Como el legendario escritor Jules Verne comentó acertadamente: "Un mínimo bien utilizado es suficiente". En nuestra era, el concepto de un mínimo bien utilizado se aplica al código. Triste pero cierto: en el mundo moderno del código hay demasiado. Para ser más precisos, hay demasiado código innecesario, entre los cuales el código útil es simplemente sofocante.
Dado lo anterior, el código innecesario es malo por defecto. Se deteriora con el tiempo. Requiere apoyo continuo. Contiene errores que debes buscar. Cuando aparecen nuevas funciones, el código antiguo debe adaptarse a ellas. Mientras más código tenga, más errores puede tener en él. Cuanto más tiempo lleve la verificación o la compilación, más tiempo comprenderá el sistema el nuevo empleado.
Y además de todo este salto, el código está escrito por programadores. Cuanto más es, más se requieren programadores. A medida que aumenta el número de programadores, también lo hace el costo de la comunicación entre ellos, lo que contribuye aún más al costo de desarrollar y mantener el código.
Para todos estos problemas, hay una solución: escribir menos código. Este enfoque tiene muchas ventajas:
- Menos código para desarrollar = menos costos de desarrollo
- Menos código en desarrollo = menos costos de mantenimiento
- Menos código en desarrollo = menos errores
- Menos código para desarrollar = pruebas más eficientes
Y lo más importante: cuanto menos código obligue a las personas a leer, mayor será la probabilidad de que alguien lo lea.
Aquí hay algunas formas en que puede reducir el código.
El principio YAGNI ("No lo necesitas")
El principio "No lo necesita" (a menudo se lo conoce como YAGNI - No lo va a necesitar) significa la siguiente regla de programación extrema: "Aproveche esta o aquella oportunidad solo cuando sea realmente necesaria, y no cuando asuma que la necesitarán pronto ". Incluso si está cien por ciento seguro de que esta función no se puede realizar en el futuro, no comience a implementarla ahora.
Hay dos razones para esta práctica:
- Ahorra tiempo al negarse a escribir código que no se necesita actualmente.
- La calidad del código mejora: no lo contamina con fragmentos que se basan en conjeturas más o menos correctas, y permanece en la base del código, incluso si estas conjeturas no están confirmadas.
El concepto de YAGNI es bastante razonable sin importar a qué metodología de gestión de proyectos se adhiera. La buena arquitectura requiere un equilibrio equilibrado de posibilidades. La mala arquitectura está compuesta por un montón de funciones esbozadas que generan una base de código que está atormentado para admitir.
La regla básica aquí es: concéntrese en lo que claramente se necesita y no piense en lo que probablemente sucederá.
No escriba código invulnerable
Un código invulnerable es un código ideal, un código que funcionará bajo cualquier dato de entrada y bajo cualquier condición. La idea de crear algo similar tiene su propio atractivo, especialmente para los desarrolladores ambiciosos que perciben el fracaso en algún escenario como un insulto personal. Sin embargo, escribir (o intentar escribir) código invulnerable es una idea vacía, porque todo en el mundo tiene su propio límite, y el código no es una excepción.
Al tratar de implementar el módulo ideal, prescribirá condiciones adicionales, agregando así complejidad al código base, lo que va en contra del propósito del código. El módulo se volverá más y más extenso con el tiempo, consumirá más recursos y se convertirá en un candidato para un mantenimiento descuidado.
Es por eso que, si pretende escribir menos código, debe esforzarse por la implementación más simple posible, desde la categoría de "si solo funcionara".
La Guía de programación extrema menciona dos reglas de oro para escribir código simple:
- Primero, implemente la nueva funcionalidad de la manera más primitiva que solo puede funcionar. No erige superestructuras impresionantes, no te refines, solo asegúrate de que todo comience. Asegúrese de que el código pase las pruebas unitarias para la nueva funcionalidad (y también para las antiguas, como siempre).
- Luego, y esto es una parte crítica de la regla, refactorice el sistema y simplifique el código tanto como sea posible para todas las funciones que actualmente están contenidas en el producto. Siga el principio DRY y otros principios que ayudan a que el sistema esté más ordenado.
No lo olvide: no buscamos el camino más corto, sino el resultado más simple.
En consecuencia, comenzamos dividiendo el método existente en varias partes. En este caso, las opciones de prueba funcionarán sin fallas. Luego cambiamos (en la dirección de la simplificación) uno de los pequeños métodos resultantes con un ojo en la siguiente opción de prueba y así sucesivamente.
Recuerde que la simplicidad está en el corazón de la elegancia. La capacidad de controlar y eliminar la complejidad innecesaria es una programación magistral.
No empeores el código
Esta regla puede considerarse el juramento hipocrático para los desarrolladores. Aquellos involucrados en la programación escuchan constantemente consejos para no cortar esquinas y no buscar soluciones que puedan dañar el código y conducir a su degradación.
Los procedimientos de desarrollo de software, como los procedimientos médicos, a menudo implican interferencias graves y acciones destructivas. Además, las herramientas y técnicas que utilizamos son a menudo nuevas y no verificadas (o insuficientemente verificadas). Además de eso, no tenemos un análogo del Consejo de Licencias Médicas o la Oficina de Control de Productos que regiría las prácticas y las herramientas de desarrollo que elijamos. Por lo tanto, a veces exponemos a nuestro paciente, es decir, el software, a procedimientos asociados con riesgos innecesarios, y ni siquiera entendemos completamente cuáles son estos riesgos.
A veces, en el proceso de solucionar un problema, hacemos más daño que bien. En su libro "Código perfecto", que es parte de la literatura dorada para programadores, Steve McConnell escribe que si no trabajas en la raíz del problema, sino en su síntoma, solo empeoras la situación: te estás engañando a ti mismo, creando la ilusión de que el problema está resuelto .
Pero a veces observar esta regla puede ser muy difícil. A veces, el código desactualizado se encuentra en tal estado que es prácticamente imposible implementar adecuadamente una nueva funcionalidad sin dañarla. Por lo tanto, para ser más realista, debe reformular un poco la regla: de "No empeore el código" a "Si degrada la calidad del código, debe ser consciente de lo que está haciendo".
Eso es correcto Si no ve una manera de implementar las funciones necesarias y no estropear el código, advierta a otros miembros del equipo antes de realizar cambios. La conclusión es que, en este caso, degrada la calidad del código intencionalmente.
Por supuesto, esto no mejorará el código incorrecto, pero así tendrá tiempo para pensar en la situación. La experiencia muestra que las personas a menudo no alcanzan la solución óptima simplemente porque están listas para aceptar la primera idea que les viene a la mente. Tenga en cuenta que no es necesario que solicite permiso o ayuda para encontrar la mejor solución.
Otra ventaja de este método es que reduce la probabilidad de sorpresas desagradables en los malos momentos: todo el equipo sabe qué problemas deben esperarse. Gracias a esto, puede trabajar en equipo en el sentido completo de la palabra y lidiar con esta situación de manera oportuna.
Evitar concurrencia excesiva
La concurrencia es una espada de doble filo. Debe recurrirse solo si no puede prescindir de él.
Cuando el código se ejecuta secuencialmente, es más fácil de entender y buscar errores. Cuando se usa concurrencia, las operaciones se realizan simultáneamente o en un orden distorsionado. Esta implementación específica crea muchos problemas para identificar y corregir errores. Obviamente, complica la arquitectura y la implementación de funciones a la vez en varios niveles. Aquí hay algunos problemas que la concurrencia mal implementada puede causar:
- Condición de carrera: las operaciones comienzan a ocurrir de manera impredecible
- Bloqueo mutuo: los objetos involucrados se cruzan mientras esperan que se completen las operaciones simultáneas
- Falta de recursos: la operación de manera estable no obtiene acceso al recurso necesario que espera
Uno de los desastres de más alto perfil asociado con el desarrollo de software fue causado precisamente por condiciones interdependientes prescritas incorrectamente. Un error de programación con Therac-25, un aparato de radioterapia, provocó la muerte de cuatro personas.
Cabe señalar que la mayoría de los lenguajes y marcos de programación modernos proporcionan herramientas especiales para depurar la concurrencia. Pero, en última instancia, todo depende del desarrollador: es él quien decide cuándo, dónde y cómo aplicarlos para lograr el mejor resultado.
No choques contra el acaparamiento
El acaparamiento patológico es un tipo de comportamiento caracterizado por la recolección de una gran cantidad de cosas innecesarias y la falta de voluntad para deshacerse de ellas; sin embargo, las cosas pueden ocupar la mayor parte del espacio vital, lo que puede provocar lesiones y estrés.
Cuando los síntomas de acumulación aparecen entre los desarrolladores, comienzan a aferrarse a cualquier parte del código, incluso si ya está desactualizado o lleno de errores. Dichos desarrolladores nunca eliminan el código ellos mismos y generalmente se oponen a esta práctica. Si les cuenta esto directamente, obtenga respuestas en el espíritu: "Puede que algún día sea necesario" o "Sin esto, no puedo realizar la operación X" y así sucesivamente.
¿Te ha atacado alguna vez el síndrome de Plyushkin? ¿Quizás abandonaste la idea de poner las cosas en orden porque entiendes que simplemente no tienes tiempo suficiente para resolver todo este desastre? Si es así, aún sufres de acaparamiento y reina el caos en tu vida laboral.
Ahorrar es irracional. Si le parece que la presencia de algún código está justificada, pero no está completamente seguro de ello, márquelo en consecuencia para que pueda volver a él más tarde. Por lo tanto, no se te caerá de la memoria. En cuanto al código, que no cumple un propósito específico y no es vital, debe ser eliminado y el punto.
Un buen programador está trabajando para mejorar el código día a día y, con el tiempo, la calidad del código crece constantemente. El código obsoleto escrito por un buen programador siempre se destaca por su precisión: los profesionales no dejan un lío detrás de sí mismos; Después de todo, el código es nuestra reputación y serán ellos quienes nos juzgarán por él. Como dijo correctamente Robert Martin: "La verdad solo se puede encontrar en el código".