¿Cómo escribir un buen código con cosas nuevas? [cerrado]

Siempre trato de escribir código fácil de leer que esté bien estructurado.

Me enfrento a un problema particular cuando estoy jugando con algo nuevo. Sigo cambiando el código, la estructura y muchas otras cosas. Al final, miro el código y me molesta lo complicado que se volvió cuando estaba tratando de hacer algo tan simple.

Una vez que he completado algo, lo refactorizo ​​mucho para que esté más limpio. Esto ocurre después de la finalización la mayor parte del tiempo y es molesto porque cuanto más grande es el código, más molesto es reescribirlo.

Tengo curiosidad por saber cómo las personas lidian con tal agonía, especialmente en grandes proyectos compartidos entre muchas personas.

Mientras esté refactorizando, lo está haciendo bien.

Considere esto: en cualquier momento puede trazar una solución al problema. Sin embargo, a medida que pasa el tiempo, está descubriendo cada vez más sobre el problema que lo lleva a ser capaz de encontrar mejores soluciones. La primera iteración puede ser al revés, y la última es, con suerte, elegante. Si continúa refactorizando a medida que crece su conocimiento, siempre obtendrá mejores resultados. No existe un atajo para saltar de inmediato a la solución más elegante sin seguir los pasos de 'aprendizaje' a menos que ya haya encontrado un problema similar, pueda generalizar problemas pasados ​​o tener suerte.

Tengo curiosidad por saber cómo las personas lidian con tal agonía, especialmente en grandes proyectos compartidos entre muchas personas.

• Reconoce que existe.
• Programe tiempo para la creación de prototipos.
• Intente aprender cosas nuevas en proyectos de pasatiempos en lugar de código de producción.

Bueno, hago TDD con pruebas unitarias. Todo el mantra TDD gira en torno al siguiente ciclo:

Como estoy usando TDD, me veo obligado a escribir pruebas unitarias. Si una prueba es difícil de escribir, es una señal de que mi diseño es demasiado complicado y debe simplificarse.

El ciclo no termina a menos que refactorice para eliminar la redundancia, por lo que la mayor parte del tiempo se refactoriza en pequeños fragmentos y no consume mucho tiempo. Además, después de cada refactorización ejecuto todos los casos de prueba para asegurarme de no haber roto nada.

fuente de la imagen: http://www.javacodegeeks.com/2012/05/test-driven-development-win-win.html

Todos aprenden a escribir un programa escribiéndolo. La refactorización es parte del proceso, porque estás mejor calificado para escribirla la segunda vez. El truco no es tratar de evitar la refactorización, sino hacerlo antes y con mayor frecuencia. Refactorice tan pronto como note un problema, en lugar de esperar hasta el "final".

Una vez que haya escrito y depurado el código, déjelo a un lado y vuelva a escribirlo de una manera diferente. Varíe las estructuras de datos. O las estructuras de control. Prueba diseños extravagantes. Repetir. A menudo, la estructura de código más limpia no es obvia de inmediato y al probar diferentes aproximaciones puede encontrar una mejor solución.

Detecté por mi práctica que escribo un código más claro y simple cuando entiendo completamente el dominio del problema. Desafortunadamente, los clientes a menudo no pueden aclarar exactamente lo que quieren y esta es una situación laboral normal. Si no entendió el dominio, se reflejará en su código. Y si usted es un líder de proyecto, una de sus tareas principales es ayudar al cliente a obtener una nueva visión de la solución comercial que desea que implemente. Por lo tanto, trate de dar más tiempo para un análisis de dominio y le ayudará a escribir código más simple y claro.