¿Existe un estudio de caso que demuestre de manera convincente que el código limpio mejoró el desarrollo? [cerrado]

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 un código limpio, y es realmente difícil para mí codificar en un peor camino.

Estoy buscando un caso de estudio en el que el uso de código limpio (veo varias definiciones aquí de qué es código limpio) mejoró el desarrollo y la facilidad de mantenimiento.

Una búsqueda rápida (pero no exhaustiva) de Google Scholar muestra muchos artículos que hacen referencia al Código limpio de Bob Martin , pero personalmente no he visto ningún documento que cubra una correlación entre el "código limpio" y el desarrollo mejorado.

Sin embargo, piense en su pregunta por un momento. Usted está preguntando sobre el desarrollo mejorado, y eso en sí mismo es un área temática muy amplia que se cubre no solo escribiendo un código mejor, 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, pruebas, integración continua y realmente toda la caja y los dados cuando considera cuántas cosas se necesitan para que un proyecto de desarrollo de software sea exitoso, y mucho menos mejorarlo.

Entonces su pregunta probablemente debería ser: ¿escribir código limpio contribuye a mejorar el desarrollo de software? Para responder a eso, la única "evidencia" que podría proporcionar sería completamente anecdótica, y para eso creo que el libro Clean Code sería una excelente referencia, ya que está escrito no solo por el propio Bob Martin, sino también con muchos capítulos contribuidos por algunos de los desarrolladores de software más inteligentes que existen. Si eso no ayuda, entonces tal vez podría aplicarse una lógica fría y dura.

Si hace un desastre en su hogar y nunca llega a limpiarlo, entonces vivir en su hogar será una tarea difícil. Se vuelve más difícil encontrar cosas, más difícil moverse, y nadie en su sano juicio querrá visitarlo si vive en un ambiente sucio. Lo mismo también con el código. Si su código es un desastre, le resulta más difícil localizar 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, seguramente supera tener que atravesar todo ese viejo legado, ¿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, hacer que la refactorización y la depuración sean menos complicadas,

No, no tengo pruebas directas que brindarle, 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 en el desarrollo de software . :-)

Lo que debe comprender es que ninguna compañía se propone escribir código mediocre. El problema es que el 50% del código, más o menos, está escrito por los programadores inferiores a la media de su empresa. Estás predicando al coro cuando expones 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 posibles soluciones en lugar de simplemente explicar por qué el problema es malo.

Sé que esto irá en contra del grano aquí, pero el tiempo de comercialización, la obtención de los requisitos correctos, la financiación adecuada, el buen marketing, el precio correcto y la buena suerte tienen mucha más influencia en el éxito de un producto de software que la calidad del código.

Esto NO quiere decir que se deba ignorar la calidad del código, pero debe reconocer que es solo uno de los muchos factores.

Hay muchos ejemplos de código simplemente horrible en productos de gran éxito (por ejemplo, el sistema operativo Apple original que dejó su gestión de hilos a las aplicaciones).

No puedo pensar en ningún ejemplo de código hermoso que supere un producto mal concebido o demasiado caro.

Entonces, si es hora de comercializar frente a un código bonito, ¡la comercialización debe tener prioridad!

Debe separar el código limpio de los objetivos reales: reducir el costo de corregir los defectos después de la implementación y reducir el reprocesamiento innecesario. Cuando hablas de "escribir código limpio para que tenga menos errores", estás hablando de religión. Cuando habla de "reducir la tasa de defectos en un 10% ahorrando 2 meses-hombre de esfuerzo en el proyecto", habla de gestió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: http://www.cs.umd.edu/~mvz/pub/eworkshop02.pdf

No conozco ningún estudio específico, pero revise el trabajo de Steve McConnell .

Si alguien lo tiene, lo hará. Por ejemplo, un escaneo de dos minutos encontró esto (16 años pero todavía es relevante hoy).

Para agregar a la respuesta de mattnz, si aún no lo ha hecho, diría que consulte específicamente Code Complete: A Practical Handbook of Software Construction de Steve McConnell. Además del hecho de que probablemente mejorará su codificación, cita numerosos estudios a lo largo del libro sobre cómo las diversas prácticas de codificación afectan la calidad de los programas.

Como ejemplo (del libro):

Otro estudio de 450 rutinas diferentes (que es solo una coincidencia inusual) encontró que las rutinas con las relaciones de acoplamiento a cohesión más altas tenían 7 veces más errores que aquellas con las relaciones de acoplamiento a cohesión más bajas y eran 20 veces más costosas 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 una manera poco convincente)