Puede encontrar esto interesante: cómo las prácticas rotas se convierten en estándar (también creo que habla del último punto en la respuesta de Miles Fidelman).
Como alguien que ha pasado años haciendo programación de mantenimiento, supongo que esto podría ir en ambos sentidos. Estoy de acuerdo con Miles en que la exposición a las buenas prácticas es probablemente la clave. Si realmente ha trabajado en entornos de alto funcionamiento y bases de código de relativamente buena calidad, reaccionará con todo, desde la aversión y la molestia hasta la ira y las lágrimas cuando se enfrente con el tipo de bases de código en las que he estado trabajando. . Por lo general, está claro que la persona que escribe el código probablemente nunca haya visto mejores prácticas. Recuerde que una gran cantidad de problemas en el código y las prácticas heredadas ya tienen soluciones, ¡ pero debe conocerlas!
Ilustrar esto fue un proyecto en el que trabajé reemplazando durante más de un año. Cuando lo heredé, el desarrollador (en realidad era más una actividad secundaria de su trabajo como vicepresidente) ni siquiera estaba usando el control de versiones o un marco, y mucho menos un rastreador de problemas, y la mayor parte de la aplicación era solo copiar y pegar. Era una línea de aplicación comercial de la que dependían una empresa, inversores y sus clientes todos los días, pero era un castillo de naipes. Presumiblemente, si el desarrollador hubiera estado al tanto de los beneficios del control de versiones y el seguimiento de problemas, habría insistido en ellos. Ninguno de los códigos fue utilizable. Todo tuvo que ser reconstruido. Al carecer de especificaciones o pruebas, uno se ve obligado a intentar extraer el significado del código de baja calidad. Aunque he tenido que hacer esto muchas veces, es un trabajo miserable y solo un buen dinero después del mal para el cliente. En este caso, pude hablar con el desarrollador durante un largo período, lo que ayudó considerablemente, pero eso no siempre es posible.
El trabajo de baja calidad, una gran parte, si no la mayor parte del software de producción que existe, es un insulto para los clientes (sin mencionar un tipo de fraude) y para la industria misma. El efecto que esto tiene en mí es redoblar mi insistencia en no cortar esquinas.
El último proyecto en el que he estado trabajando subraya esto ya que me fue entregado sin ninguna documentación, historial de versiones, especificaciones o antecedentes, y probablemente ni siquiera era la última versión del código. Fue una relación de outsourcing que salió mal, por lo que no hubo acceso a los desarrolladores anteriores. Ese proyecto es un material horrible de nivel junior; Todos lo hemos visto. Aparentemente, el error más inevitable que cometen los programadores de bajo grado es olvidar que no se trata de arrojar el código y volver a casa. El software tiene que ser mantenido. Alguien lo posee. Alguien pagó muy caro por ello. O van a obtener valor por dinero, o el dinero (y su carrera) se va a evaporar lo suficientemente pronto. También es pura hipocresía. Cuando un programador acude al dentista, esperan que el dentista haga todo lo posible para hacer un relleno que dure, no se desmorone y se caiga. Es lo que les pagas por hacer. Sin embargo, veo mucho código escrito por personas que no ejercen la misma atención y responsabilidad profesional que esperan de todos los demás con quienes tratan. ¿De qué manera es eso sostenible?
En resumen: para crecer y desarrollarse, asegúrese de estar constantemente desafiado a mejorar su práctica de ingeniería de software, todos los días. No cortes esquinas. Trabaje con personas y mentores más experimentados que se dedican a la calidad y la facilidad de mantenimiento en su trabajo, de manera que pueda verlo usted mismo. Verificar los beneficios de mejores prácticas. Véndelos a sus gerentes y clientes con evidencia. Identifique y sea honesto acerca de los defectos en nuestras herramientas. Nunca te enamores de una herramienta; ¡Incluso tu idioma favorito tiene problemas! Identifique esos problemas * y busque soluciones. A su vez, enseña a tus colegas †. Asegúrese de que los desarrolladores que hereden su código estén encantados con él. Piensa constantemente en lo que estás dejando atrás. Como industria debemos levantar nuestro juego, evidentemente un desarrollador a la vez.
Aquí hay otro artículo que puede resultarle útil: algunas cosas que pueden ayudarlo a mejorar el software
* —La respuesta de Toby Thain a ¿Cómo funciona Python perfectamente para Quora si Python no es bueno para proyectos a gran escala y otras desventajas? – Para ampliar esto, aquí hay cosas que puede comenzar a hacer de inmediato: por cada defecto que encuentre o se le informe, ejercite los Cinco por qué para profundizar en su causa raíz. Luego pregunte, ¿cómo podría haberse evitado? ¿Qué podemos hacer para evitarlo la próxima vez? ¿Y qué lo haría más fácil de arreglar? Para características: pregunte qué haría que esta característica sea más fácil de construir. Cada vez que una tarea parece demasiado compleja, agrega riesgos o no funciona correctamente, pregunte ¿Por qué? como un niño curioso
† —Peter Seibel en Twitter