Estoy en mi primer trabajo real como programador y lo que veo es solo el código "Big Ball of Mud" (sin comentarios útiles también), pero me gusta hacer código limpio, y es muy difícil para mí codificar de una manera peor.
Estoy buscando un caso de estudio donde el uso de código limpio (veo varias definiciones aquí de lo que es código limpio) mejoró el desarrollo y la capacidad de mantenimiento.
Un rápido (pero de ninguna manera exhaustivo) search de Google Scholar aparece una gran cantidad de artículos que hacen referencia a Bob Martin's Clean Code , pero personalmente no he visto ningún documento que cubra una correlación entre "Clean Code "y mejor desarrollo.
Sin embargo, piensa en tu pregunta por un momento. Está preguntando sobre un desarrollo mejorado, y eso en sí mismo es un área temática muy amplia que se cubre no solo mediante la escritura de un mejor código, sino también por muchos otros factores como la comunicación, la gestión de expectativas, la metodología y la racionalización de procesos, las pruebas, la integración continua y la verdad. la caja completa y los dados cuando se considera la cantidad de elementos necesarios para que un proyecto de desarrollo de software sea exitoso, y mucho menos para mejorarlo.
Entonces, tu pregunta debería ser: ¿la escritura de código limpio contribuye a mejorar el desarrollo del software? Para responder a eso, la única "evidencia" que podría proporcionar sería completamente anecdótica, y para eso creo El libro Clean Code sería una excelente referencia, ya que no solo está escrito por Bob El mismo Martin, pero también con muchos capítulos contribuidos por algunos de los desarrolladores de software más inteligentes que existen. Si eso no ayuda, entonces quizás se aplique un poco de lógica fría y dura.
Si haces un desastre en tu casa y nunca llegas a limpiarla, vivir en tu casa se convertirá en una tarea difícil. Se vuelve más difícil encontrar cosas, más difícil moverse, y nadie en su sano juicio querrá visitarte si vives en un entorno sucio. Lo mismo también con el código. Si su código es un desastre, le resulta más difícil localizar los problemas, y mucho menos solucionarlos. Se vuelve más fácil justificar una solución alternativa que podría no hacer el trabajo, pero bueno, es mejor que tener que vadear todo ese viejo legado de mierda, ¿verdad? Al final, al igual que nunca ordenar su casa, permitir que su código se vuelva desordenado le costará tiempo y esfuerzo, y le creará dificultades a largo plazo. Sin embargo, mantener su código limpio le proporcionará una mejor plataforma para trabajar, hará que la refactorización y la depuración sean una tarea menos complicada y requerirá que se preocupe con menos frecuencia sobre si podrá mantener su código fácilmente con el tiempo.
No, no tengo evidencia directa para darles, y estos son simplemente los pensamientos de alguien que ha estado haciendo esto durante mucho tiempo, y que, con suerte, se ha ganado un poco de sabiduría de desarrollo de software en el camino. :-)
Lo que hay que entender es que ninguna compañía se propone escribir un código mediocre. El problema es que el 50% del código, más o menos, lo escriben los programadores de su empresa que se encuentran por debajo del promedio. Usted está predicando al coro cuando expone los beneficios del código limpio. El truco es cómo hacerlo. Investigue un poco sobre cosas como herramientas de revisión por pares, análisis estático, pruebas automatizadas, integración continua, TDD, scrum, programación extrema, etc. y presente soluciones potenciales en lugar de solo explicar por qué el problema es malo.
Sé que esto irá en contra del grano aquí, pero es hora de comercializar, cumplir con los requisitos, contar con la financiación adecuada, la buena comercialización, el precio correcto y la buena suerte tienen mucha más influencia en el éxito de los productos de software que en la calidad del código .
Esto es NO para decir que la calidad del código debe ignorarse, pero debes reconocer que es solo uno de los muchos factores.
Hay muchos ejemplos de código simplemente horrible en productos sumamente exitosos (por ejemplo, el sistema operativo original de Apple que dejó su gestión de subprocesos a las aplicaciones).
No puedo pensar en ningún ejemplo de código hermoso que supere un producto mal concebido o sobrevaluado.
Entonces, si es el momento de comercializar en comparación con un código bonito, ¡el tiempo de comercialización debe tener prioridad!
Debe separar el código limpio de los objetivos reales: reducir el costo de la reparación de defectos después de la implementación y reducir el trabajo innecesario. Cuando hablas de "escribir código limpio para hacer que tenga menos errores", estás hablando de religión. Cuando se habla de "reducir la tasa de defectos en un 10%, ahorrando 2 meses-hombre de esfuerzo en el proyecto", estamos hablando de administración. El código limpio es una herramienta para mejorar la calidad inicial de la base de código y, por lo tanto, reducir el costo total, pero es uno de muchos.
El siguiente documento explica por qué hacerlo bien la primera vez es importante desde una perspectiva de costos: enlace
No tengo conocimiento de ningún estudio específico, pero revise el trabajo realizado por Steve McConnell .
Si alguien lo tiene, lo hará. Por ejemplo, un escaneo de dos minutos encontró esto (16 años, pero aún hoy es relevante).
Para agregar a la respuesta de mattnz, si aún no lo ha dicho, consulte específicamente Código completo: Un manual práctico de Construcción de software por Steve McConnell. Además del hecho de que probablemente mejorará su codificación, cita numerosos estudios a lo largo del libro sobre cómo varias prácticas de codificación afectan la calidad de los programas.
Como ejemplo (del libro):
Otro estudio de 450 rutinas diferentes (lo cual es solo una inusual coincidencia) encontró que las rutinas con el mayor acoplamiento a cohesión los ratios tenían 7 veces más errores que aquellos con los más bajos relaciones de acoplamiento a cohesión y fueron 20 veces más costosas de arreglar (Selby y Basili 1991).
También solía ser la respuesta número uno a la pregunta ¿Cuál es el libro más influyente que todo programador debería leer? (aunque veo que las respuestas a esta pregunta se reorganizaron recientemente de forma coja)
Lea otras preguntas en las etiquetas clean-code case-studies