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

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.

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.

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?

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.

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.

Cuando puedes leerlo como prosa.

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

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)

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.

  

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.

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.

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 ...

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.

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.

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.

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

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.

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 ".