- En el software, muchas cosas son inciertas.
- ¿Por qué existe esa incertidumbre?
- La razón principal es la existencia de la complejidad del negocio.
- Debido a esa complejidad, la situación cambia constantemente y, por eso, las predicciones de los desarrolladores fallan con alta probabilidad.
- Una torre construida con mucho esfuerzo se derrumba y se convierte tal cual en deuda técnica.
- Una razón menor es la falta de conocimiento y experiencia.
- Si no hay conocimiento ni experiencia, el propio desarrollador puede crear deuda técnica por sí mismo.
- La complejidad del negocio es un factor externo que el desarrollador no puede controlar, mientras que el conocimiento y la experiencia son factores internos que sí puede controlar.
- Para los desarrolladores, hay tres caminos.
- El camino pesimista que considera inútil enfrentarse a la complejidad.
- Termina diciendo cosas como “de todos modos va a cambiar, así que hagámoslo como sea” o “la tecnología no tiene sentido”.
- Como es un camino cómodo y confortable, uno puede terminar eligiéndolo sin darse cuenta.
- El camino de ignorar la complejidad y pensar solo en ideales imaginarios.
- Cree que todo puede resolverse con una sola tecnología que considera ideal.
- Lleva a una forma de pensar rígida y uniforme.
- Es un camino en el que los desarrolladores pueden caer fácilmente, pero del que es difícil salir.
- El camino de aceptar la complejidad y luchar contra ella.
- Aun aceptando que no se puede alcanzar la perfección, se sigue intentando encontrar una mejor manera.
- Es un camino difícil que hay que soportar.
- El desarrollo de software ha luchado constantemente contra la complejidad.
- Arquitectura, metodologías, ágil, etc.
- ¿Qué aparecerá después?
- Desarrollo orientado a la destrucción
- Si miramos la realidad, es fácil caer en el pensamiento pesimista de que de todos modos todo terminará borrándose.
- Porque es muy doloroso sentir que el código que escribimos con tanto esfuerzo fue un fracaso y borrarlo nosotros mismos.
- Entonces, ¿qué tal si pensamos al revés y hacemos que sea fácil borrar bien?
- ¿La destrucción es algo bueno?
- Sin destrucción, no puede nacer nada nuevo.
- En el software, la destrucción que puede observarse se divide en dos grandes tipos: pivot y refactorización.
- El pivot permite que la organización y el producto elijan un mejor camino.
- La refactorización es algo indispensable para prolongar la vida del software.
- Entonces, ¿qué es el desarrollo orientado a la destrucción?
- Es una metodología de desarrollo que acepta el hecho de que algún día el código será destruido y desarrolla con esa idea en mente.
- Apunta a tres grandes principios.
- Si hay incertidumbre, reducirla tanto como sea posible.
- Si se pueden elegir varios métodos, elegir el que sea más fácil de destruir.
- Mantener solo lo necesario. Por lo tanto, borrar todo lo que no sea necesario.
- Análisis -> separación de límites -> implementación de código -> eliminación de complejidad
- La clave es reducir la incertidumbre causada por factores internos y prepararse para la destrucción provocada por factores externos inevitables.
- Separación de límites
- La incertidumbre es la tasa de cambio, y con base en ella es posible separar.
- El desarrollador debe prepararse para los factores externos y reducir al máximo la tasa de cambio causada por factores internos.
- Como la tasa de cambio de cada factor puede variar según la organización, no es posible expresarla con valores fijos -> se mide con métodos heurísticos.
- ej.) medición con story points
- Hay que decidir el nivel de abstracción según el cual se va a separar.
- Posibilidad de destrucción
- Al implementar, se elige la opción más fácil de destruir según los principios generales.
- La posibilidad de destrucción puede evaluarse considerando independencia, comprensibilidad y controlabilidad.
- La independencia se evalúa por el grado de acoplamiento y cohesión, y por cuánto se respetó el principio de responsabilidad única.
- La comprensibilidad es el grado en que el desarrollador puede ver el código y entenderlo.
- La controlabilidad consiste en determinar si se trata de un área que el desarrollador puede controlar.
- Eliminación de complejidad
- Hay que revisar si existe algo innecesario y eliminarlo. Es decir, al final, en el codebase solo debe quedar lo necesario.
- Si es difícil trabajar en ello por problemas como fechas límite, no pasa nada con dejarlo solo registrado y trabajar después.
- Porque los factores internos son controlables.
- La clave es mantener la simplicidad al máximo para estar preparado para la destrucción.
- Técnicas para destruir código
- Existen varios principios y métodos para borrar bien el código.
- Dividir en etapas (patrón de refactorización)
- Mantener la transparencia referencial
- Respetar el principio de responsabilidad única
- Respetar el principio de segregación de interfaces
- Patrón Strangler Fig
- Especialización de métodos
- Escribir código duplicado
- Registrar la tasa de cambio
6 comentarios
No me convence mucho eso de que la deuda de código se genera por falta de conocimiento y experiencia.
-> Puede que no haya suficiente tiempo para implementar los requisitos, y en casos de trabajo colaborativo también hay situaciones en las que se tolera cierta deuda técnica para mantener la armonía con otras personas; creo que los escenarios son diversos.
Tampoco me queda claro ver el conocimiento y la experiencia como factores internos que el desarrollador puede controlar.
-> Los negocios son complejos y no se puede predecir qué situación va a surgir, así que no es posible estudiar todas las variables en cada momento. Incluso si uno estudia cuando se enfrenta a esa situación, la próxima vez podría aparecer un problema totalmente nuevo y ese conocimiento podría dejar de servir.
Hola. Gracias por compartir su opinión.
Creo que solo cuando observamos los extremos podemos ver por fin la esencia. Desde esa perspectiva, pensé que si uno conociera perfectamente el "conocimiento y la experiencia", podría producir código y no deuda dentro del tiempo disponible.
Que falte tiempo puede dividirse en dos casos. El primero es cuando, literalmente, no hay suficiente tiempo para implementar. En ese caso, independientemente del conocimiento y la experiencia, falta el tiempo físico para escribir el código. Por lo tanto, son condiciones en las que desde el principio es imposible alcanzar el objetivo. El segundo es cuando no hay tiempo suficiente para identificar qué es lo mejor. En esos casos, como no hay tiempo para averiguar cómo implementar o para encontrar una mejor opción, se termina el trabajo escribiendo código solo con el conocimiento que se tiene en ese momento. Cuando se completa el trabajo así, uno sabe que "algo está mal", pero no sabe exactamente cómo corregirlo. Si se hubiera tenido el conocimiento preciso y se hubiera ganado confianza a partir de esa experiencia, este problema no surgiría.
Creo que la falta de tiempo que escribí arriba respalda mi opinión. Por supuesto, en la realidad es un problema muy difícil. Yo solo hablé en términos ideales. Es raro estar en un estado de conocimiento y experiencia perfectos y, como usted mencionó, claramente también hay casos en los que se soporta a propósito por el bien de la organización. Puede haber frustración, pero pensé que, "si lo vemos de forma extrema", este problema surgió por una falta de conocimiento y experiencia.
En segundo lugar, el factor interno que mencionó es simple. "Los negocios son complejos y no se puede predecir qué situación va a presentarse..." Esa parte, en el texto que escribí, corresponde a la "complejidad del negocio". Es decir, es un problema causado por factores externos. Precisamente porque son factores externos, el desarrollador no puede controlarlos y siente temor. También aquí, si lo miramos de forma extrema y asumimos que no existe la complejidad del negocio, lo único que quedaría sería el código escrito por el desarrollador. Entonces solo quedaría el problema de "conocimiento y experiencia", que sí puede controlarse internamente.
Por supuesto, el texto que escribí también es solo mi opinión. Puede haber suficientes contraejemplos. Creo que intercambiar opiniones es una oportunidad para encontrar un mejor camino. Les agradeceré mucho más opiniones en el futuro. Gracias.
Gracias por responder tan amablemente.
Leí el artículo con mucho interés. Parece que, según la etapa de la organización, también cambia qué se considera una optimización prematura y qué se considera sobreingeniería. El punto difícil es que es código que de todos modos habrá que reescribir, pero al mismo tiempo no se sabe si realmente llegará el momento de volver a reescribirlo o no. A veces yo también lo evalúo con la pregunta: si desapareciera el servicio xxx o esa funcionalidad, ¿dónde sería apropiado que estuvieran el código y los datos de yyy? También me da curiosidad conocer los métodos de otras personas.
También suelo pensar si no solo el código, sino también los datos o el esquema pueden desaparecer o cambiarse.
También quería incluir contenido sobre los datos, pero me costó pensar bien cómo abordarlo. Como es una parte crítica, no es fácil tocarla a la ligera, y me daba cautela porque uno puede terminar cayendo en un infierno de migraciones.
Como mencionaste, parece que la etapa inicial de diseño es muy importante; creo que la clave será lograr acumular el RAW lo mejor posible. O, si no, una arquitectura de event sourcing podría ser ventajosa desde la perspectiva de la eliminación. Claro, como nunca he usado realmente esa arquitectura de forma adecuada, no sé si de verdad sería válida.