Un fattore della corruzione dell'architettura è il compromesso sul costo di sviluppo
Categories:
Le caratteristiche di un’architettura corrotta sono: molti trattamenti speciali, gestione della compatibilità, forte accoppiamento, peso accumulato difficile da recuperare. Tutte le architetture marciscono lentamente. Un’architettura corrotta rende difficile sviluppare nuove funzionalità, correggere bug è difficile, toccare una parte ne muove altre, rendendo anche test e QA molto difficili da fare. Ho visto un appassionato di sviluppo trasversale postare che limitare il comportamento di astrazione del modello quando scrive codice rende il codice più facile da capire. Il codice che le persone capiscono più facilmente, anche l’LLM lo capirà più facilmente, permettendo uno sviluppo rapido e riducendo gli errori. Immagino che gli sviluppatori trasversali abbiano probabilmente progetti più piccoli, abituati alla logica a flusso, se c’è l’aspettativa di scalare, il modo di pensare non può limitarsi al flusso, ma deve usare la mentalità dell’operaio edile. Aspettarsi un edificio di 30 piani, cioè bisogna fare fondamenta di 10 metri, aspettarsi acqua ed elettricità, cioè bisogna riservare pozzi per acqua e elettricità. Questo è un design con obiettivo chiaro, inoltre c’è il design con obiettivo non chiaro, come in un punto della casa si metterà in futuro un elettrodomestico, ma non si sa quale, basta riservare una presa. L’ingegneria del software ha già i principi SOLID per guidare il design, spesso in apparenza, seguire i principi solid per implementare la stessa funzionalità richiede di attraversare più file, scrivere più codice, a breve termine il design e il non-design per capo/test/utente sembrano quasi identici, i benefici del design si vedono solo a lungo termine. Una buona architettura rende facile aggiungere funzionalità, modificarle, correggere bug, e introdurre meno problemi. Il pensiero necessario al design è spesso maggiore dello sviluppo diretto della funzionalità, il design richiede di considerare la granularità, incollare pannelli presa ovunque come piastrelle è un altro assurdo. In passato quando sviluppavo consideravo il ciclo di sviluppo, facevo compromessi, quando il tempo stringeva non facevo nemmeno il design, aggiungevo qualche funzione e finivo, il futuro si vedrà poi. Ora con l’AI, possiamo rendere la granularità del design più fine, il codice generato sarà più difficile da capire per l’uomo, ma l’ingegneria sarà più facile da mantenere. Aumentando l’astrazione, i modelli peggiori potrebbero davvero non gestirla bene, meglio usare il miglior modello attuale. Se si scrivono solo script, la differenza di capacità tra modelli potrebbe non essere troppo evidente. Sul fatto che l’AI abbassi la soglia di ingresso per gli sviluppatori? Ne dubito, dopo tutto il percorso di apprendimento dei nuovi sviluppatori è ormai molto diverso dal passato, discutere se la soglia sia alta o bassa potrebbe non avere senso, perché non sappiamo dove sia stata spostata.
