Una de mis actividades favoritas como profesional del software es borrar el código. Con el tiempo, he aprendido que es una de las mejores cosas que puedo hacer porque la cantidad ideal de código es ningún código en absoluto .
Si se puede entregar valor sin escribir ningún código, se evitan los costes de desarrollo y mantenimiento.y no habrá ningún error de software! Un ejemplo fantástico de esto viene del pragmático Dave Thomas1. Una compañía tenía problemas con su correo al no llegar a los departamentos adecuados. Querían un sistema complejo de OCR para enrutar su correo, pero él sugirió que en su lugar podían usar sobres de color.No se necesitaba ningún código y la compañía ahorró mucho dinero.
El código es una responsabilidad
Por supuesto, necesitamos algo de código porque el software puede ofrecer un valor increíble. Pero ese valor viene de lo que el código hace o permite. El código no es intrínsecamente valioso, sino que es una responsabilidad.
Una vez que se tiene el código, los desarrolladores deben entenderlo. Es necesario actualizarlo cuando los requerimientos cambian. Puede tener errores. Estas cosas traen riesgos y pueden ralentizar un negocio de software. Incluso el código más perfecto puede volverse problemático cuando el mundo cambia a su alrededor. Los cambios en los lenguajes, marcos, paradigmas o sistemas operativos pueden añadir una carga al código que, por lo demás, es bueno.
Ya que necesitamos código, necesitamos manejar el riesgo. He encontrado que las dos cosas más grandes que los desarrolladores de software pueden hacer son:1. Mejorar la calidad del código2. Manejar el tamaño de la base de código
La calidad del código y el tamaño de la base de código están altamente correlacionados. Tener demasiado código disminuye la calidad del software ya que se hace más difícil de entender y manejar el tamaño total. Por otra parte, la calidad también se ve afectada si se tiene muy poco código. O bien no hay suficiente código para proporcionar el valor necesario o el código se vuelve innecesariamente difícil de leer y mantener.
La cantidad correcta de código es un problema de optimización. En general, se quiere que la base de código sea pequeña en relación con el valor de la característica que se proporciona, pero no tan pequeña que empiece a violar los buenos principios de diseño.
Borrar el código
En la mayoría de las bases de datos de código hay mucho espacio para mejorar la calidad y reducir el riesgo mediante el borrado de código. Sin embargo, hay que ser disciplinado en la forma en que se borra:
La refactorización del código debe utilizarse para mantener su calidad alta y su tamaño pequeño. Puede hacerse mientras se escribe el código (prefiero hacerlo continuamente como parte integral del bucle de desarrollo impulsado por pruebas) o puede hacerse para mejorar el código existente.
Desafortunadamente, no todo el código proporciona valor. Algunas características no se utilizan lo suficiente en el software para justificar su existencia, por lo que deberían ser eliminadas. Peor aún, el código «muerto» acecha en muchas bases de código, distrayendo y confundiendo a los desarrolladores sin llegar a ser ejecutado.
Lean y Mean
El desarrollo de software Lean reconoce que el código es una forma de inventario, y por lo tanto un potencial desperdicio. Así que adelgaza! Deshazte del exceso! Como un régimen de ejercicio, no será fácil pero los resultados hablan por sí mismos.
Me gusta particularmente esta cita sobre el tema de Michael Feathers:
Código de refactorización para maximizar lo bueno y reducir lo malo. ¡Borra sin piedad el código que no está proporcionando valor!
- Escuché esta historia relatada por Neal Ford en el podcast de la Radio SE (32 minutos). ?
- Esta definición del término «refactorización» viene del bliki de Martin Fowler. Él literalmente escribió el libro sobre ello. ?
Categorías: prácticasEtiquetas: código limpio, magro