Come evitare i problemi di complessità dei framework mantenendo al tempo stesso possibile la commercializzazione della mia squadra?

Non penso che le strutture siano una causa dell'ingegneria eccessiva. Più spesso, i framework rimuovono il codice boilerplate e semplificano il codice base che si è lasciato da mantenere.

Sono d'accordo anche con il commento di Thorbjorn che è una cattiva idea aspettarsi un'API per tutto. È molto meglio avere l'ambiente runtime focalizzato sulle cose che appaiono in quasi tutte le applicazioni ed essere abbastanza flessibile da consentire l'aggiunta di framework dove altri problemi comuni sono risolti.

Tuttavia, ho visto le istanze (al di fuori del mondo Java) dove i framework sono usati per il gusto di usare un framework. Capisco perché pensi che questo sia male, e se si sovrappone il prodotto, allora lo è. Ma bisogna tenere presente che se a uno sviluppatore viene dato spazio per migliorare il proprio curriculum, vedranno più motivi per restare in giro e imparare ancora di più.

Se uno sviluppatore è probabile che esegua il backup se scopre che un framework non aiuta, ci sono buone ragioni per lasciarli andare.

Ma leggendo la tua storia, vedo un problema più grande, non la comprensione del dominio aziendale. Troppi prodotti sono scritti senza alcun riguardo per problemi di business reali, solo il tentativo di produrre qualcosa che gli sviluppatori pensano dovrebbero aiutare. Questo non è colpa dei framework in alcun senso, è colpa degli sviluppatori, ma ha bisogno di essere risolto in qualche modo.

Il modo in cui lo fai dipende molto dalla struttura del team. Ma fai molti commenti sulla falsariga di "Non pensi che saremmo più soddisfatti del nostro lavoro se pensassimo di scrivere software che renderebbe la vita delle persone migliore?"

O fai in modo che gli sviluppatori si uniscano alle persone che useranno il software e vedranno i problemi che affrontano ogni giorno e offrono soluzioni.

Oppure, se si tratta di questo, gioca all'angolo della carriera. Intendo dire chi vuole andare alla loro prossima intervista e dire "sì, abbiamo fatto del nostro meglio, ma non è mai stato il prodotto che il cliente voleva", piuttosto che "così sono entrato nel business e ho studiato il modello e usato le tecniche DDD per trasformalo in un modello software "?

Are frameworks the catalyst of many of the over engineered projects out there

No.

or is it something much more simple?

Sì.

If you'd encountered these issues in a software project, how have you dealt with it?

Ignora.

Are there any good key indicators to look out for when a project is being over engineered?

Sì.

Vuoi alcuni suggerimenti?

O la domanda era semplicemente retorica?

Uno dei principali indicatori di sovraingegneria è la gente che si lamenta dell'eccessiva ingegneria. Sul serio. Altre persone che si lamentano

Over-engineering significa questo:

vengono aggiunte funzionalità extra per le quali non ci sono requisiti.

Flessibilità, scalabilità, disponibilità e tutti gli altri requisiti non funzionali sono spesso gettati in un progetto perché gli utenti (oi proprietari dei prodotti) si preoccupano solo dei requisiti funzionali.

Alcune persone amano davvero discutere i requisiti non funzionali in una grande quantità di profondità. Aggiungere tutti i tipi di cose

Ad alcune persone piace deprecare i requisiti non funzionali. Rimozione delle funzionalità essenziali per rendere il software "più leggero" o "più trasparente" o simile.

L'essenziale di una persona è opzionale di un'altra persona.

Dal momento che tutti hanno torto, anche tutti hanno ragione. C'è una via di mezzo da qualche parte.

Ciò che è importante è che i framework forniscono una suite standard di requisiti non funzionali a costo essenzialmente zero. Chiaramente, non è divertente. Chi vuole concentrarsi sui requisiti di confusione dell'utente?

Evitare un framework significa che tutta la suite standard di requisiti non funzionali deve essere costruita da zero. Chiaramente, è più divertente. Evitare i requisiti effettivi dell'utente per concentrarsi sui requisiti non funzionali è più simile alla programmazione reale.

Quando scegli i framework, considera questa roba:

1. Quante dipendenze ci sono nel framework. Quali altre librerie, programmi, ambienti, computer o sistemi richiede. Quanto impegno ci vuole per mantenere tutte le dipendenze? Meno sforzi è meglio.
2. Una volta scomparso lo sviluppatore originale del framework, cosa succederà? Mantenere il quadro è impossibile, difficile, richiede un team di 1000 persone
3. È abbastanza popolare che ci saranno sempre persone che si preoccupano del quadro, e offriranno volontariamente tempo e denaro per mantenerlo, anche se è un lavoro noioso e / o fastidioso mentre il mondo intero pensa che ci siano strutture migliori (già ) disponibile
4. qual è il tempo prima che il framework sparisca e considerato obsoleto
5. qual è la dimensione dell'interfaccia che utilizzerai. Piccolo è meglio.
6. Le convenzioni quadro tentano di suddividere il codice in 22 pezzi di forma diversa? Applica le convenzioni sul tuo codice? Fai attenzione ai callback che devono essere implementati. Fai attenzione anche alle convenzioni di denominazione / gestione della memoria / api che si diffondono intorno al tuo codice.
7. Il framework ha spostato la parte fastidiosa o gravosa del lavoro di sviluppo sulla tua responsabilità o tenta di gestirla e semplificarla
8. Puoi utilizzare l'intera funzionalità del framework, oppure è ciò che stai pianificando usando solo una piccola parte del framework. Se stai usando solo una piccola parte, allora il framework potrebbe essere troppo oneroso da gestire per te.
9. In quali linguaggi di programmazione o ambienti si basa il framework? L'ambiente sarà disponibile in futuro? Diversi fornitori che forniscono l'ambiente?
10. C'è un modo semplice per isolare il framework in una scatola che può essere cambiata?
11. Quanti dei tuoi file sorgente devono usare il framework? Il numero più piccolo è migliore.
12. Quanto sforzo risparmi quando decidi di utilizzare il framework? Che problema risolve? Quanto sforzo extra devi fare per utilizzarlo e mantenerlo per sempre.