Hoy es un día soleado. Conduces por el camino hacia tu pueblo donde viven todos tus amigos, tu familia y tu querido perro. Un dia maravilloso! De repente escuchas un terrible grito de pesadilla desgarrando los alrededores. ¡La enorme y repugnante Hydra se acerca al pueblo para destruirlo! Agarras una espada (¡por supuesto, tienes una espada!) Y tratas de proteger a todos los que amas. Pero hay un pequeño problema: el monstruo tiene muchos objetivos, y cuando cortas uno de ellos, ¡uno nuevo crece rápidamente!
Parece que no puedes ganar esta batalla. ¿Quizás puedas jugar con Hydra el tiempo suficiente para que toda la aldea tenga tiempo de escapar de una terrible amenaza? ¡Finalmente, te convertirás en un verdadero héroe del mundo entero! ¿Quién no quiere esto?
El papel de Hydra es la entropía en el software: es tu enemigo, él te está agotando, pero nunca puedes deshacerte de él por completo. Pero aún necesita luchar con él para que sus aplicaciones (y colegas) permanezcan sanas y sanas.
Descubriremos:
- ¿Qué es la entropía en el software y cómo notarlo en su código?
- ¿Cuáles son sus posibles causas y cómo mantener baja la entropía?
¡Basta de hablar, hasta el punto!
Conoce a tu enemigo
¿Qué es la entropía y cómo terminó en mi aplicación?
A veces es útil averiguar la etimología de las palabras utilizadas, especialmente las específicas como la entropía. Traducido del griego, significa "transformación". Cambio. Algo a lo que debería acostumbrarse como desarrollador de software.
La entropía se refiere a la segunda ley de la termodinámica. Dice que en un sistema cerrado y aislado, la cantidad de caos no disminuye con el tiempo. Se mantiene estable o en crecimiento.
La idea de la entropía en el software surgió a través del libro
Ingeniería de software orientada a objetos . Cuanto más cambia el programa, más caos tiene, aumenta su entropía.
Lo primero que los desarrolladores pobres deben dejarnos en claro es la trágica verdad: podemos combatir la cantidad de entropía en nuestros programas, pero nunca podemos deshacernos de ella.
Crea el mejor equipo (¡con tu participación, por supuesto!), El mejor entorno, la mejor gestión, la mejor cultura de la empresa, el mejor proyecto. ¿Qué pasará con el tiempo?
- Usted tarareará todas las mañanas, "¡Este es el mejor proyecto!" Un proyecto verde que parece un hermoso campo, iluminado por un maravilloso amanecer.
- Usted y el equipo agregarán más y más funciones. Como eres el mejor de los mejores, por un tiempo todo se ve genial.
- Pasarán meses o años. Ya nadie quiere trabajar en un proyecto. Incluso si estaba bien diseñado, la tecnología está desactualizada, el proyecto requiere demasiado esfuerzo y tiempo para comprenderlo, es costoso de escalar. Es demasiado difícil construir su buen modelo mental.
¿Cómo creaste esta complejidad? Solo necesitas escalar el proyecto. Más elementos a menudo significan más dependencias y mayor complejidad. Ya escribí un
artículo detallado sobre esto.
Si le explicas esto a Lyokha, tu compañero desarrollador, él responderá:
"Nifiga! Eres un tonto ¡El caos y el desorden no tienen cabida en mi hermosa aplicación! ¡Mi reputación no se verá empañada por tonterías! ¡Soy el dueño de mi destino! Si no cambio mi programa, entonces la complejidad no crecerá, y en relación con esta prueba de la contradicción, ¡declaro que estás equivocado y que soy el mejor!
Puede explicar con calma, de manera convincente y decisiva a Lyokha que, incluso si no cambia el programa, todo lo que lo rodea cambiará. Si tiene bibliotecas de terceros que no se actualizan, habrá problemas de seguridad. Y si los actualiza, se abrirá la puerta al cambio y la entropía.
Además, si un día
necesita cambiar algo en su software después de mucho tiempo, no recordará todos los detalles. E incluso la mejor documentación no te ayudará. El mundo ha cambiado, y lo que ayer era cierto puede que nunca sea cierto, tanto a nivel tecnológico como a nivel comercial.
Tales cambios a la vez traen una gran cantidad de entropía.
Entonces, la cuestión no es deshacerse de él, sino con moderación. Esta es una verdadera batalla en la que estamos inmersos los desarrolladores.
Definición de entropía en software
Calidad del software
¿Cómo descubrir que su aplicación tiene un alto nivel de entropía? Un buen indicador es la calidad del código.
¿Qué es y cómo medirlo? Según
Accelerate: The Science Behind Devops :
- Si la proporción de cambios / fallas aumenta, entonces la calidad disminuye. Rastree cambios, errores y fallas, compárelos entre sí. Si cada cambio conduce a nuevos errores o fallas, entonces la entropía en su programa aumenta.
- La percepción subjetiva del proyecto juega un papel importante por parte de los desarrolladores. Si todos tienen la sensación de que cada vez es más difícil escalar la aplicación sin romperla, entonces la entropía probablemente sea alta. Sin embargo, esta sensación debería ser común.
- Si el equipo pasa mucho tiempo reparando errores o recuperándose de fallas, entonces la entropía debe haber anidado en su aplicación.
Si puede obtener información sobre la correlación de cambios y fallas, y dedicar tiempo a corregir errores, puede llegar a un buen cronograma para convencer a la gerencia de la necesidad de algún tipo de refactorización.
Demonio de dificultad
Incluso si tiene un código de la más alta calidad, la complejidad puede aumentar fácilmente cuando se trata de las capacidades del programa. El negocio en sí es una fuente de la
complejidad necesaria de la que no puede deshacerse.
Dada la excesiva complejidad del negocio, los desarrolladores tendrán que hacer un gran esfuerzo para construir un buen
modelo mental del negocio de la empresa. Por lo tanto, cometerán errores al tratar de traducir los requisitos comerciales en código.
Hablemos con más detalle sobre la complejidad del negocio: ¿realmente necesitamos todas estas características complejas que nos decepcionan?
La razón de la entropía y cómo lidiar con ella.
Cascada de entropía
El problema
Más o menos obvio, la principal causa de entropía en el software son los propios desarrolladores. Son flojos, carecen de calificaciones, especialmente de Sanka, con quien trabajas. ¡Hace tantas preguntas!
Estoy totalmente en desacuerdo con esta opinión. En mi experiencia, la razón principal de la entropía es el liderazgo, especialmente en empresas con un estilo de gestión de cascada.
Como
Gerald Weinberg señaló en
The Secret of Consulting :
Incluso si se trata de un problema puramente técnico, su origen siempre se remonta a la acción o inacción de la administración.
Sé lo que pensaste: “¡Estás equivocado! ¡La gerencia no siempre es responsable de todo! ¡Es conveniente para los desarrolladores culpar a los jefes por todo!
No digo que el liderazgo sea el culpable de todo, pero él siempre tiene
cierto grado de responsabilidad . ¿El desarrollador hizo algo malo? Necesita revisar el proceso de contratación. Las especificaciones fueron mal implementadas? Quizás algunos de los líderes no saben lo que realmente quieren y, por lo tanto, las especificaciones no le importan.
Por lo tanto, ¡es tan difícil ser un líder! Cuanto más alto seas en la jerarquía, más difícil será.
Como desarrolladores, ¿cuánto influyen en la toma de decisiones? Si es 100%, entonces felicitaciones, usted tiene la culpa de todo. Si al 0%, entonces tu culpa no es. Entre estos polos se encuentra todo el espectro de influencia. Y la cascada no implica una gran cantidad de ella.
¿Usando Scrum, Kanban y Poker Planning? ¡Por supuesto que no usas la cascada! Utiliza Agile como un niño construye una casa con un destornillador.
Por supuesto, las herramientas son importantes, pero su importancia es
mucho menor que la importancia de su forma de pensar , que es necesaria para el correcto desarrollo del software. Para citar el manifiesto ágil:
Las personalidades y las interacciones son más importantes que los procesos y las herramientas.
Usar Scrum no significa que esté usando Agile, especialmente si no tiene la forma de pensar que esta metodología está tratando de enseñar.
Con la gestión de cascada, alguien más alto que tú toma una decisión, más arriba, otras personas toman nuevas decisiones, y así sucesivamente.
En los niveles inferiores de la jerarquía están los empleados cuya maldición es seguir todas las decisiones tomadas. ¿Cuál es su tarea? Para hacer, como si los trabajadores en la línea de montaje de una fábrica de automóviles. No necesitan pensar,
tienen que hacer autos .
Malas noticias: como desarrollador, estarás en la parte inferior de la jerarquía.
Si alguien en la parte superior toma decisiones con respecto a las funciones de la aplicación, y prácticamente no tiene la oportunidad de influir en el proceso de toma de decisiones, ¡bienvenido a la cascada! Desafortunadamente, la mayoría de la alta gerencia no ve que
en el mundo del desarrollo de software no haya una fase de producción . Los desarrolladores se dedican al
diseño del sistema , y esta tarea está lejos del montaje del transportador de la cabina.
Por qué Porque, a diferencia de un automóvil, las aplicaciones cambian constantemente. Debe
diseñarlos correctamente para que funcionen, satisfagan las necesidades de los usuarios, que las aplicaciones tengan un rendimiento aceptable, que sean escalables y resistentes a los cambios, al tiempo que mantienen la entropía en un nivel bajo. Para hacer esto, debe tomar muchas
decisiones sobre cómo
reflejar el conocimiento empresarial en su código.
Si no afecta la complejidad que le corresponde a usted el liderazgo, tendrá que dedicar mucho esfuerzo a administrarlo en el código. Esto se considerará una complejidad "necesaria": una que no se puede evitar.
Posible resultado? Los niveles de entropía pueden crecer muy, muy rápido.
Posible solución
La empresa necesita practicar la toma de decisiones y la responsabilidad conjunta de la forma más activa posible.
Si reconoce a su empresa en el modelo de cascada que describí, entonces necesita hablar con quienes toman las decisiones:
- Proporcione datos y argumentos sólidos sobre por qué y cómo simplificar la función X o Y. Explique el posible precio de desarrollar una función compleja ahora y en el futuro .
- Explique por qué el desarrollo ágil de software significa que las personas necesitan trabajar juntas. Los gerentes, diseñadores, desarrolladores y todos los demás deberían ser parte del proceso de toma de decisiones según los requisitos del negocio.
- Si su liderazgo rechaza automáticamente la oferta, entonces debe comprender por qué lo hizo. Haz preguntas
- Hable sobre lo que los tomadores de decisiones consideran más importante: dinero y tiempo. Muéstreles que el pensamiento de estilo ágil (y no solo las herramientas) puede salvarlos a ambos.
Sin embargo, es difícil tratar de resolver el problema si no se le ha preguntado al respecto. Muchos gerentes están muy satisfechos con el modelo de cascada y, a menudo, ni siquiera saben que lo están siguiendo. Necesitará mucha diplomacia y tacto.
Dado todo esto, si siente que las soluciones comerciales agregan demasiada complejidad a su aplicación y que no puede hacer nada al respecto, incluso si lo intenta, le aconsejo que busque otro trabajo. Es agotador: trabajar con alta entropía todos los días y hacer un producto hinchado de placer no es suficiente ... o usarlo. Esto puede darle una pista sobre el éxito que espera su producto.
Y lo último: lo que puede parecer complicado a nivel comercial puede simplificarse si conoce bien los procesos comerciales. Esto es extremadamente importante. Por lo tanto, aprenda más sobre las actividades de su empresa, lo que están haciendo y lo que no están haciendo, esto ayudará a simplificar las características y la base del código.
Cuando expresamos nuestra arquitectura, explicamos algo a la computadora. Y para esto necesitamos entender bien lo que explicamos.
Látigo de DonaldCódigo de calidad y deber técnico
El problema
Además de la complejidad "necesaria" introducida por el negocio, la entropía en el software está estrechamente relacionada con la calidad del código y la deuda técnica.
¿Qué es la deuda técnica? En pocas palabras, estas son simplificaciones (hacks) que usa para ahorrar tiempo, sabiendo que más tarde esto puede volver a usted. Especialmente en los casos en que otras características dependen de estos hacks: tendrá que solucionarlo con interés, como con una deuda real, en forma de dificultades y dolor de cabeza.
Dependiendo de la tarea de su aplicación, la deuda técnica puede ser más o menos aceptable. Si el programa debe vivir un par de meses, entonces no puede pensar en deuda técnica, entropía o calidad. ¡Solo junta las piezas de código y listo!
Por ejemplo, esta puede ser una solución temporal antes de crear una aplicación más compleja desde cero. O bien, puede escribir rápidamente un prototipo para ilustrar la idea y luego reescribir todo o abandonar el concepto.
Por otro lado, las empresas generalmente desean desarrollar aplicaciones de mayor duración. Esto es razonable: reescribir una aplicación puede ser muy costoso (especialmente si es grande), y nadie puede garantizar que su nivel de entropía sea más bajo. Copiar es un negocio muy arriesgado.
En tales casos, debe tener mucho cuidado con el deber técnico y la calidad del código. Esta es una parte importante de su trabajo como desarrollador.
En el famoso libro
The Pragmatic Programmer (en el que, entre otras cosas,
se introduce el
principio DRY ), se da una analogía interesante de la deuda técnica. Aquí se describe un estudio que compara la destrucción de edificios urbanos con ... ventanas derribadas. La ventana rota da la impresión de abandono, inspirando a cada matón en el área. Como resultado, los edificios con ventanas rotas se vandalizan más rápido que los edificios con ventanas enteras.
La deuda técnica es una simplificación o pirateo de su código, una ventana rota. Cuando otro desarrollador, o incluso usted mismo en el futuro, note esto, habrá una tentación de agregar aún más deudas técnicas, porque "todavía hay un código incorrecto aquí, entonces, ¿por qué tomar un baño de vapor?
Ejemplo: escribió una solución alternativa para un error complejo, porque no había tiempo para buscarlo. Otro desarrollador (o usted mismo más adelante) además de esta solución alternativa puede escribir un código diferente, resolviendo otro problema. Las capas de soluciones alternativas que nadie descubrirá muy rápidamente crecerán.
Solución
Primero, ¿cómo saber si un código tiene una deuda técnica?
Pregúntate a ti mismo:
- ¿Puedo explicar simple y lógicamente lo que hace el código?
- ¿Se usan los nombres correctos aquí? ¿Ayudan a explicar lo que hace el código?
- ¿Se aplican nombres largos con "y", como "deleteUserAndShutDown"? Esta es una buena señal de que necesita separar una función, método u otra construcción.
- ¿Siente que se agregó algún código debido a la pereza? ¿Viola la lógica y perjudica la comprensión?
Cuanto más crezca su conocimiento y experiencia, más curiosidad tendrá y más a menudo mantenga conversaciones saludables con otros desarrolladores, más a menudo notará patrones de deuda técnica. Este es un
código con un estrangulador .
Cuando encuentre tales patrones, no los considere como un permiso para agregar aún más deuda técnica:
- Un aumento en la duración técnica dará lugar a nuevos problemas. Volverán y te perseguirán a ti (y a tu equipo) aún más.
- Habiendo cumplido una deuda técnica, refactorícela. Esta es la mejor opción. Si no tiene el tiempo o la energía, simplemente agregue un comentario // TODO: refactorizar por esta y esa razón. Informe un problema, no lo deje oculto en la base del código.
No olvide que necesita refactorizar en paralelo con el desarrollo de otras características para que coincidan con la arquitectura actual. En pocas palabras, la reparación de la deuda técnica no debe ser una tarea independiente, sino un proceso continuo que puede no estar relacionado con la tarea actual. Al desarrollar una función, concédete el derecho de corregir la deuda técnica encontrada.
Refactorice pequeños fragmentos de código a la vez y, a menudo, ejecute pruebas para asegurarse de que el sistema se comporta como se esperaba.
Finalmente, durante la refactorización, es posible que necesite algunos buenos argumentos:
- Primero, por ti mismo. Es fácil pensar que su colega no puede programar y que usted lo sabe mejor que otros. Pero si no ve los beneficios específicos de la refactorización, entonces no lo vea. Quizás todo está solo en tu ego, y puedes arruinar algo.
- Si la refactorización está relacionada con el estilo del código, significa que su equipo no lo ha definido claramente . Tenga una reunión y decidan juntos qué estilo de código desean adoptar. Esto deberá escribirse en alguna parte, para que todos puedan manejarlo según sea necesario. Edite el acuerdo de acuerdo con las necesidades del equipo. De lo contrario, su código estará lleno de comentarios como "¡usamos pestañas!" NO ESPACIOS !!!!! 11! 1 !!! ". Este es un ruido inútil.
- Finalmente, si alguien le pregunta por qué cambió su hermoso código, tendrá argumentos reales para explicar su decisión.
Los buenos argumentos siempre juegan un papel positivo en el futuro. Por ejemplo, envolviendo una biblioteca de terceros para que no cause una fuga en su base de código. Si no comprende por qué estoy hablando de una fuga, lea lo
que escribí sobre abstracciones .
Es difícil para nosotros los humanos hacer pronósticos a mediano y largo plazo. Por lo tanto, no siempre es fácil refactorizar o "vender" algo con la vista puesta en un futuro desconocido.
El deber técnico refleja el dualismo entre el camino
simple y el
correcto . El primero es rápido y atractivo, el segundo hará que su proyecto sea escalable y fácil de mantener. Necesitará
autodisciplina para elegir el segundo camino con la mayor frecuencia posible. De lo contrario, el futuro estará lleno de sufrimiento.
Si está demasiado cansado, molesto o lleno de otros pensamientos o emociones que reducen su motivación para seguir el camino correcto, y no el camino simple, entonces es mejor no programar todavía. Salga a caminar, hable con colegas, tome un descanso. Regrese al código con cerebros frescos.
Muy a menudo, la deuda técnica se agrega durante la depuración. Si corrige un error
agregando una solución alternativa, entonces no ha solucionado nada. El error persiste, es más difícil de ejecutar y encontrarlo accidentalmente. Debe corregir los errores mediante la
refactorización , el
cambio o la
eliminación completa
del código. Luego pruebe el código para asegurarse de que el error no vuelva a ocurrir.
Por último: culpar a los colegas por los errores es improductivo. Si habla mal o sarcásticamente sobre su base de código, esto tampoco resolverá los problemas, solo empeorará la situación. No destruyas el espíritu de equipo. Debe reducir la entropía en el proyecto y no destruirla verbalmente.
Pruebas automatizadas
El problema
Hay algo fascinante para mí en el mundo mágico del desarrollo de software, especialmente en las startups: muchos programadores todavía no quieren escribir pruebas automatizadas.
¿Por qué me fascina? En todas las demás áreas de la ingeniería, prueban lo que hacen siguiendo un proceso riguroso. Cuando construyes un cohete, necesitas probar muchos sistemas, o el cohete caerá. Lo mismo ocurre con los automóviles, puentes, aviones, cualquier cosa.
Ahorrando dineroUn ejemplo simple: la
NASA está probando a fondo su código (ver la regla 5) .
, , ,
.
, , .
. .
, , — , . ? , . , , ( ), , - .
, : ,
. ,
.
, .
Solución
, , , .
.
- 1,3 . , . «» .
:
, , - ( ), :
- . , , .
- . , , - .
- . — , .
- , - . , - . !
- , . !
,
.
, . , . , .
, , .
.
, , . , , - .
, , . , , :
, . , . . , , , - , .
— , .
, .
,
:
. , , .
?
— . - , . , .
Eso es todo! , .
, , .
, , : « , , ? , . !».
: , . , . , .
, , , . , , . !
. :
, . , . , , .
, , . ?
, . , , .
:
- , . «, ?» — , « ! ! !».
- , . , , , , . «, , ?» « , 289 ».
, . ,
!
( !) .
. , , .
, — , , . !
!
, , , ,
. ? ? - ? ?
. , . -, . , , , .
, , . . — .
Entonces ?
- — . . , .
- — .
- . / .
- , , .
- , . , .
- Cree una atmósfera que facilite el intercambio de conocimientos entre sí mediante la programación conjunta, el análisis de código o simplemente estableciendo enlaces a fuentes de información interesantes (artículos, libros).
El software ideal no existe. La entropía siempre será parte de nuestro trabajo. Esto no significa que ya hayamos perdido esta batalla. ¡Esto significa que reducir la entropía en toda la base de código ya es una victoria!Enlaces utiles: