Elegir entre crear deuda técnica e incumplir los plazos de entrega es una falsa dicotomía, argumentó Daniel Terhorst-North en la charla Best Simple System So Far de GOTO Copenhague. A los programadores les gusta generalizar en lugar de resolver el problema inmediato, lo que puede dificultar cambios futuros. En cambio, necesitamos desarrollar las habilidades y los instintos para mantener las cosas simples.
Muchos programadores sienten que tienen que hacer concesiones constantemente, acumulando deuda técnica para cumplir con un plazo o retrasando los plazos establecidos por la gerencia o los empresarios para tener tiempo de «hacerlo bien»:
Con los compromisos y las decisiones de diseño correctos, puede tener un producto que se pueda enviar en todo momento, manteniendo al mismo tiempo el listón de calidad lo suficientemente alto.
El actual Best Simple System (BSSN) cumple tres características, explica Terhorst-North:
- No contiene código extraño o especulativo, que es todo lo que se necesita por ahora («Simple»). El diseño está «preparado para el futuro» porque es muy fácil realizar cambios, no porque hayamos colocado puntos de extensión donde pensábamos que las cosas podrían cambiar.
- cumple con todo actual («por ahora»), ignorando o posponiendo cuidadosamente necesidades futuras.
- Cualquier código contenido en él está escrito según un estándar apropiado («Mejor»). Para el código de producción, esto significa telemetría, pruebas automatizadas, documentación de API, puesta en marcha automatizada, etc. Para los «bocetos» en los que explora ideas, el listón puede ser más bajo. Pero en cualquier caso, no hay excusa para nombres deficientes, complejidad innecesaria (archivos fuente grandes, métodos o funciones difíciles, estructura de archivos deficiente, etc.) que los «buenos hábitos» no pueden solucionar.
Terhorst-North citó la descripción de Terry Pratchett de las habilidades requeridas de una bruja en una de sus novelas de fantasía de Mundodisco, Wintersmith:
Primera Vista y Segundos Pensamientos, eso es en lo que una bruja tenía que confiar: Primera Vista para ver lo que realmente hay allí, y Segundos Pensamientos para verificar que los Primeros Pensamientos estaban pensando correctamente.
Por ahora, diseñar implica primera vista: ver lo que realmente hay allí, dijo Terhorst-North:
¿Necesitamos un motor de reglas, o es sólo media docena de sentencias if en un baúl? ¿Kubernetes alojado en Azure es la plataforma de implementación adecuada para su aplicación web interna con sus 10 usuarios?
A los programadores les gusta generalizar, lo que introduce capas de complejidad que hemos aprendido a ignorar. Terhorst-North dijo que hemos perdido la primera vista. Esto puede dificultar los cambios futuros, especialmente si van en una dirección que no anticipamos.
El consejo de Terhorst-North para mantener las cosas simples es simplemente intentarlo, sabiendo que te equivocarás una y otra vez. Pensarás demasiado, codificarás e indexarás demasiado en una dirección u otra mientras desarrollas las habilidades y los instintos para mantener las cosas absurdamente simples.
Son principalmente los malos hábitos y los comportamientos aprendidos los que nos impiden diseñar sistemas simples basados en fundamentos, explica Terhorst-North:
Como programador con décadas de experiencia, tengo un ego enorme y creo que sé mucho sobre programación, por lo que me resulta difícil admitir que estaré cerca pero equivocado cada vez que intento predecir la dirección futura de un producto o código base.
Aunque intenta cumplir con las convenciones BSSN cada vez que escribe código, Terhorst-North descubre que piensa demasiado o diseña demasiado una solución «por si acaso»:
¡La única manera que he encontrado es practicar, practicar, practicar! En mi caso, encuentro que soy mucho más honesto a la hora de emparejar; mi pareja me impide hacer un baño de oro o desafía mis suposiciones sobre hacia dónde vamos a continuación, de una manera que me mantiene encaminado.
Antes de que te des cuenta, están inmersos en otra optimización que nunca necesitarán, o en agregar una interfaz o un punto de flexibilidad que nunca usarán, concluye Terhorst-North.
InfoQ entrevistó a Daniel Terhorst-North sobre el mejor sistema simple que existe.
InfoQ: Usted desaconsejó predecir el futuro de cualquier forma. ¿Por qué?
Daniel Terhorst-Norte: Este es el corazón del diseño por ahora. Un producto puede cambiar de cualquier forma, en cualquier momento y por cualquier motivo. Yo las llamo «dimensiones del cambio».
A continuación se muestran algunos ejemplos:
- Hay muchos tipos de informes, pero hemos elegido una herramienta de informes de dominio específico que es altamente flexible y no puede conectarse a todas estas fuentes de datos adicionales.
- Muchas variantes del mismo informe, pero agregar una nueva variante es costoso y requiere mucho tiempo porque lo hemos bloqueado por «motivos de rendimiento».
- La complejidad de los informes ha aumentado a medida que el cumplimiento requiere la procedencia de los datos, pero esto ralentizará drásticamente la generación de informes, ya que hemos optimizado la escala en lugar del detalle.
- En su lugar, queremos un panel de control, por lo que el «informe» se evaluará dinámicamente.
Estos no son hipotéticos; ¡Todo esto me ha pasado a mí! Cualquiera de estos futuros posibles que anticipemos o anticipemos en nuestro diseño, estamos haciendo concesiones frente a otros e introduciendo complejidad de forma totalmente especulativa.
Mi posición es que la clave para una verdadera «flexibilidad» y «escalabilidad» es mantener las cosas lo más simples posible para que uno pueda concentrarse en el próximo cambio, cualquiera que sea.
InfoQ: ¿Qué se puede hacer para mantener nuestros sistemas simples y mejores?
Terhorst-Norte: Proclamo «finge hasta lograrlo», o más bien «hazlo a tu manera para una nueva forma de pensar». No se puede convencer a nadie de que es posible mantener un sistema de forma continua, ni de que cualquier cambio futuro será más fácil cuanto más simple sea el código base; tienen que experimentarlo ellos mismos, muchas veces. Irónicamente, cuanto más experimentado es el ingeniero, más difícil le resulta creer que debería No predecir la próxima dimensión del cambio. Después de todo, ¿no es ese el objetivo de toda esta experiencia?
I ya no Obsesionarme con si tengo el diseño «correcto». Tengo suficiente confianza en mis hábitos (TDD, control de versiones, refactorización, código «borrador») como para poder revertir malas decisiones con la suficiente rapidez e ir en una dirección diferente. También me he enseñado a mí mismo a no creer en mi monólogo interior cuando me dice que «sabe» lo que viene.
