Un factor de la corrupción de la arquitectura es el compromiso con el costo de desarrollo
Categories:
Las características de una arquitectura corrupta son: gran cantidad de manejo especial, manejo de compatibilidad, acoplamiento severo, carga acumulada difícil de revertir. Todas las arquitecturas se corrompen lentamente. La arquitectura corrupta dificulta el desarrollo de nuevas funciones, los bugs son difíciles de corregir, un cambio afecta a todo, lo que hace que las pruebas y QA también sean muy difíciles de realizar. Una vez vi a un aficionado al desarrollo de otro sector publicar que, al limitar el comportamiento de abstracción del modelo al escribir código, el código es más fácil de entender. El código que las personas entienden más fácilmente, los LLM también lo entenderán más fácilmente, por lo que se puede desarrollar rápidamente y reducir errores. Supongo que los desarrolladores de otro sector probablemente tienen proyectos pequeños y están acostumbrados a una lógica de línea de producción; si hay expectativas de escalar, la forma de pensar no puede limitarse a la línea de producción, sino adoptar la mentalidad de un trabajador de la construcción. Si se espera construir un edificio de 30 pisos, es decir, hay que hacer una base de 10 metros; si se espera suministro de agua y electricidad, es decir, hay que reservar pozos de agua y electricidad. Este es un diseño con objetivos claros; además, hay diseños con objetivos poco claros, como cuando en algún lugar de la casa se colocará un electrodoméstico en el futuro pero no se sabe cuál, basta con reservar un enchufe. La ingeniería de software ya cuenta con los principios SOLID para guiar el diseño. Muchas veces, en apariencia, seguir los principios SOLID para lograr la misma funcionalidad requiere abarcar más archivos y escribir más código; a corto plazo, el diseño y la falta de diseño parecen casi iguales para el jefe/pruebas y el usuario, y los beneficios del diseño solo se ven a largo plazo. Una buena arquitectura facilita agregar funciones, modificarlas, corregir bugs e introduce menos problemas. El pensamiento que requiere el diseño suele ser mayor que el de desarrollar directamente la funcionalidad; el diseño requiere considerar la granularidad. Pegar paneles de enchufes por toda la casa como si fueran azulejos es otro absurdo. Antes, al desarrollar, consideraba el ciclo de desarrollo y hacía concesiones: cuando el tiempo apretaba, ni siquiera diseñaba, solo añadía algunas funciones y listo, lo del futuro se vería luego. Ahora, con la IA, podemos hacer la granularidad del diseño más fina; el código generado será más difícil de entender para los humanos, pero el proyecto será más fácil de mantener. Tras aumentar la abstracción, es cierto que los modelos peores podrían no manejarlo bien; es mejor usar el mejor modelo actual. Si solo se escriben scripts, la diferencia de capacidad entre modelos puede no ser tan evidente. Sobre si la IA ha reducido la barrera de entrada para los desarrolladores, lo dudo; después de todo, la ruta de aprendizaje de los nuevos desarrolladores es muy distinta a la del pasado, y discutir si la barrera es alta o baja puede no tener sentido, porque no sabemos a dónde se ha movido la barrera.
