C'è davvero qualcosa da guadagnare con un design complesso?

...would it be wrong to recommend a super-simple architecture, even to solve a complex problem, for an enterprise client?

Dipende dal cliente. Molti andranno bene con un approccio più diretto. Alcuni penseranno che tu sia incompetente perché quell'approccio semplice non risolverà i loro problemi - l'intera cosa "quella cosa deve essere super economica per una ragione ..." cosa che fa sì che alcune cose siano molto più costose di quanto costi fare.

testing and interfaces aren't used

Direi che non c'è modo all'inferno di poter fare in modo economico un software non banale senza uno di questi. Come compagnia, se provassi a vendermi qualcosa senza di loro, temerei che mi sopporterai con un mucchio di cacca di cane fumante completamente inflessibile e non mantenibile. ( modifica: per essere chiari, sto parlando di interfacce qui, non di interfaces . I programmi procedurali e funzionali non sono tutti mucchi di merda, anche se mancano di Java- interfacce di stile.)

if the cool-but-expensive abstractions are worth the overall cost

Come progettisti di programmi, abbiamo bisogno di formulare ipotesi su dove le cose cambieranno e tracciare delle linee in modo che le cose che cambiano possano essere fatte in modo rapido, semplice e corretto. Buone astrazioni ti faranno risparmiare tempo nel tempo perché l'inevitabile cambiamento diventa economico.

Ma non commettere errori, il termine "architettura astronauta" esiste per una ragione. Non stai sempre costruendo la navetta spaziale. Aggiungendo le brutte astrazioni che esistono nel mezzo di cose che devono cambiare o esistono per supportare modifiche che non esistono ... possono costare.

Ma nella mia esperienza, ho sentito persone lamentarsi del over codice astratto, ma ho visto solo i progetti fallire a causa del codice sottotramato.

Per architetto, o non architetto

Per riformulare Einstein, "le cose dovrebbero essere il più semplici possibile - ma non più semplici". È importante capire il vero uso di alcune architetture e non sono necessariamente per le prestazioni individuali, e spesso nemmeno per la soddisfazione sul lavoro.

A volte le architetture sono così complicate perché un progetto aziendale è così grande, con così tante persone al lavoro, che l'architettura deve in gran parte permettere a così tante persone di lavorare per qualcosa senza che tutti inciampino su tutti gli altri. Sono, a volte, poco più della complessità aggiunta che riduce la produttività individuale e rende il lavoro più difficile, ma consente a un gran numero di persone di lavorare. Questo funziona quando lo sforzo aggiunto supera la volontà individuale di vivere, err, intendo "produttività".

Questa è la situazione del tuo cliente? Bene, se il loro budget non è in milioni per questo progetto, forse no. Se è sotto un 100k, allora quasi certamente no. Costruisci un bunker di cemento per un reattore nucleare, non una stufa a legna:)

Non è necessariamente sbagliato suggerire "la cosa più semplice che potrebbe funzionare" per il tuo cliente, se è quello che la situazione richiede. Potrebbe essere il modo migliore per gestirlo. Il modo più semplice per vedere è confrontarlo con i progetti disponibili in commercio / open source che sono progettati per svolgere un compito simile (questa è la tua ricerca di mercato di due diligence, comunque), e vedere cosa li ha portati a fare ciò che hanno fatto.

Naturalmente, quando lavori con milioni di dollari, dovresti essere consapevole di alcuni incentivi perversi in gioco. In breve, "asino che copre": se si consiglia un sistema di architettura super complesso che richiede un dottorato di ricerca per capire correttamente, quando va a puttane chi è la colpa è stato? Non il tuo, ovviamente - hai suggerito solo le migliori tecnologie sofisticate che tutti dicono sia il migliore - ma sono "complicate" e "difficili", quindi la colpa è per le persone che hanno cercato di implementarlo. Devono semplicemente non essere abbastanza intelligenti o abbastanza abili ... in altre parole, viene dato un sacco di consigli per assicurarsi di non avere un bell'aspetto quando i progetti falliscono, cosa che inevitabilmente devono, poiché non tutti i progetti hanno successo. È cattivo juju, ma è un dato di fatto della nostra realtà.

Mancato follow-through

