De consistentie van code en/of het volgen van een bepaald stramien heeft hier een rechtstreekse invloed op.
Zal misschiens wat voorbeelden geven wanneer consistentie een probleem is, bedoel dus niet dat elke developer de dingen oplost zoals hij het graag ziet
Dus hou u vast voor een hoop gezaag
Stel dat we een WPF applicatie gaan maken
bv MVVM, no code behind, seperation of concerns, ge hebt dus echte No Code Behind puristen
Om in een complex project totaal geen code behind te hebben kost meer tijd, pragmatischer om het soms wel te doen
Allez dat zeggen de developers achter visual studio toch die met het hele MVVM gedoe zijn afgekomen
Stel dat we dan DDD gaan doen want welja we hebben domain logic
Dus we maken een hoop laagskes en interfacekes aan, als we dan een combo op het scherm zetten
en die moet gewoon gevuld worden zonder enige nood aan "domain logic" gaat die dan zoals de rest ook consistent door al die laagskes?
zoja --> anemic domain model, extra werk, extra kosten
(om maar een voorbeeld te geven project dat ik ken, om een combo toe te voegen op een form (dus enkel tonen) moeten 10 files aangepast worden)
We gebruiken een ORM
we moeten iets doen dat die ORM niet goed kan,
bv we moeten een vrij zware Batch-verwerking doen 10.000+ records die gesaved en gechecked moeten worden naar de database
We doen het consistent aan de rest -> minder goede performance
We doen het consistent en gebruiken het framework -> framework is er niet voor geschikt maar we zien dit als een 'extra uitdaging' -> extra tijd nodig om het goed te krijgen, niet zeker als het ooit goed komt
We gebruiken een stored procedure, niet consistent, maar duidelijk, en snel
Niets zo gemakkelijk om een hoop best practices te volgen en alles consistent te doen
Afhankelijk van de applicatie en de context weten wanneer het beter is om bepaalde dingen soms "niet consistent" op te lossen
of in te zien dat bepaalde "best practices" of "design patterns" niet genoeg meerwaarde gaan geven is juist de moeilijkheid
