Absolutamente, pero hay algunos casos extremos a considerar.
Se tarda mucho más en agregar funciones y encontrar errores en una gran bola de espagueti.
El código realmente malo tiene nombres que no están claros, lo que te hace mirar en el lugar equivocado. Tiene entornos de trabajo para errores; entonces, el error off-by-one en la línea 1,216 se compensa agregando uno en las líneas 3,372 y 5,453. Si corrige el error por un error, olvidará cambiar esas líneas. Luego encontrará que algún otro código se basa en una de esas líneas que están allí. El código podrido se ondula y es difícil de reemplazar.
- ¿Puedo saber sobre la facilidad de E-Infobook proporcionada por algunos bancos comerciales en India?
- ¿Existe un software de asistencia horaria que cambia el turno de los empleados automáticamente en función del primer registro del día?
- ¿Qué opciones de voz a texto hay para alguien con parálisis cerebral?
- Si 'el software se está comiendo el mundo', ¿por qué las empresas no tecnológicas subcontratan su desarrollo de software personalizado?
- ¿Qué aplicación usas más? ¿Qué hace?
El código verdaderamente mal diseñado se basa en efectos secundarios, soluciones, casos de “no me importa” y flujos de ejecución de código accidentales para funcionar. Cualquier cambio a esto romperá inocentemente y en silencio este código. Para saber por qué, debe ir más allá de leer el código, que no le dirá. Debe leer detrás del código y comprender qué suposición oculta es responsable.
Diría que este tipo de trabajo lleva 10 veces más tiempo que trabajar con código limpio. ¿Quizás una definición diferente del programador “10x”?
Pero hay dos advertencias importantes:
- Algún código es descartable, en cuyo caso esto no es tan malo. Tíralo y comienza de nuevo.
- Todo el código se vuelve más complejo No importa cuán limpio sea su diseño, su código se llena de características. Las características agregan complejidad del comportamiento condicional o capas adicionales de abstracción. Una vez que agreguemos el decimoséptimo código de descuento, tenemos diecisiete si se trata de ramas, o un subsistema de “precios” más abstracto. Ambos son más difíciles de entender, porque el dominio del problema es más difícil de entender.
Es tentador decir ‘mantenga limpio su código, no hay problemas’. Pero, si bien estoy de acuerdo con el código limpio, es mi gran cosa, en realidad, no es garantía de que no te ahogues en la complejidad.
