¿Cómo sabes que estás escribiendo un buen código? [duplicar]

267

Me encanta la programación. He estado jugando con el código desde que era un niño. Nunca tomé la ruta profesional, pero codifiqué varias aplicaciones internas para varios empleadores, incluido un proyecto que obtuve en el lugar donde construí un sistema interno de gestión de transacciones / informes para un banco. Recojo cosas rápidamente, entiendo muchos de los conceptos y me siento a gusto con todo el proceso de codificación.

Dicho todo esto, siento que nunca sé si mis programas son buenos. Claro, funcionan, pero ¿está el código limpio, ajustado, bien escrito, o lo vería otro programador y me pegaría en la cabeza? Veo algunas cosas en Stack Overflow que simplemente me sorprenden y hacen que mis intentos de codificación parezcan completamente débiles. Mis empleadores han estado contentos con lo que he hecho, pero sin la revisión por pares, de lo contrario, estoy en la oscuridad.

He investigado la revisión del código de pares, pero muchas cosas no pueden publicarse debido a NDAs o cuestiones de confidencialidad. Muchos de ustedes profesionales pueden tener compañeros de equipo para ver cosas por encima del hombro o intercambiar ideas, pero ¿qué hay de los tipos independientes y solistas como yo? ¿Cómo aprende las mejores prácticas y se asegura de que su código esté a la altura?

¿O no importa si es "el mejor" siempre y cuando se ejecute como se espera y proporcione una buena experiencia de usuario?

    
pregunta 6 revs, 5 users 50%Jim 14.11.2015 - 16:32
fuente

25 respuestas

328

La mayor pista para mí es:

Cuando tiene que regresar y agregar / modificar una característica, ¿es difícil? ¿Rompe constantemente la funcionalidad existente al realizar cambios?

Si la respuesta a lo anterior es "sí", es probable que tenga un diseño general deficiente.

Es (para mí al menos) un poco difícil juzgar un diseño hasta que se requiere que responda al cambio (dentro de lo razonable, algunos códigos son malos y se puede decir de inmediato, pero incluso eso viene con experiencia .)

    
respondido por el Ed S. 25.03.2011 - 02:35
fuente
177

Esta es ciertamente una medida bastante estándar donde trabajo.

  

¿Qué puerta representa tu código? ¿Qué puerta representa a tu equipo o tu empresa? ¿Por qué estamos en esa habitación? ¿Es esto simplemente una revisión de código normal o hemos encontrado una serie de problemas horribles poco después de su lanzamiento? ¿Estamos depurando en pánico, estudiando minuciosamente el código que pensamos que funcionaba? ¿Se están yendo los clientes en masa y los gerentes nos están fallando el cuello ...

(Robert C Martin, Clean Code - libro que se abre con la imagen de arriba)

    
respondido por el Phil.Wheeler 23.09.2013 - 10:03
fuente
103

Sabes que estás escribiendo un buen código cuando:

  • Las cosas son inteligentes, pero no demasiado inteligentes
  • Los algoritmos son óptimos, tanto en velocidad como en legibilidad
  • Las clases, variables y funciones están bien nombradas y tienen sentido sin tener que pensar demasiado
  • Vuelves a él después de un fin de semana libre y puedes saltar directamente
  • Las cosas que se reutilizarán son reutilizables
  • Las pruebas unitarias son fáciles de escribir
respondido por el Rich Bradshaw 24.03.2011 - 22:18
fuente
59

Aunque dijiste que no tenías otros programadores para hacer esto, incluiré esto por el bien de los demás.

La prueba de calidad del código: Haga que otro programador que nunca haya visto el código lo lea y le explique qué le hace cada módulo mientras mira por encima del hombro. Cuanto más fuerte sea su deseo de saltar y explicar algo, peor es el código que probablemente sea. Si puedes sentarte tranquilamente con la boca cerrada y no necesitan hacer muchas preguntas, probablemente estés bien.

Para su beneficio, aquí hay algunas pautas generales para cuando no tiene un compañero a la mano. No son absolutos, solo "huele".

Buenas señales

  • Los métodos tienden a ser muy cortos y lo ideal es que realicen una sola tarea.
  • Tienes suficiente información para llamar a los métodos SIN mirar el cuerpo de ellos.
  • Las pruebas unitarias son fáciles de escribir.

