¿Cómo entrenarse para evitar escribir el código "inteligente"? [cerrado]

  

El problema es cada vez más agobiante, ya que ahora trabajo con un equipo de desarrolladores experimentados y, a veces, mis intentos de escribir código inteligente me parecen tontos, incluso después de un tiempo que disipa la ilusión de elegancia.

Tu solución está aquí. Supongo que "experimentado" en este contexto significa "más experimentado que tú". Por lo menos, los respetas claramente. Esta es una valiosa oportunidad de aprendizaje, asumiendo que tu ego puede recibir el golpe. (Cosas irónicas, egos. Lástima que las necesitemos).

¿Tiene revisiones de código con estas personas? Si es así, si aún no lo están haciendo, pídales explícitamente que lo llamen por su mierda. Mencione que ha notado una tendencia en usted a diseñar en exceso, a utilizar un martillo neumático neumático top-of-the-line meticulosamente diseñado (preferiblemente manejado por algún tipo de android automático para trabajadores de la carretera) cuando un simple martillo sería más que suficiente .

Es posible que a menudo te encuentres retorciéndose en tu asiento mientras tu cara se pone roja durante las revisiones del código. Aguántalo. Estás aprendiendo.

Luego, una vez que tenga algunos de estos en su haber, preste atención a los momentos en los que sospecha que posiblemente esté diseñando demasiado. Cuando lleguen esos momentos, pregúntese: "Si alguien me llama a esto durante la revisión del código, ¿puedo defender mi solución como la mejor disponible? ¿O hay una solución más simple que estoy dejando de lado?"

A veces, la revisión por pares es la mejor manera de ver bien tu propio trabajo.

Lo mejor que puedes hacer es tener en cuenta la máxima de Brian Kernighan:

  

“La depuración es el doble de difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código lo más inteligentemente posible, por definición, no es lo suficientemente inteligente como para depurarlo ".

Por lo general, existen al menos tres soluciones para problemas de software de alguna importancia: la forma obvia, una forma compleja no obvia (inteligente) y una forma simple no obvia (elegante). Una cita sobre los autores es aplicable aquí:

  

Deja todo lo que viene en tu cabeza y luego eres un   escritor. Pero un autor es alguien que puede juzgar el valor de sus propias cosas,   Sin piedad, y destruir la mayor parte de ella. - Colette

No podrás escribir código elegante hasta que puedas juzgar el valor de tu propio código, sin lástima, y destruir la mayor parte. Si juzga el código elegante por el resultado final, parece ser engañosamente fácil, pero requiere disminuir la velocidad, repasar muchos borradores, buscar el consejo de otros y eliminar lo que no aparece en la página. Eso significa que incluso si su código funciona a la perfección, se pregunta a sí mismo o a un colega por qué algo no se siente bien, hasta que esté satisfecho con la respuesta. Tal vez se siente demasiado largo o repetitivo, o siente que el compilador debería haber podido detectar un cierto tipo de error. La mayoría de los programadores con un mínimo de experiencia pueden reconocer el código no elegante fácilmente. El truco es averiguar por qué .

Esa es la forma metódica de escribir código más elegante. Con frecuencia, también requiere un destello de información que lo ayude a ver un problema de una manera nueva. Esto es más difícil de lograr, pero ayuda a disminuir la velocidad y solo pensar en un problema antes de sumergirse en la codificación. Cuando encuentres una buena solución, busca una mejor. Leer otro código ayuda. Tomar clases o leer libros sobre las mejores prácticas ayuda. Aprender otros paradigmas de programación ayuda. Pedir consejo a colegas cuyo código admira ayuda.

Me gustaría agregar a las respuestas existentes, desarrollar de manera TDD, por lo que primero escribe pruebas sobre lo que debería hacer su código y luego las implementa para que sus pruebas se vuelvan ecológicas. De esta manera, solo cumplirás con los requisitos que imponen las pruebas. Ya que estará escribiendo el examen, es una buena manera de desarrollar un enfoque autodisciplinado.

Cuando se trabaja para un equipo grande y dinámico que abarca muchos conjuntos de habilidades y años diferentes, el desarrollo tiene una progresión natural para ser "reducido" al nivel más bajo del miembro más conservador o más intelectualmente deficiente del equipo, el actual o histórico.

