¿Qué debo hacer cuando huele mi código?

Soy un programador novato y, a menudo, cuando trabajo en mis propios proyectos, siempre tengo la sensación de que el diseño de mi código no es el mejor posible, y odio esta sensación. Termino pasando tiempo buscando cosas, pero luego me abrumo fácilmente con muchos detalles, como patrones de diseño para elegir y cuándo usar una clase abstracta o una interfaz. ¿Se supone que debo intentar aprender un poco de todo a la vez?

Algunas sugerencias

1. Utilice la encapsulación para gestionar la complejidad separando la funcionalidad en distintos bloques de construcción. Demuestre que cada bloque funciona (a través de pruebas unitarias), y puede usarlo sin preocuparse por sus detalles internos.

2. Aprende y estudia patrones de software . Los patrones de software son métodos probados y comprobados para realizar ciertas tareas comunes y bien conocidas.

3. Estudiar y comprender estructuras de datos. Aprenda los usos apropiados y las características de rendimiento para cada tipo de estructura de datos.

4. Conozca bien su lenguaje de programación, sus fortalezas y debilidades, y cómo usar mejor sus características.

No tiene que saber todo esto a la vez, pero debe estudiarlo todo con el tiempo.

Mi consejo es: deja de preocuparte.

La experiencia es el mejor maestro, y no obtienes experiencia si no escribes código. Además, un código mal diseñado que está escrito es mejor que un gran diseño que no lo está .

Entonces, escribe más código. Termina tus proyectos. Esa sensación de que el código no es ideal probablemente sea correcta. Y probablemente tendrá problemas con este código. Y cuando tenga estos problemas, entonces aprenderá por qué exactamente fue malo. Aprendería mucho más de la experiencia de primera mano que de "buscar cosas".

Además, no espere que esta sensación de "olor a código" desaparezca. A medida que mejore, solucionará algunos problemas, pero comenzará a notar nuevos, más oscuros / avanzados.

Este es un problema común con los programadores principiantes. No se paralice pensando que todo tiene que ser perfecto. Esa es la forma más segura de nunca terminar un proyecto. Una de las habilidades más importantes para aprender como desarrollador es la diferencia entre lo perfecto y lo suficientemente bueno . Acepte que cada sistema que cree puede mejorarse. Concéntrese en terminar sus proyectos. Después de que termines, puedes regresar y mejorarlos. Por eso tenemos la versión 2.0, después de todo.

¿Se supone que debo intentar aprender un poco de todo a la vez?

Espero que no. Por otro lado, deberías estar aprendiendo y mejorando todo el tiempo.

Lea libros, tome cursos, califíquese, trabaje en ello y debería mejorar.

Mi mejor consejo es centrarse en los fundamentos como la lista que sugirió Robert Harvey. El desarrollo de software es un monstruo complejo que lleva años incluso llegar a ser remotamente bueno, especialmente en el tema del buen diseño de la interfaz. Es realmente difícil apreciar muchos aspectos del desarrollo de software sin experimentarlos primero. Incluso algo tan básico como comentar código puede ser menospreciado. Desde el primer día, se le enseña a escribir código bien documentado. Admito que no fue hasta que realmente me metí en un código de comprensión $$ que escribí hace meses antes de que realmente apreciara el valor de los buenos comentarios. Lo mismo puede decirse de muchos conceptos de programación. Por ejemplo, encapsulación de datos, módulos de bajo acoplamiento e interfaces nítidas y limpias.

El recurso más valioso con el que me encuentro son mis compañeros de trabajo. Vas a escribir mal el código. Solo acepta eso. Es lo que haces para asegurarte de escribir un código mejor con el tiempo lo que te define como programador. Por ejemplo, cuando comencé a trabajar, mi empresa no tenía ningún tipo de código formal o procedimientos de revisión de diseño. Me encargué de someter mi trabajo a las críticas de mis compañeros de trabajo más antiguos y, para ser honesto, me sentí como un idiota durante gran parte de mi primer año de trabajo.