Señales malas

  • Métodos largos compuestos de 2-3 subtareas que no se dividen en otros métodos.
  • Los métodos comparten datos a través de otros medios distintos a su interfaz.
  • Si cambia la implementación de un método (pero no la interfaz) necesita cambiar la implementación de otros métodos.
  • Muchos comentarios, especialmente comentarios largos.
  • Tiene un código que nunca se ejecuta en su aplicación para proporcionar "flexibilidad futura"
  • Bloques grandes de try / catch
  • Le está resultando difícil encontrar buenos nombres de métodos o contienen las palabras "OR" y "AND" (por ejemplo, GetInvoiceOrCustomer)
  • Bloques de código idénticos o casi idénticos.

Aquí hay una lista más larga de olores de código que también deberían ser útiles.

    
respondido por el JohnFx 25.03.2011 - 17:38
fuente
27

Para mí, personalmente, creo que es cuando me olvido del código. En otras palabras:

  • Los errores raramente ocurren
  • Cuando ocurren, otras personas los resuelven sin preguntarme nada
  • Aún más importante, nadie nunca me pregunta nada con respecto a mi código
  • Las personas no tienen una alta tasa de WTF / min cuando lo leen
  • Muchas clases nuevas en el sistema comienzan a usar mi clase ( high fan-in , como lo llamaría Steve McConnell)
  • El código es fácil de modificar y / o refactorizar cuando / si es necesario, sin maldecirme (incluso si soy yo, ¡maldiciéndome a mí mismo!)
  • También me encanta cuando creo que es exactamente la cantidad de abstracción adecuada que parece ser adecuada para todos en el equipo

Es una sensación agradable cuando abres un archivo que escribiste hace un año y ves todas las adiciones agradables a una clase, pero muy pocas modificaciones , y - ¡muy alta fan-in! :)

Por supuesto, estas son las cosas que hacen que yo sienta que estoy escribiendo un buen código, pero en realidad, es muy difícil saberlo. Supongo que si la gente comienza a burlarse de su código más de lo que se burla de usted, es hora de preocuparse.

    
respondido por el dr Hannibal Lecter 24.03.2011 - 23:15
fuente
20

Tengo tres reglas de oro:

  1. Si me siento obligado a copiar / pegar bloques de código, estoy haciendo algo mal
  2. Si no puedo tomar todo el código en mi cabeza, estoy haciendo algo mal
  3. Si alguien entra y se pierde en mi código, estoy haciendo algo mal

Esas reglas me han guiado a hacer algunas mejoras arquitectónicas reales, terminando con clases / métodos pequeños, limpios y mantenibles.

    
respondido por el dukeofgaming 03.04.2011 - 18:38
fuente
11

Esta es una excelente pregunta, y te felicito por incluso preguntar.

Primero, es bueno hacer volar tu mente de vez en cuando. Te mantiene humilde, te hace darte cuenta de que no lo sabe todo, que hay gente mejor para ti que esto y te da algo mejor por lo que luchar.

Ahora, ¿cómo sabes cuándo estás escribiendo un buen código?

  • Cuando sus clases tienen un propósito único, muy claramente definido, separado de otras clases con otros propósitos claramente definidos.
  • Cuando sus métodos son cortos, idealmente por debajo de 50 líneas y ciertamente por debajo de 100, y sus nombres definen claramente lo que hacen exactamente . Un método no debe hacer nada más que lo que su nombre implica. Si va por más de 100 líneas, o está muy cerca, probablemente pueda sacar algo de su propia función.
  • Cuando su código proporciona una forma de hacer algo: cuando no proporciona la opción de zig o zag, sino que proporciona una única ruta lineal para cada posible curso de acción, el usuario puede enviarlo.
  • Cuando haya hecho todo lo que razonablemente pueda para reducir el acoplamiento entre clases; de modo que si la Clase A depende de la Clase B, y la Clase B se elimina y la Clase C se coloca en su lugar, se deben hacer pocos o ningún cambio a la Clase A. La Clase A debe ser lo más ciega posible a lo que está sucediendo en el mundo exterior.
  • Cuando cualquier persona que ingrese el código puede leer y entender de inmediato los nombres de sus clases, métodos y variables, no hay necesidad de 'pktSize' cuando 'packetSize' se lee mucho más fácilmente.

Como han dicho otros, esencialmente, si estás haciendo Programación Orientada a Objetos, y cuando llega el momento de cambiar algo, lo encuentras como intentar desenredar y rebobinar una bola de hilo, el código no sigue un buen Objeto -Principios orientados.

Recomiendo encarecidamente el libro "Clean Code", si está interesado en profundizar un poco más en esta. Es una buena lectura para principiantes y expertos por igual.

    
respondido por el trycatch 25.03.2011 - 04:04
fuente
7

Yo diría que mis puntos principales serían:

  • Legibilidad (para usted y cualquier otra persona que haya revisado su código)
  • Capacidad de mantenimiento (fácil de modificar)
  • Simplicidad (no complica las cosas cuando no hay necesidad de eso)
  • Eficiencia (por supuesto, su código debería ejecutarse rápidamente)
  • Claridad (si su código se explica por sí mismo, no es necesario que haga comentarios la mayoría de las veces, nombre sus métodos / propiedades, etc. con sensatez, divida el código largo, nunca copie y pegue un bloque de código)

No estoy poniendo Diseño en esta lista, ya que creo que se puede escribir un buen código sin adherirse a un patrón de diseño siempre y cuando sea consistente dentro de su proyecto.

Buen artículo de MSDN sobre este tema: ¿Qué hace que un buen código sea bueno?

    
respondido por el Bad Display Name 25.03.2011 - 11:40
fuente
6

Busque un buen proyecto de código abierto en su idioma favorito y vea qué hacen.

Por ejemplo, sendmail es un lugar para ver si escribe código de spaghetti . No es culpa de Sendmail realmente; Solo tiene 20 años, por lo que tiene un montón de travesuras. Entonces, si su código se ve como el código de sendmail, probablemente esté en el camino equivocado.

No he visto Postfix últimamente, y probablemente esté muy bien diseñado. Así que si tus cosas se parecen más a postfix, estás en el camino correcto.

Cuando comencé a programar cuando era niño, no había Internet y no tenías nada con qué comparar. Pero ahora con un montón de líneas de código disponibles para verlas como comparación, debes comenzar a tener una idea de si lo estás haciendo bien o no.

Y solo porque el kernel de Linux es el kernel de Linux no significa que esté bien escrito. Ten eso en cuenta.

    
respondido por el 2 revs, 2 users 64%stu 26.03.2015 - 12:12
fuente
6

Esta ha sido mi experiencia desde que pasé del mundo universitario de la programación a la industria en los últimos cinco meses:

  • La facilidad de uso es tan importante que pagamos a las personas solo para diseñar interfaces de usuario. Los programadores a menudo apestan al diseño de la interfaz de usuario.
  • Encuentras que hacer que funcione no es suficiente
  • Las optimizaciones se vuelven más críticas en los escenarios del mundo real.
  • Hay mil formas de abordar un problema. Sin embargo, muchas veces el enfoque no tiene en cuenta factores menos conocidos que podrían afectar negativamente el rendimiento de su enfoque, como la autenticación de la base de datos, las transacciones, el archivo I / O , reflexión, solo para nombrar unos pocos al azar.
  • La capacidad de mantenimiento es un aspecto muy importante de la codificación. El hecho de que tu código esté súper optimizado y súper denso ... no significa que sea sexy. A veces simplemente se etiqueta como "Codificación de héroe".
  • Las habilidades de diseño se aprenden, no son inherentes. Estoy seguro de que hay algunos niños con problemas cerebrales, pero en general, el diseño sólido con respecto a los problemas del mundo real, se desarrolla a través del tiempo, la investigación y, lo que es más importante, la transmisión de conocimientos de sus superiores = P
  • La documentación no es una conveniencia, es una necesidad.
  • Lo mismo ocurre con pruebas unitarias (esto varía según la compañía)

Le sugiero que aproveche la oportunidad con un proyecto de código abierto. Tendrá la oportunidad de ver cuánto sabe realmente si trabaja junto con la línea de fondo de otros programadores. Un proyecto de código abierto es probablemente la mejor forma de averiguarlo según su fondo.

    
respondido por el Feisty Mango 26.03.2015 - 12:14
fuente
2