Esto puede no ser necesariamente algo malo porque el código inteligente puede ser más difícil de depurar, más difícil de transmitir en una especificación técnica y demorar más en escribir, lo que ralentiza el tiempo de desarrollo.

Hay ocasiones en que el código inteligente es importante, como cuando el código inteligente proporciona eficiencia y ganancias de rendimiento más adelante en el ciclo de madurez del software cuando el rendimiento se convierte en un requisito.

El código inteligente también tiene una forma de transmitir un código más rápido y más legible y comprensible a un equipo que puede no estar expuesto a una nueva función de idioma o llamada a la biblioteca. Por ejemplo, cuando un desarrollador junior me introdujo por primera vez en Linq, tuve un disgusto inmediato por ser innecesario, difícil de depurar, tonto e "inteligente". Después de jugar con él y descubrir cuán útiles y poderosas pueden ser las consultas de Linq, invierto tiempo para aprenderlo y mi código DAL nunca ha sido más limpio y legible, así como más fácil de depurar y extender.

Lamento no tener una mente abierta antes y desearía no haber sido tan duro con un desarrollador junior tan "inteligente".

Mi punto es que el código "inteligente" DEBE ser sospechoso, pero no debemos ir a la cruzada contra él porque puede ahogar la creatividad y la innovación.

EDITAR: Acabo de darme cuenta de que no respondí completamente tu pregunta. Si tiene la capacidad en su proyecto para escribir código inteligente con mucha facilidad, tal vez el equipo debería adoptar estándares de codificación más estrictos para seguir una plantilla y un estilo distintos y uniformes. Esto ayudará a dibujar las líneas de su caja de arena para que no salga a la calle persiguiendo una pelota.

Si el 20% (su% puede variar) o más de sus líneas agregadas debe ser documentación, es hora de retroceder y rethink .

Realmente creo que deberías esforzarte por ser inteligente, es un efecto secundario natural de ser más competente. Darte una guía general como el% de comentarios necesarios para aclararte es una buena manera de obligarte a retroceder y evaluar si usar esa nueva cosa que aprendiste es una elección acertada o simplemente una forma de mostrar tu nuevo juguete. p>     

No puedo resistirme a intentar algo inteligente.

Así que lo hago en un proyecto de juguete, en mi propio tiempo, en casa.

Cuando la novedad desaparece, el problema se resuelve.

Creo que una forma de averiguar si tu código es demasiado "inteligente" es retroceder un paso y preguntarte lo siguiente:

  

Si tuviera que dar una copia impresa de este código a alguien que nunca ha   trabajaron en este proyecto / código, ¿podrían leerlo y   Describe de nuevo lo que hace la función (después de darles algunos   breve contexto)? Si no, ¿cuánto tendría que hacer la explicación? Cómo   ¿Le explico esto a alguien que toma CS101?

Si resulta que tendría que guiar a alguien a través de cada línea o la mayoría de las líneas en un método o clase, probablemente sea demasiado inteligente. Si tiene que explicar las construcciones de lenguaje (por ejemplo, LINQ) a alguien que no está familiarizado con eso, probablemente esté bien. Si tiene que mirar una línea y pensar un poco antes de poder explicarla, su código debe ser refactorizado.

1) Quédate quemado antes para que sepas que es algo malo. Intentar depurar algo de hace mucho tiempo que está escrito inteligentemente es muy divertido. Creo que tienes eso cubierto.
2) Comente su código, explique lo que está haciendo antes de cada sección de código.
3) Si tiene dificultades para explicarlo o siente la necesidad de insertar un diagrama, entonces lo que acaba de hacer es demasiado inteligente y probablemente podría hacerse de manera más limpia.

Las soluciones inteligentes a los problemas pueden ser fantásticas, hasta que tenga que depurarlas o expandirlas. A veces es la única solución. Si puede describir exactamente qué demonios hace y cómo lo hace, las soluciones inteligentes pueden ser aceptables.

Normalmente uso comentarios para describir lo que estoy haciendo con una sección de código. Si parece en lo menos confuso, también describo cómo lo estoy haciendo. Idealmente, el código debe ser sencillo y autoexplicativo. Pero si me cuesta explicar cómo hice lo que acabo de hacer, entonces es una señal clara de que necesito dar un paso atrás e intentarlo de nuevo.