Suggerirei che l'incapacità di aggiornare continuamente i test e il follow-through sulle decisioni relative all'architettura (lanciare piani quando cambiano invece di aggiornarli, ecc.) è il motivo per cui così tanti sistemi finiscono per essere buttati fuori e riscritti da zero o sostituiti all'ingrosso con una nuova "soluzione" a pochi anni lungo la strada.

Quando le cose che rafforzano la chiarezza e la coerenza vengono espulse per convenienza, è facile a volte pensare di essere molto furbo e in realtà "fanno le cose" quando in realtà hai reso i cambiamenti futuri più difficili e più complicati; è molto comune rubare dalla produttività futura per ottenere guadagni immediati. È un male specifico quando nessuno si rende conto di quello che sta succedendo.

Il test, ad esempio, è particolarmente adatto a quando le cose cambiano. Si cambiano i test per riflettere su quale sia la nuova direzione, quindi si procede a correggere tutte le cose che sono ora "rotte" perché le persone hanno cambiato idea o si sono rese conto di aver perso qualcosa l'ultima volta. È come smettere di dormire perché hai molto da fare questa settimana - renderà le cose più difficili.

In conclusione, "Dipende" (utile, non è vero?)

La complessità architettonica è un costo generale, come affittare uno spazio più ampio per un'azienda di mattoni e malta; ha senso solo quando c'è una reale complessità che deve essere gestita. Se si tratta di un team di 3 persone che lavorano su una soluzione relativamente convenzionale, MVC semplice e strumenti minimi è probabilmente del tutto sufficiente.

Se si tratta di una soluzione software complessa, multi-sottosistema, con milioni di budget e almeno una mezza dozzina di team di 3-5? Stai pregando per l'amore dolce e dolce che solo l'ingegneria del round-round sull'analisi del programma orientata agli oggetti e tutti i suoi grafici, diagrammi e modelli possono dare. Qualunque cosa ti aiuti a mantenere le dozzine o centinaia di occhi senza fissarti fissamente, chiedendoti cosa dovrebbero fare oggi e come dovrebbero fare qualsiasi cosa.

Benvenuto nella consulenza.

Un ottimo posto per fare un sacco di soldi rapidamente offrendo funzionalità ai clienti.

Se cerchi di creare software mantenibili, adattabili e belli che funzionino bene sia che in futuro ti consiglio di lavorare in un settore specifico come quello sanitario o governativo in cui puoi ritagliare un nicchia migliore per il lavoro di qualità.

Ciò che ottieni da un design solido, è un ciclo di cambiamento più affidabile nel lungo periodo. Il costo è inizialmente più alto perché hai bisogno di programmatori adeguatamente addestrati e di una progettazione adeguata, tuttavia l'intento è di mantenere il costo delle modifiche successive da sbalzo fuori controllo.

Senza una solida architettura le modifiche sono solo più economiche all'inizio. Con l'evolversi del progetto, i cambiamenti diventano sempre più costosi. Questo, combinato con il desiderio di una manodopera più economica e di una iterazione più rapida, potrebbe uccidere il progetto in quanto le modifiche alla fine costano più di quanto la società sia disposta a pagare e più tempo di quello che l'azienda può aspettare. I cambiamenti successivi che avrebbero potuto richiedere una squadra media e un tempo medio richiederanno invece una squadra superumana e un lungo periodo di tempo per setacciare gli anni di codice e refactator sufficienti per apportare modifiche in modo sicuro.

Se il cliente capisce e vuole fare questo sacrificio, allora fai qualunque cambiamento sia necessario con qualunque metodo sia più veloce. Ma non è saggio (e probabilmente disonesto) fare quei compromessi per loro, in quanto questo processo influenzerà le loro decisioni di business.

Parte del lavoro è comprendere tutte quelle astrazioni che hai elencato, non solo per chiedere "Sono necessarie?" ma per capire quando e perché sono necessari e per capire come applicare tali schemi come parte del lavoro con il software.

Un'altra parte del lavoro è capire che i clienti giudicano spesso il lavoro in base a ciò che possono vedere (l'interfaccia utente, la funzionalità) e devono essere istruiti su ciò che non possono vedere (lo stato della base di codice).