Cuando puedes leerlo como prosa.

    
respondido por el Klaim 25.03.2011 - 00:15
fuente
2

Desde una perspectiva de código y diseño, me gusta lo que otros ya han dicho sobre la capacidad de mantenimiento.

Además, también miro la estabilidad. Mira las estadísticas de soporte de producción. Si está obteniendo una alta instancia de correspondencia de soporte para cosas que parecen ser una funcionalidad fundamental, pero encuentra que muchas personas no pueden entender cómo usar el software o si encuentran que no satisface sus necesidades, entonces hay algo incorrecto.

Por supuesto, hay algunos usuarios que no tienen ni idea, pero si con el tiempo sigue recibiendo informes de roturas, confusiones o solicitudes de cambio de características significativas, esto indica que se aplica uno o todos los siguientes:

  • Los requisitos se rompieron
  • El código está roto
  • La aplicación no es intuitiva
  • El desarrollador no entendió la necesidad del usuario
  • Alguien presionó para la fecha de entrega por encima de la calidad
  • Alguien no probó bien o no sabía qué probar
respondido por el Bernard Dy 25.03.2011 - 02:20
fuente
2

Lee un buen código y averigua por qué es bueno. Lee el código malo y averigua por qué es malo. Lea el código mediocre y averigüe qué partes son buenas, cuáles son malas y cuáles están bien. Lee tu propio código y haz lo mismo. Recoja un par de libros de texto (bien considerados) específicamente con el fin de ver los ejemplos y comprender por qué los escribieron de la manera en que lo hicieron. Principalmente, lea el código hasta que pueda distinguir la diferencia entre malo y bueno, y pueda hacer su propio "Wtf?" pruebas.

No puedes saber si estás escribiendo un buen código hasta que puedas reconocer un buen código en general. El hecho de que algo esté por encima de su cabeza no significa que esté bien escrito ...

("Leer el código de otras personas" apareció en un par de comentarios en este hilo, pero pensé que merecía su propia publicación)

    
respondido por el Beekguk 25.03.2011 - 16:46
fuente
2

Pídale a otra persona que se haga cargo de su trabajo por un día y verifique qué tan estresado está al final del día ;-)

Soy malo en documentar y limpiar cosas, así es como lo verifico.

    
respondido por el Stefan Ernst 26.03.2015 - 12:09
fuente
1
  

Dicho todo lo dicho, me siento como yo   nunca se si mis programas son   bueno. Claro, funcionan, pero es el   código limpio, apretado, cosas bien escritas,   o otro codificador lo miraría y   abofetearme en la cabeza?

¿Has considerado preguntarle a otro programador qué piensan de tu código?

Algunos lugares usan "revisión por pares" donde el código debe ser aceptable para otro codificador antes de que sea aceptado en el repositorio de códigos.

    
respondido por el user1249 25.03.2011 - 07:21
fuente
1

En mi humilde opinión, no hay un "buen código" per se, pero hay un "buen software".

Cuando estamos trabajando en algo, hay muchas restricciones en nuestro trabajo, que muchas veces nos hacen producir el código que cae fuera del estándar de "buen código" de otros programadores.

Algunos podrían decir "buen código" es el código que es fácil de mantener. El argumento en contra de esta afirmación para mí es, ¿qué tan fácil? ¿Necesitamos poner un esfuerzo de 200% en la pieza de código para que sea tan fácil de mantener por el estándar de "buen código", incluso si sabemos que no necesitaremos mantenerlo tanto? Lo siento, pero no lo creo.

De hecho, yo soy el que realmente promueve el "buen código" en mi equipo que a nadie le importa. Cada vez que miro sus códigos, nunca encontré que escribieran un código perfecto. Sin embargo, debo aceptar que realmente hicieron el trabajo y también poder mantenerlo adecuadamente para las necesidades de nuestra empresa. Por supuesto, la aplicación a veces tiene fallos, pero acabamos de hacerlo a tiempo, haciendo felices a nuestros clientes y usuarios y asegurando a nuestra empresa en una posición muy por delante de nuestros competidores.

Por lo tanto, diría que "código bueno" es el código que produce lo que necesitas. Solo tienes que pensar en lo que realmente necesitas, luego usarlo para evaluar tu código.

    
respondido por el tia 26.03.2011 - 07:44
fuente
1

