Actualmente estoy haciendo una pasantía en una gran corporación y están experimentando muchos cambios en la estructura de entrega de software (mudarse a Agile).
En los últimos meses, he notado este apego religioso a las Clean Codeprácticas y al libro como una biblia para los desarrolladores.
Ahora, una de las características más importantes del código limpio es un código que se explica por sí mismo y que se basa en una denominación comprensible y una refactorización rigurosa. Esto es seguido por la no commentingregla.
Entiendo que este código limpio es una inversión a largo plazo que facilitará el mantenimiento y la mejora del código, pero ... ¿realmente vale la pena todo este alboroto?
¿Alguien compartiría su experiencia sobre Clean Code y cualquier opinión sobre si soy demasiado conservador o si es solo una tendencia temporal?
fuente
CalculateFoonicityMetric()te dice exactamente lo que está haciendo, y un código bien escrito te mostrará cómo ... pero ninguno de estos te dice por qué . El código puede ser obvio en qué (multiplicar esto por eso, dividir por la otra cosa, cuadrarlo, agregar este bit ...) pero no está claro por qué (factor = a * b / c; cuadrado para tener en cuenta foo negativo, ajustar para deriva ...). Agradezco un comentario rápido que explica por qué.Respuestas:
Absolutamente.
Claro, pero tenga en cuenta que la gran empresa probablemente tenga años o décadas de código incorrecto para limpiar. Va a tomar mucho tiempo y esfuerzo hacer eso.
Lo principal a tener en cuenta es que ambos tienen razón. El "código limpio" es muy importante, y Clean Code es una forma universalmente respetada de llegar allí. Dado que la compañía acaba de comenzar en el camino, estarán más comprometidos con el libro que un grupo que tenga más experiencia. Una vez que lo hayan hecho por un corto tiempo, comenzarán a aprender qué funciona y qué no. Una vez que lo entiendan mejor, (con suerte) seguirán un enfoque más pragmático y natural que mantiene un código limpio, pero no conduce a 70 nombres de funciones char.
fuente
Originalmente estaba escribiendo un comentario. Trataré de dar menos respuesta que las perspectivas a considerar. Sin embargo, estoy totalmente de acuerdo con las prácticas de "Código limpio", como los nombres y refactorizaciones comprensibles.
Siempre me desagradaron las reglas de no comentarios , ya que hay casos en los que los comentarios son necesarios para evitar la ruptura futura del código. Normalmente deberían restringirse a lo que se está haciendo y por qué. Úselos con moderación cuando el código esté haciendo algo inesperado, o sea necesario reemplazar un algoritmo.
Considere la productividad cuando esté leyendo o manteniendo código. Durante la vida útil del código, esto puede ser más importante que la productividad al escribir el código. ¿Estas prácticas ayudarán a la productividad en estas tareas?
Con experiencia, estas prácticas deberían arraigarse y ser menos asesinas para la productividad. Elegir el nombre correcto puede llevar más tiempo porque está aclarando lo que debe hacer el código. (Esta aclaración puede acelerar la codificación y la depuración). ¿Esto da como resultado un código que solo hace lo que se requiere o que tiene menos errores? ¿Qué efecto tiene esto en la productividad?
El tiempo necesario para elegir el nombre correcto del método probablemente dará sus frutos de inmediato para comprender mejor cuál es el propósito del método. Compare los nombres de método "iterateOverCustomers" con "localizarActiveCustomers". ¿Cuál transmite la intención de la función? ¿Cuál será más fácil de refactorizar si es necesario?
fuente