• Vedi questo talk sul costo di un design scadente nel tempo
• Vedi questo talk sulla produttività stabile
• Vedi questa risposta SO sul valore dei test unitari

Complicato è relativo. Quando ho iniziato a imparare a programmare il concetto di puntatori, in particolare le liste concatenate erano complicate ("Come puoi avere qualcosa che ha se stessa come un campo"), ma una volta che ho capito cosa fosse il concetto, era semplice.

Quando ho iniziato ad apprendere la programmazione funzionale, il concetto di lambda sembrava complesso. Ma poi l'ho collegato all'idea di un puntatore Function da C ++ ed era semplice. E così via con curring, e completamenti, e così via e così via.

Quando ho iniziato a studiare TDD, ho pensato che fosse complesso o che aggiungesse un sovraccarico al processo di sviluppo. Ora non credo che il mio codice sia completo, a meno che non abbiate dei test che coprano almeno il percorso felice. L'iniezione di dipendenza e l'utilizzo di interfacce invece di classi concrete sembrano inizialmente complesse. Ma ti permettono di costruire il tuo codice con l'ipotesi che tu possa elaborare i dettagli delle dipendenze e concentrarti prima sui costrutti di livello superiore.

Dai un'occhiata a Clean Code e The Clean Coder di "Uncle Bob" Martin. Il primo parla di come programmare meglio. Il secondo parla di come essere un programmatore migliore. C'è una differenza tra i due.

Per dare un'analogia, sto imparando la chitarra. Sono al punto in cui posso suonare semplici melodie e accordi. La transizione tra accordi e posizioni è difficile. Praticando di più, sarò in grado di colpire quelle transizioni più facilmente e diventerà una seconda natura per me.

Uso il repository / unità di pattern di lavoro in modo da poter utilizzare un repository in memoria mentre sto costruendo le funzionalità di base e convertito in un repository "sql lite" o "odata" mentre mi avvicino alla consegna. Si noti che questo mi consente di completare più funzionalità anche prima che l'infrastruttura finale sia presente (o addirittura decisa). Le astrazioni mi permettono di creare mock e stub più facilmente in modo da poter verificare che il codice che dipende dalle astrazioni funzioni come previsto. Ancora una volta, posso completare le funzionalità dall'alto verso il basso.

Direi che è sbagliato creare prima l'infrastruttura. Il semplice fatto è che è anti-agile. Se spendo uno sprint su "infrastruttura", sto costruendo cose che non sono nemmeno sicuro che avrò bisogno alla fine e gli utenti non avranno nulla da guardare per fornire un feedback.

Questo è ciò che forniscono le astrazioni. Più ti eserciti ad usarli, più diventano di loro natura, e guarderai a questa discussione e ti meraviglierai di quanto hai sviluppato. Proprio come spero, mi chiedo tra qualche anno come le transizioni di accordi siano sempre state una sfida per me.

Non sono completamente d'accordo con la tua affermazione che l'astrazione aumenta automaticamente la complessità. L'astrazione è la ragione principale per cui al giorno d'oggi non è necessario risolvere il codice macchina.

Il problema a volte con le astrazioni è che tendono a concentrarsi sui meccanismi interni piuttosto che nascondere la complessità ai suoi utenti finali. Le astrazioni dovrebbero isolare la logica e promuovere la riusabilità. Inoltre, ritengo che il testing sia un ottimo modo per sfidare la progettazione architettonica. Principalmente perché ti costringe a guardare il tuo codice dal punto di vista dell'utente.

I problemi che hai menzionato riguardo la mancanza di tempo, sono la causa principale del cattivo design. Il buon design di solito non arriva istantaneamente, ma attraverso iterazioni e raffinatezza. Il modo in cui estraiamo i requisiti dai nostri clienti è tramite le storie degli utenti. In questo modo il cliente può pensare a cosa e come vuole usare il sistema. Inoltre, se l'architetto è a conoscenza delle intenzioni del sistema, è possibile scegliere decisioni di progettazione appropriate o tecniche di astrazione per aggiungere flessibilità al sistema. Non perché siano belli o belli.

Indirizzamento delle domande ...

...would it be wrong to recommend a super-simple architecture, even to solve a complex problem, for an enterprise client?