El buen código es subjetivo para la persona. Un programador profesional que ha leído muchos libros, ha asistido a seminarios y ha usado diferentes técnicas de codificación probablemente destruiría su código ... Sin embargo, he descubierto que el código es realmente indicativo de dónde está el nivel de experiencia de los programadores. Para mí, se lee como un libro de historia o una auto-biografía. Es lo que el programador sabía en ese momento o a qué herramientas se limitaba.

Pregúntate esto ... ¿Por qué Microsoft toma 3 versiones de software para hacer algo bien? Porque están constantemente arreglando los errores que cometieron en las versiones anteriores. Sé que mi código siempre mejora y mejora después de una revisión. Seguro que habrá gente aquí que diga, escribo el código perfecto la primera vez. Si crees eso, entonces tengo algunas tierras pantanosas para venderte ...

A medida que entiendes los conceptos, las cosas se vuelven más fáciles. Para mí, el comienzo de aprender algo nuevo es "¿puedo hacer que funcione?", Luego el siguiente paso es "Me pregunto si puedo hacerlo de esta manera ...", entonces, generalmente, cuando lo logro, pregunto. "¿Cómo puedo hacerlo más rápido" ...

Si quieres ser un programador, tienes que sumergirte en él y simplemente hacerlo. Requiere mucho trabajo y, para ser honesto, es como una obra de arte que nunca se puede terminar. Sin embargo, si quieres ser solo un aficionado casual, entonces si funciona, entonces no te preocupes por eso. Tienes que adaptarte a tu entorno. Si no tiene una manera de hacer revisiones de código, entonces la ignorancia es una bendición =)

Pero no importa qué ... Todos van a tener su propia opinión. Claro que hay formas correctas y formas equivocadas de hacer las cosas ... Pero, sobre todo, he encontrado que existen formas mucho mejores de hacer las cosas que formas equivocadas ...

    
respondido por el webdad3 27.03.2011 - 17:09
fuente
1

Para una pieza de código en particular:

Si funciona y se puede mantener (elija sus buenas prácticas), es un buen código.

Para usted como desarrollador a lo largo del tiempo:

Bueno es un término relativo y dinámico, para el dominio del idioma, el dominio del problema, las tendencias actuales y, lo que es más importante, su experiencia. La prueba de ácido "BUENA" para este continuo podría simplemente mirar hacia atrás en su trabajo anterior y si dice " suspiro , ¿realmente lo resolví de esa manera?" entonces es probable que continúes creciendo y que sigas escribiendo buen código.

Si miras hacia atrás y ves el código perfecto, entonces, eres perfecto, y existe el riesgo de que te estancas y pronto dejarás de escribir un buen código.

    
respondido por el Stephen Bailey 26.03.2015 - 12:23
fuente
0

Libere su código, deje que algunas personas se metan con él para asegurarse de que hace lo que siempre debe hacer. O si lo desea, diseñe una especificación y asegúrese de que cumpla con todas esas especificaciones. Si pasa una o ambas de estas pruebas, entonces su código es "válido por ahora". Para la mayoría de las personas, su código nunca será bueno, porque volverá en un año y dirá "¿Por qué hice eso cuando hubiera funcionado mucho mejor esto way? "

Con más experiencia, obtienes mejor código. Pero si continuamente practicas los mismos hábitos, continuamente caerás en los mismos escollos. Es solo una versión simple de un viejo adagio de "La práctica hace permanente ". Si continuamente haces las cosas de la manera correcta (como probar tu código para asegurarte de que funcione para lo que se supone que debe hacer), entonces mejorarás. Si continuamente hace las cosas de manera incorrecta (como nunca probar su código para ciertas situaciones, o no reconocer dónde podrían ocurrir errores), simplemente se volverá terco con su código.

    
respondido por el Andrew Hays 24.03.2011 - 22:16
fuente
0

