Een factor van architectuurverval is het compromis met ontwikkelingskosten
Categories:
Kenmerken van vervallen architectuur zijn: veel speciale afhandeling, compatibiliteitsafhandeling, ernstige koppeling, onomkeerbare last. Architectuur vervalt langzaam. Een vervallen architectuur maakt het moeilijk om nieuwe functies te ontwikkelen, bugs zijn moeilijk te repareren, alles hangt samen, waardoor testen en QA ook moeilijk te doen zijn. Ik zag ooit een bericht van een hobbyist in een andere branche die zei dat het beperken van het abstractiegedrag van het model bij het schrijven van code, de code begrijpelijker maakt. Code die makkelijker te begrijpen is voor mensen, is ook makkelijker te begrijpen voor LLM, dus snelle ontwikkeling en minder fouten. Ik denk dat de hobbyist in een andere branche waarschijnlijk een kleinere projectomvang heeft en gewend is aan lopende-band-logica. Als er verwachting is van schaalvergroting, mag de denkwijze niet beperkt blijven tot de lopende band, maar moet de mentaliteit van een bouwvakker worden gebruikt. Bij de verwachting een gebouw van 30 verdiepingen te bouwen, moet je een fundering van 10 meter slaan; bij de verwachting van water- en elektriciteitsvoorziening, moet je water- en elektriciteitsschachten reserveren. Dit is ontwerp met duidelijke doelen, daarnaast is er ook ontwerp met onduidelijke doelen, zoals ergens in huis later een apparaat plaatsen, maar onzeker welk, dan volstaat een gereserveerd stopcontact. Software engineering kent al de SOLID-principes ter begeleiding van ontwerp. Vaak lijkt het dat bij het volgen van SOLID-principes voor dezelfde functie meer bestanden en meer code worden aangemaakt. Op korte termijn lijkt er voor de baas, tester en gebruiker nauwelijks verschil tussen wel of niet ontwerpen; de voordelen van ontwerp tonen zich pas op lange termijn. Een goede architectuur maakt het makkelijk om functies toe te voegen, te wijzigen, bugs te repareren, en introduceert minder problemen. Ontwerpen vereist vaak meer nadenken dan direct aan de functieontwikkeling beginnen. Bij ontwerpen moet je nadenken over granulariteit; het stopcontactpaneel als tegels over het hele huis plakken is een andere absurde aanpak. Vroeger maakte ik bij ontwikkeling, rekening houdend met de ontwikkelcyclus, compromissen: bij tijdgebrek sloeg ik ontwerp over en voegde wat functies toe, de toekomst zien we later wel. Nu met behulp van AI kunnen we de ontwerpgranulariteit fijner maken; de gegenereerde code is voor mensen moeilijker te lezen, maar de engineering is makkelijker te onderhouden. Met meer abstractie kan een minder goed model het inderdaad slecht aan; gebruik bij voorkeur het beste huidige model. Als je alleen scripts schrijft, is het capaciteitsverschil tussen modellen misschien niet zo duidelijk. Of AI de toegangsdrempel voor ontwikkelaars heeft verlaagd? Ik twijfel daaraan, aangezien het leertraject van nieuwe ontwikkelaars totaal anders is dan vroeger; discussiëren over hoog of laag drempel is misschien zinloos, want we weten niet waar de drempel naartoe is verplaatst.