Assolutamente no.

Dalla prospettiva del cliente

Come affermato sopra, dipende in gran parte dal cliente. Dipende anche dalla tua capacità di valutare accuratamente quali soluzioni sono giuste per il tuo cliente. Mentre ci sarà sempre un costo percepito per il valore desiderato, come consulente è il tuo lavoro per impostare le aspettative appropriate del cliente. In alcuni casi, dovrai soddisfare questa percezione. In altri, sarà nel tuo migliore interesse correggerli. Dopotutto, dovresti essere l'esperto per il tuo cliente. E se non lo sei, dovresti avere le conoscenze per essere in grado di diventare quell'esperto. Questo è quello per cui ti pagano.

Dalla prospettiva dello sviluppatore

La parte più difficile nella scelta dell'architettura da utilizzare è, spesso, la stima corretta della quantità di lavoro necessaria per utilizzare la tecnologia per soddisfare le esigenze specifiche. Questo può portare rapidamente a progetti che non soddisfano le aspettative dei clienti. Comprendi che alcuni progetti sono effettivamente realizzati più velocemente utilizzando questi "complessi" pezzi di codice che menzioni. Si comprende anche che alcuni non lo sono. Tu devi fornire quella misurazione, in base a ciò che tu o il tuo team conoscete.

Is it complexity that defines enterprise solutions, or is it the reliability, # concurrent users, ease-of-maintenance, or all of the above?

Sebbene le specifiche possano variare, in generale, una soluzione aziendale è una soluzione software che si applica a un vasto pubblico misto. Il numero di utenti concorrenti può essere o meno un fattore, anche se spesso lo è. Il numero totale di utenti, spesso in una varietà di ruoli aziendali, è uno dei maggiori fattori determinanti per stabilire se la soluzione è "enterprise".

Molte soluzioni aziendali sono molto complesse, ma alcune sono piuttosto semplici. Mentre l'impresa dà un'aria di affidabilità (e dovrebbe essere certamente mantenuta a un certo livello), diverse soluzioni hanno diversi livelli di affidabilità.

La facilità di manutenzione è qualcosa che penso che ogni sviluppatore (indipendente o membro del team) si impegni, non è necessariamente così facilmente raggiunto. Ciò che è importante è che esiste una procedura di manutenzione che ha linee guida ferme, piuttosto che essere "facile". Ricorda, basi di codice differenti avranno livelli sostanzialmente diversi di facilità a seconda delle filosofie, delle metodologie, dell'attività dell'ambiente (aziendale), della e complessità del codice.

Reagendo alle altre dichiarazioni ...

In all cases, there was never a need to actually make code swappable or reusable

Spesso non c'è mai un'esigenza specifica per farlo. Questo dovrebbe essere il tuo obiettivo, in ogni momento, comunque. Considera questo ... Potresti avere un cliente che richiede la possibilità di accedere o visualizzare il calendario dalla pagina web. Se rendi il tuo codice riutilizzabile, allora quando un altro cliente chiede la stessa cosa, hai già un po 'del lavoro svolto. Se non lo fai, allora devi fare tutto da capo. Ogni problema con il cliente è spesso di cui potrebbe aver bisogno un altro cliente in futuro. In altre parole, ogni cliente con cui lavori dovrebbe avere il potenziale per ridurre il costo del lavoro per i tuoi futuri clienti (non necessariamente il costo del prodotto).

and the tests were never actually maintained past the first iteration because requirements changed, it was too time-consuming,

Direi qui che la metodologia di test non era abbastanza astratta. Recentemente ho usato un pezzo di codice che ha fatto i propri test unitari direttamente all'interno di se stesso. Sono state create una funzione personalizzata assert e expect che ha soddisfatto le esigenze del progetto. Ogni volta che era necessario un test unitario, poteva essere applicato senza nemmeno regolare il codice. Infatti, il codice viene distribuito attivamente con gli asseriti e si aspetta ancora lì. Ha effettuato tali controlli come parte del codice di lavoro.

... deadlines, business pressure, etc etc....