No hay nada mejor que tener a alguien con experiencia mirando tu código, pero hay algunos recursos para ayudarte a evaluar y mejorar tu código por tu cuenta. Eche un vistazo a la Refactorización de Martin Fowler (o website ). Los estándares de codificación de C ++ de Sutter y Alexandrescu son buenos si escribes en C ++. Muchas de las recomendaciones incluyen lenguaje agnóstico, pero otras pueden recomendar libros similares para otros idiomas. El desarrollo basado en pruebas puede ser muy útil para los desarrolladores en solitario, ya que proporciona una especie de control de calidad a medida que avanzas, y sabes cuando las pruebas se vuelven difíciles de escribir, lo que significa que tu código probablemente podría usar una reestructuración.

Algunos otros signos están más orientados al proceso. Usualmente llevan a un mejor código, pero no directamente. Estos incluyen cosas como el uso del control de código fuente, un proceso de compilación automatizado, no desarrollar directamente en el servidor en vivo, el uso de software de seguimiento de errores, etc.

    
respondido por el Karl Bielefeldt 25.03.2011 - 01:47
fuente
0

Puede utilizar una herramienta de análisis de código como FindBugs , PMD . Eso proporcionará información sobre la calidad de su código.

    
respondido por el nimcap 25.03.2011 - 08:59
fuente
0

En un esfuerzo por codificar bien, mi objetivo es asegurar que el programa sea altamente funcional y rápido al respecto. Asegúrese de que todo esté en un lugar en el que debería estar, de modo que el archivo, los datos, la función y las abstracciones sean bastante obvios.

Después de este punto, lo pongo a prueba: encuentre a una persona bastante poco versada en las computadoras en general, intente explicar algunos de los patrones principales del código. Si pueden leerlo un poco, wow. Buen trabajo.

Principalmente, solo KISS y trata de ser innovador sin fallar. También tomaría más notas sobre volver al código y pasar un buen rato mejorándolo y manteniéndolo, pero eso se ha cubierto bastante bien.

    
respondido por el Garet Claborn 11.08.2011 - 23:52
fuente
0

Nunca.

"Buen código" es solo un código para el que aún no se ha encontrado ningún modo de mejora. Como Jeff Atwood dijo :

  

Hay un puñado de programadores en   El mundo capaz de producir.   Código brillante, perfecto. Todo el resto   de nosotros podemos hacer es seguir haciendo nuestra   software menos mierda en el tiempo-- un   proceso de mejora continua

Y, por cierto, no tiene que alcanzar la perfección, porque a veces, " Suficiente diseño significa mal diseño ".

    
respondido por el David 26.03.2015 - 12:21
fuente
-1

Uso 5 puntos para saber si el código es bueno o no:

  • los nombres de los procedimientos, los métodos y las clases son útilmente cortos y, sin embargo, me dicen qué hacen.
  • comentar hacia fuera cualquier falla de ejecución de las causas de inclusión
  • viendo el código después de un mes, puedo seguir el flujo
  • el código se compila y se ejecuta limpiamente.
  • El programa
  • realiza las acciones previstas y solo las acciones previstas.

Para mí, GetCustIDFromDB (var & ast; DB, char & ast; customer) es mejor que getcid (var & ast; DB, char & ast; c) porque me dice lo que estoy mirando. Pero * DBLookupCIDByName (var & ast; DB, char & ast; customer) también funciona.

A menudo hago pruebas para ver si aún uso todos mis #incluidos ... Si puedo eliminarlo, genial. A veces, es posible examinar los encabezados incluidos y ver si las funciones necesarias están realmente en algo que el encabezado incluye a través de #include en su lugar ... pero solo lo he hecho rara vez, y también ahorra un poco de espacio. aunque 'puede hacer que el proceso de agregar nuevas funciones sea mucho más difícil.

    
respondido por el aramis 26.03.2011 - 00:20
fuente
-1

Es una cosa difícil de decir. Siempre hay una cuestión de tomar más tiempo para hacerlo bien, o tomar menos tiempo y hacerlo antes para que pueda trabajar en otras cosas.

enlace

Regresé y miré el código que hice hace unos años, y creo que se ve horrible. Estamos aprendiendo constantemente en este campo, y la mejor manera de codificar correctamente es mirar los ejemplos de otras personas y aprender de ellos. Una vez que aprendas algo nuevo, compártelo con otros para que todos podamos beneficiarnos de él.

    
respondido por el thunsaker 26.03.2015 - 12:20
fuente

Lea otras preguntas en las etiquetas