Beh, si vede se qualcuno ha realizzato la stessa cosa o simile, come l’ha fatto e quali sono stati i risultati
antipattern
Per questo motivo in questi anni ho avuto l’opportunità di provare tutte queste tecnologie e framework, in modo da poterli valutare sul campo e non per sentito dire
L’importante spesso è capire bene cosa sta sotto un particolare framework e verificare se i punti di estensione che il framework ci fornisce ci possono essere eventualmente utili
Composition over Inheritance
Interface Thinking
Design for Change
A lui interessa soprattutto che l’applicazione sia bella, che magari funzioni pure (ironico) che venga fatta in fretta e che costi poco. Che poi la si sviluppi in Java, Ruby, .Net, C, Assembler... a lui interessa relativamente
Per me la curva di apprendimento diventa un elemento determinante ma, per la maggior parte di questi prodotti, il costo di passaggio da un framework a un altro è spesso maggiore del vantaggio tecnologico che può dare uno nei confronti dell’altro. La propensione all’apprendimento del team di sviluppo potrebbe essere l’altra caratteristica interessante da valutare: Team più sperimentatori, o slegati da uno specifico IDE, possono cambiare strumento con una certa facilità; altri hanno bisogno di consolidamento. Altri ancora possono avere investito tempo e soldi su licenze e componenti custom e allora non sono particolarmente propensi al cambiamento
Su applicazioni di una certa complessità cerco di proteggere il più possibile il domain model dalle variazioni della presentation, per cui cerco di imporre una separazione netta tra presentation e business layer e mi lascio il più ampio margine di manovra per il presentation layer
Grails
SpringMVC
Riagganciandomi a quanto diceva Massimo... alle soglie del 2010 il framework fai-da-te, nella maggior parte dei casi (quindi in un dominio "normale") è uno "smell" (ma forte, ...tipo Taleggio dimenticato nello sgabuzzino della casa in montagna dalle vacanze dell’anno scorso). Il peggior lock-in è nei confronti di te stesso (inteso sia come persona che come azienda)
Domain Specific Language
Ruby, Groovy, Scala
ha senso inventarsi tutto da zero?
Cosa manca per evitare che si ripetano gli stessi errori del passato? Come mai con il pullulare di nuove tecnologie e soluzioni nessuno si ricorda la regola numero uno che con la nascita di Java pareva che avessimo imparato? Perche’ stiamo annaffiando la boscaglia dei mille e mille nuovi framework e strumenti, consci del fatto che prima o poi rimarrà tutta roba inutilizzabile? Non era meglio seguire la strada di un JDK + JVM magari con evoluzioni general purpose o DSL? Tutto sommato la linea di Luca (scelgo poche cose ma che so gestire e che mi costano una cifra gestibile) mi pare il compromesso migliore. Faccio una ulteriore provocazione: la spinta dell’onda del "terze parti" che per molto tempo abbiamo cavalcato (a fronte della soluzione unidirezionale di MS) non rischia di risultare alla fine troppo diversificata da non poter essere più gestita? È così strano pensare a uno scenario più semplice con un Flex o un solo framework da specifica? Limitare la concorrenza bloccherebbe il progresso o ridurrebbe la complessità?