Ho spesso riscontrato che la pressione extra aziendale e le scadenze che ostacolano il processo di codifica sono state imputate allo sviluppatore, non al cliente. Anche se questo non è sempre il caso, molte volte la pressione aziendale è causata dalla percezione di non riuscire a soddisfare le aspettative del cliente. Quando le scadenze impediscono il codice, è spesso perché lo sviluppatore non è riuscito a valutare con precisione la quantità di lavoro richiesto per il codice funzionale utilizzabile. In altre parole, programmali (i client se lo aspettano) , misurali (i client futuri se lo aspettano) , eseguili (gli utenti lo richiedono) , e vieni pagato per loro (il tuo contratto dovrebbe richiederlo) .

Gran parte di ciò che questa domanda pone è incredibilmente soggettiva, penso che sia importante riportare alcuni dati sui costi di composizione della complessità architettonica. C'è un case study molto interessante proveniente dal MIT Sloan che misura

• diminuzione della produttività degli sviluppatori
• aumento del fatturato
• e aumento della densità dei difetti che risulta da una maggiore complessità.

Fondamentalmente, direi che c'è un mezzo felice che ogni base di codice dovrebbe sforzarsi di trovare tra (A) semplicità in modo che la produttività degli sviluppatori sia elevata e (B) lungimiranza in modo che la funzionalità non venga compromessa quando vengono aggiunte nuove funzionalità.

Il case study riguardava questa società con una base di codice monolitica con un nucleo ad alta complessità (si pensi alle utilità e all'astrazione elevata) e una periferia a complessità inferiore (si pensi a nuove funzionalità con poche dipendenze). Tra la periferia e il nucleo, la produttività degli sviluppatori è diminuita del 50% (cose pazzesche) e i difetti sono aumentati di 2,6 volte.

Posso mettere in relazione i tuoi dubbi riguardo le complesse tecniche di sviluppo del software, e indovinerei che ci sono molte persone che possono, per le ragioni esattamente indicate, aggiungere un overhead alla creazione iniziale di un nuovo sistema mentre non sempre mostrando immediatamente i loro benefici.

Questo chiaramente non significa che non esistono, per ogni concetto esiste una ragione, la maggior parte delle volte una buona. In totale dovrebbero ridurre il lavoro necessario per finalizzare un progetto e migliorarlo in seguito.

In teoria, naturalmente, e scommetto che hai imparato tutti quei benefici teorici e ora più che mai li vedi fallire. E questo può avere una buona ragione, anche usare un concetto non è così facile come capire perché viene usato, e mentre tu puoi avere l'esperienza necessaria per decidere quando astrarre e quando no, i tuoi clienti potrebbero non ancora.

Utilizzare un concetto in ogni punto possibile del tuo progetto può costarti un sacco di tempo (vedi la risposta di Telatsyns per una frase semplice e chiara su quello) e anche usare un concetto nel posto giusto può costarti, se non hai esperienza basta usarlo. Come hai detto, non sono concetti semplici ma a volte complessi che devono essere adattati alla tua situazione, una comprensione teorica non può essere sufficiente per usarla velocemente e correttamente.

E per queste ragioni non è una sorpresa che i tuoi clienti non si accorgano dei concetti e abbandonino i test e le astrazioni e riprendano a lavorare in modo semplice.

Per quanto riguarda la grande barriera che può essere l'ingegneria del software, ti suggerisco questo articolo: Le sette fasi di competenza nell'ingegneria del software Mi sono imbattuto in esso da qualche parte in questa pagina ed esprime alcuni pensieri ed esperienze davvero interessanti.

Direi che se stai sviluppando applicazioni per l'azienda, tu o qualcuno responsabile dei tuoi progetti (Proj mgr) dovresti avere un'idea migliore della quantità di lavoro che dovrebbe andare ai progetti. Se stai vedendo una perdita di tempo allora dovresti discutere della tua visione con il mons. Il mio modo di sentire e di operare è sempre su un tipo di giudizio per base, ma guardo sempre quel cliente che ti lancerà una palla curva. Farei un errore nel fare un buon lavoro tracciando i tuoi I e incrociando le tue t. Mi assicurerò inoltre di avere la corretta gestione del ciclo di vita delle applicazioni in modo che la maggior parte del sovraccarico sia automatizzata in modo che mal risparmi tempo ecc ... Spero che ti aiuti!