Probablemente, una buena manera de comenzar a escribir código simple es liberar la pasión inteligente en un proyecto que pide inteligencia . El resto de la respuesta es específica de .NET, pero Estoy seguro de que uno puede encontrar proyectos de nivel similar en cualquier otro idioma.

Hay marcos de inyección de dependencia de código abierto Para trabajar en el que solo solicite el conocimiento de Expression tricks, hay F # y maravillosa variedad de tareas por las que uno podría querer intentarlo.

Si te gustan las matemáticas (y eso es agnóstico del lenguaje ), tienes Project Euler para ti.

Por último, pero no menos importante, en el mundo .NET hay un Mono Project que tiene una gran cantidad de áreas que necesitan la atención del desarrollador , algunas de ellas bastante complicadas. ¿Qué hay de contribuir a una herramienta analizadora de código .NET de código abierto ? Hay algunos análisis de IL involucrados, así como cosas de alto nivel. Jb Evain siempre funciona en algo interesante, ya sea en la biblioteca de reflejos Cecil, el soporte Expression o un descompilador .NET.

Si nada encaja, solo inicie su propio marco de burla : - )

  

¿Conoces esa sensación cuando solo necesitas mostrar ese nuevo truco?   ¿Con expresiones o generalizar tres procedimientos diferentes?

No

Esta es una de las razones por las que siempre digo que es algo bueno cuando los nuevos desarrolladores se lanzan a un gran desorden de código speghetti indocumentado para mantener y refactorizar. Les enseñará las realidades de mantener un código demasiado 'inteligente' que no escribieron, y espero que inculque cierta empatía por el pobre imbécil que tendrá que depurar su código dentro de 5 años.

Creo que el tema está bien elegido. Es "genial" escribir una línea de Perl que haga diez mil cosas a la vez, pero luego apesta cuando tienes que volver a visitarla.

En una nota diferente, inteligente o no, el código debe estar documentado. Existe un desajuste de impedancia inherente entre los lenguajes de programación aceptados por la industria y los conceptos de alto nivel a los que los humanos estamos acostumbrados en nuestro pensamiento. El código de auto-documentación simplemente no es realizable, hasta que se convierte en un lenguaje natural, es decir. Incluso es necesario documentar el código de Prolog, ya que, por muy alto que sea, aún es bastante formal.

El código imperativo de grano fino sirve para implementar planes de grano grueso, que deben documentarse. No quiero tener que leer las 50 líneas del método cuando un comentario rápido de la hoja de ruta de 3 líneas funcionará.

Edición posterior: Un ejemplo más elocuente es uno que trasciende las computadoras. Un libro puede estar muy bien escrito, pero a menudo queremos procesarlo en diferentes niveles de abstracción. A menudo, un resumen del libro servirá, y eso es lo que los comentarios pueden ofrecer al código. Por supuesto, un código bien resumido puede hacer mucho para la autodocumentación, pero no puede ofrecerle todos los niveles de abstracción.

Y los comentarios también pueden actuar como notas al margen en un libro, cuando necesitamos explicar el proceso de razonamiento detrás de una afirmación en el texto principal sin descarrilarlo.

Con este contexto, encuentro que mi declaración anterior que se refiere al lenguaje natural que trasciende la necesidad de comentarios es incorrecta. Incluso el lenguaje natural, como en un libro, puede prestarse a la documentación, para explicar de manera dispersa la abstracción incorporada en el texto, o para proporcionar desvíos sin descarrilar el texto principal. Con la nota de que un código bien resumido ya puede haber recorrido un largo camino hacia la autodocumentación.

Por último, pero no menos importante, los comentarios pueden ayudar al programador a mantener un alto nivel de abstracción. Muchas veces me doy cuenta de que dos comentarios consecutivos que incluí en una lista de pasos no hablan al mismo nivel de abstracción, lo que justifica de inmediato una mirada crítica a lo que estoy haciendo con ese código.

Ciertos problemas trascienden la codificación y afectan la codificación al igual que otras actividades. Los comentarios pueden proporcionar esa ayuda para aclarar las razones subyacentes y las facetas de nuestro código, y creo que son un compañero agradable que habla un lenguaje más suave para beneficiar a la persona para un cambio.

¿Cómo? Siga mostrando su código a los desarrolladores con experiencia. y cuando te arrebatan por ser sofisticado y vistoso, hazlo y pregúntales cómo lo harían y por qué (de una manera no confrontativa, por supuesto).

Editar a la luz de -1:

Hace muchas lunas, estaba en la misma situación: tenía un jefe que se estremecía cada vez que usaba un puntero en Delphi o el 'con construcción', otro que amenazaba con despedirme si no detenía el corto circuito todos mis booleanos con 0-1 y usando variables de una sola letra en todas partes.

Aprendí porque pregunté por qué y se tomaron la molestia de explicarlo porque pensaron que podría ser algo - LOL ...

¿Siento la necesidad de presumir? No, no más. ¿Cómo lo superé? Como la mayoría de las personas superan cualquier otro mal hábito ... la práctica consciente y deliberada de las técnicas adecuadas. Si lo hace lo suficiente, comprenderá el valor de las mejores prácticas y, a través de su uso constante, desarrollará buenos hábitos.

También tenga en cuenta que al centrarse en el software funcional, que es puntual y se mantiene fácilmente, obtendrá el reconocimiento que busca. Los desarrolladores con experiencia vendrán a ti y te dirán "El hombre que escribiste el módulo estaba bien diseñado. Solo tuve que implementar un componente para conectarlo a mi proyecto". a diferencia de "Tuve que volver a trabajar todo el módulo que escribiste para usarlo en otro componente. ¿Alguna vez has oído hablar de Bob Martin o Ward Cunningham?"

TLDR: No estás solo. El reconocimiento de la habilidad se logra mejor como un subproducto de la resolución de problemas de forma inteligente.

Para mí, el código demasiado inteligente a menudo se esfuerza por resolver los requisitos futuros imaginarios en lugar de centrarse en los requisitos de hoy. ¡Gran trampa!

0% de código demasiado complicado no es un objetivo alcanzable. Tal vez ni siquiera el mejor objetivo para luchar. El código demasiado complicado es malo, pero tienes que probar cosas nuevas para crecer como programador. No debe probarlos en el código de producción si puede evitarlo. A diferencia de las máquinas, los humanos cometen errores.

Código de ayuda ayuda. Pasar años arreglando el código "inteligente" de otras personas ayuda. Mantenerse enfocado en lo que el cliente realmente necesita hoy en día ayuda.

Las escuelas y los negocios tienen cuadrillas de personal de limpieza y mantenimiento en el personal. ¡El código necesita limpieza y mantenimiento también! Cuando sea posible, limpie los líos (especialmente los suyos)! Creo que eso es lo mejor que uno puede hacer.

Además de los buenos consejos dados hasta ahora (revisión de código, depuración, enfoque TDD), debe (re) leer de vez en cuando los (mejores libros imho) sobre buenas prácticas de codificación:

• programador pragmático
• Código completo
• Código limpio

y otros, dependiendo de la tecnología que uses.

Solo recuerda YAGNI: no vas a necesitarlo .

  

el programador no debe agregar funcionalidad hasta que se considere necesario ...

     

YAGNI es un principio detrás de la práctica de XP de "hacer lo más simple que podría funcionar" (DTSTTCPW). Está diseñado para ser utilizado en combinación con varias otras prácticas, como la refactorización continua, las pruebas unitarias automatizadas continuas y la integración continua. Utilizado sin refactorización continua, podría dar lugar a código desordenado y retrabajo masivo ...

     

Según quienes defienden el enfoque de YAGNI, la tentación de escribir código que no es necesario en este momento, pero que podría estar en el futuro, tiene las siguientes desventajas:

     

• El tiempo dedicado se toma al agregar, probar o mejorar la funcionalidad necesaria.
  
• Las nuevas funciones se deben depurar, documentar y admitir.
  
• Cualquier nueva característica impone restricciones sobre lo que se puede hacer en el futuro, por lo que una característica innecesaria puede impedir que se agreguen las características necesarias en el futuro.
  
• Hasta que la función sea realmente necesaria, es difícil definir completamente lo que debe hacer y probarlo. Si la nueva función no está definida y probada correctamente, es posible que no funcione correctamente, incluso si finalmente se necesita.
  
• Conduce al código inflado; el software se vuelve más grande y más complicado.
  
• A menos que haya especificaciones y algún tipo de control de revisión, la función puede no ser conocida por los programadores que podrían usarla.
  
• Agregar la nueva característica puede sugerir otras nuevas características. Si estas nuevas características también se implementan, esto puede resultar en un efecto de bola de nieve hacia la fluencia de características ...