El desarrollo de software es una experiencia de aprendizaje continuo. Haga toneladas de preguntas, revise su código, comprenda el por qué de las sugerencias que hacen las personas mayores, no tenga miedo de cuestionar la validez de las sugerencias que dan los desarrolladores mayores y, sobre todo, no tenga miedo de equivocarse. Finalmente, el factor de intimidación o la sensación de estar abrumado de modas. Para el registro ... las curvas de aprendizaje apestan.

• Primero: refactorización (todavía olerá pero estará un poco más organizado)
• Segundo: vea si puede usar un patrón de diseño para hacer que las piezas refactorizadas coincidan con su lógica.
• Tercero: cuando las cosas empiecen a verse mejor, recuerde el tiempo que pasó haciendo el primer y segundo paso. De esta manera, cuando escriba alguna característica nueva, lo considerará mientras lo hace y no como otro proceso.

Eche un vistazo al libro Refactoring: Mejorando el diseño del código existente , por Martin Fowler. Lo primero que debe hacer es refactorizar su código , para mejorar la legibilidad del código y reducir la complejidad para mejorar la facilidad de mantenimiento del mismo.

Cuando refactoriza su código, ya está usando Patrones de diseño , código de encapsulación , etc.

Este es uno de los mejores libros que he leído sobre este tema. Proporciona muchas recetas útiles.

Un buen recurso es el programador pragmático . El capítulo sobre "Ventanas rotas" describe dónde te ves a ti mismo. La respuesta breve y concisa es solucionar los problemas.

Cuando comienzas a arreglar tu diseño, te ayuda a entender lo que no te gusta de él. Es fácil encontrar las respuestas vagas como "simplemente va por todas partes" o "¿por qué hice eso allí?". Pero tómese el tiempo para ver si hay algún patrón común que haya utilizado.

• Un buen diseño reutilizará una pequeña cantidad de conceptos en toda la base de código (lo ideal es un concepto, pero en la práctica puede necesitar un par más)
• Un buen diseño facilitará determinar dónde solucionar los problemas (principio DRY, principio SRP)
• Un buen diseño tendrá un buen informe de errores (relacionado con el punto anterior, pero llamado como un elemento separado porque es un aspecto que a menudo se pasa por alto)

Una vez que descubra a dónde quiere ir, tome pequeños pasos fácilmente reversibles para llegar allí (es decir, de esto se trata la Refactorización ). Cada vez que mejore su código, considere el impacto en el resto del código. ¿Hiciste las cosas mejor o peor? Este al menos es mi enfoque para llevar el orden al caos.

Si ya tienes experiencia en programación, ¿por qué no estudias algunos proyectos de código abierto que tienen código limpio ? Puede consultar ESTA pregunta desde SO, que tiene algunos enlaces relevantes.

Además, los patrones de diseño son obligatorios: piénselo, la idea de tener patrones es resolver problemas conocidos sin reinventar la rueda o escribir código con errores.

Finalmente, parece que necesita una dosis de programación funcional para despejar la cabeza. Mira a Haskell u Ocaml para empezar.

Si no eres un monstruo peligroso, deberías encontrar un supuesto amigo , que pueda revisar tu código, y viceversa. Además, si está haciendo cosas, que serán revisadas o simplemente supervisadas por otros, es una buena presión hacerlo mejor.

Y no olvide, la programación comienza antes de la codificación, siempre revise sus ideas, planes. Si su plan es malo, es un acto alegre deshacerse de él: acaba de salvar la frustración de tirar un montón de código (y el momento de su creación) en base a un mal plan.

Mi consejo es que tome cada uno de los olores en serio e intente solucionarlo. Hay muchos buenos libros sobre el tema (código limpio y GOOS son los mejores en mi humilde opinión). Pero más que libros van a conferencias para escuchar y discutir con otras personas y en comunidades en línea (lista de correo, grupos). Aún mejor, intente unirse a su xxug local (dotnetug, jarra, xpug, etc.) o encuentre uno.

Discutir con otros programadores es la única forma en que sé mejorar realmente (a menos que tenga la suerte de trabajar junto con otros programadores dedicados).