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 lo mejor que podría ser, y odio este sentimiento. Terminé pasando el tiempo buscando cosas, pero luego me siento abrumado fácilmente por muchos detalles, como los 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:
Use encapsulation para administrar la complejidad al separar la funcionalidad en bloques de construcción distintos. Demuestre que cada bloque funciona (a través de pruebas unitarias), y puede usarlo sin preocuparse por sus detalles internos.
Aprenda y estudie patrones de software . Los patrones de software son métodos probados y comprobados para realizar ciertas tareas comunes y bien conocidas.
Estudie y comprenda estructuras de datos. Aprenda los usos y las características de rendimiento adecuados para cada tipo de estructura de datos.
Conoce bien tu lenguaje de programación, sus fortalezas y debilidades, y cómo utilizar mejor sus funciones.
No es necesario que sepas todo esto a la vez, pero deberías estudiarlo todo a lo largo del tiempo.
Mi consejo es: deja de preocuparte.
La experiencia es el mejor maestro, y no obtienes experiencia si no escribes el código. Además, el código mal diseñado que está escrito es mejor que el gran diseño que no .
Entonces, escribe más código. Termina tus proyectos. Ese sentimiento de que el código no es ideal es probablemente correcto. Y probablemente tendrás problemas con este código. Y cuando tenga estos problemas, entonces aprenderá por qué fue exactamente malo. Aprendería mucho más de la experiencia de primera mano que de "buscar cosas".
Además, no esperes que este sentimiento de "olor a código" desaparezca. A medida que vaya mejorando, solucionará algunos problemas, pero comenzará a notar otros nuevos, más oscuros / avanzados.
Este es un problema común con los programadores principiantes. No te paralices 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 perfecto y lo suficientemente bueno . Acepte que cada sistema que cree puede mejorarse. Enfócate en terminar tus proyectos. Después de que termines, puedes regresar y mejorarlos. Es por eso que 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ía estar aprendiendo y mejorando todo el tiempo.
Lee libros, toma cursos, califica, trabaja en ello y deberías mejorar.
Mi mejor consejo es centrarse en los aspectos fundamentales, como la lista sugerida por Robert Harvey. El desarrollo de software es un monstruo complejo que demora años en ser remotamente bueno, especialmente en el tema del buen diseño de interfaces. Es realmente difícil apreciar muchos aspectos del desarrollo de software sin experimentarlos primero. Incluso algo tan básico como comentar el código puede ser subestimado. Desde el primer día, le enseñan a escribir código bien documentado. Admito que no lo fue hasta que realmente recibí el código $ que intenté entender, que escribí hace meses, antes de apreciar realmente el valor de los buenos comentarios. Lo mismo puede decirse de muchos conceptos de programación. Por ejemplo, la encapsulación de datos, los módulos de bajo acoplamiento y las interfaces nítidas y limpias.
El recurso más valioso que he encontrado son mis compañeros de trabajo. Vas a escribir mal el código. Sólo acepta eso. Lo que usted hace para asegurarse de que escribe un mejor código a lo largo del tiempo es lo que lo 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 mayor rango y, para ser honesto, me sentí como un idiota durante la mayor parte de mi primer año de trabajo.
El desarrollo de software es una experiencia de aprendizaje continuo. Haga toneladas de preguntas, haga revisar su código, comprenda el por qué de las sugerencias que le dan más personas mayores, no tenga miedo de las preguntas, la validez de las sugerencias que dan los desarrolladores senior y, sobre todo, no tenga miedo de equivocarse. Eventualmente el factor intimación o sensación de ser abrumado por las modas. Para el registro ... aprendiendo curvas apesta.
Eche un vistazo al libro Refactorización: mejora del diseño del código existente , de Martin Fowler. Lo primero que debes hacer es refactorizar tu código para mejorar la legibilidad del código y reducir la complejidad para mejorar su capacidad de mantenimiento.
Cuando refactoriza su código, ya está utilizando 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 The Pragmatic Programmer . El capítulo sobre "Ventanas rotas" describe dónde te ves. 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 respuestas vagas como "solo va por todos lados" o "¿por qué hice eso allí?". Pero tómese el tiempo para ver si hay algún patrón común que haya usado.
Una vez que descubras a dónde quieres ir, toma pasos pequeños y fácilmente reversibles para llegar allí (es decir, esto es lo que Refactoring se trata de). Cada vez que mejore su código, tenga en cuenta el impacto en el resto del código. ¿Has hecho las cosas mejor o peor? Este es al menos mi enfoque para poner orden en el caos.
Si ya tiene algo de experiencia en programación, ¿por qué no estudia algunos proyectos de código abierto que tienen código limpio ? Puede consultar THIS pregunta de SO que tiene algunos enlaces relevantes.
Además, los patrones de diseño son indispensables, piénselo, la idea de tener patrones es resolver problemas conocidos sin reinventar la rueda o escribir código buggy.
Finalmente, parece que necesitas una dosis de programación funcional para despejar la cabeza. Mira en Haskell o Ocaml para empezar.
Si no eres un monstruo peligroso, debes encontrar un llamado amigo , que puede revisar tu código y viceversa. Además, si haces cosas que serán revisadas, o simplemente supervisadas por otros, es una buena presión para hacerlo mejor.
Y no se olvide, la programación comienza antes de la codificación, siempre revise sus ideas, planes. Si tu plan es malo, es un acto de alegría tirarlo: acabas de salvar la frustración de tirar un montón de código (y el momento de su creación) basado en un plan malo.
Mi consejo es tomar en serio cada uno de los olores e intentar solucionarlo. Hay muchos buenos libros sobre el tema (el código limpio y el GOOS son los mejores IMHO). Pero más que libros van a conferencias para escuchar y discutir con otras personas y en comunidades en línea (listas de correo, grupos). Aún mejor, intenta unirte a tu xxug local (dotnetug, jug, xpug, etc.) o encontrar uno.
Discutir con otros programadores es la única forma que conozco de mejorar (a menos que, por suerte, tengas que colaborar con otros programadores dedicados).
Lea otras preguntas en las etiquetas code-quality