Quando si crea un'applicazione non banale, è meglio concentrarsi su come far funzionare le cose rapidamente e prendere scorciatoie nel codice come mescolare la logica del modello con le proprie viste, rompere l'incapsulamento - odori tipici del codice? Oppure, stai meglio prendendo il tempo in anticipo per costruire più architettura, costruirla nel modo giusto, ma correndo il rischio che tutto questo codice extra possa non essere utilizzato poiché il tuo design è abbastanza fluido e potresti doverlo buttare via se il feedback ti causa andare in una direzione diversa?

Per il contesto, sto creando un'applicazione desktop. Sono l'unico sviluppatore e lo faccio part-time da quando ho un lavoro giornaliero. Ora, per lavoro, provo a fare le cose nel modo giusto, se il programma lo consente. Ma per questo progetto, che mi aspetto si trasformerà quando riceverò feedback dalle persone, non sono sicuro che sia l'approccio giusto. Ho trascorso diverse ore questa settimana a mettere in atto un libro di testo Model View Controller design per comunicare i cambiamenti nel modello alla vista. Questo è fantastico in generale, ma non sono sicuro di aver bisogno di più viste per visualizzare i dati e so che avrei potuto visualizzare le cose più rapidamente senza l'architettura aggiuntiva. Con forse 10-15 ore settimanali da dedicare al progetto, credo che ci vorranno anni per realizzare qualcosa che posso dimostrare se seguo le buone pratiche del software. So che i miei utenti hanno vinto " non importa se ho usato MVC internamente, vogliono solo qualcosa che risolva il loro problema. Ma mi sono anche trovato nella situazione in cui hai subito un così grande debito tecnico da scorciatoie che il codice è incredibilmente difficile da mantenere e aggiungere nuove funzionalità. Mi piacerebbe sapere come le altre persone affrontano questo tipo di problema.

Costruiscilo bene .

Costruirlo "velocemente" è un errore logico se si guarda il quadro generale. Ti impedirà di averlo mai costruito bene e alla fine sarai impantanato da bug e difetti dell'architettura fondamentale che impediscono il refactoring o addirittura rendono impossibile l'aggiunta di nuove funzionalità.

Costruirlo bene è in realtà il contrario. All'inizio potrebbe essere più lento, ma alla fine ti renderai conto dei guadagni di efficienza dopo aver preso il tempo per fare le scelte giuste in anticipo. Inoltre, sarai in grado di adattarti alle esigenze future più facilmente (refactoring se necessario) e avrai un prodotto finale migliore a causa, almeno, di un minor numero di bug.

In altre parole (a meno che non si tratti di un contratto unico), crealo velocemente = crealo lentamente, crealo bene = crealo velocemente .

Inoltre c'è qualcosa di importante da realizzare nel "costruirlo bene" e progettare un'architettura. Hai chiesto ...

... ma correre il rischio che tutto questo codice extra non possa essere usato poiché il tuo design è abbastanza fluido e potresti doverlo buttare via se il feedback ti fa andare in una direzione diversa?

Questo non è in realtà un vero rischio derivante dal "passare il tempo in architettura". Il design dell'architettura dovrebbe essere organico . Non perdere tempo a progettare un'architettura per qualsiasi parte finché non è giustificata. L'architettura dovrebbe evolversi solo da schemi osservati e confermati nel progetto.

Legge di John Gall da Systemantics :

Un sistema complesso progettato da zero non funziona mai e non può essere riparato per farlo funzionare. Devi ricominciare da capo, iniziando con un sistema semplice funzionante.

Veloce, quindi bene

Questo deriva dalla mia esperienza personale dopo aver provato molti metodi diversi.

Il problema con il solo lavoro veloce (e il rilascio) è generalmente che affronterai funzionalità dopo funzionalità sulla tua applicazione e poiché è stato rilasciato è molto difficile apportare modifiche fondamentali al tuo programma. A lungo termine paghi un prezzo altissimo per nulla che abbia una solida architettura di base, è come costruire una sgangherata su sabbie mobili.

Il programma per farlo bene è che perderai molto tempo e codice. È come costruire un palazzo senza progetti. Scrivere applicazioni è un processo di apprendimento e quasi (nella mia esperienza) impossibile da progettare in anticipo. Ciò significa che eseguirai molto refactoring e se scrivi tutto "bene" tutto il tempo, finirai per buttare via un sacco di codice.

Quindi, veloce, allora bene!

La cosa principale quando inizi è solo mettere tutto in codice in modo da poter inchiodare tutte le funzionalità e vedere che tipo di architettura devi supportare. Un'altra cosa positiva di questa metologia è che ti terrò motivato poiché avrai rapidamente qualcosa in esecuzione. È anche importante implementare alcune funzionalità "edge-case" poiché ciò avrà un impatto sulla tua architettura generale. Non preoccuparti di scrivere unit test o di lavorare sui dettagli in questa fase. Se pensi che dovrai supportare il multilingua in futuro, un'architettura plug-in di ciò che non è, implementala, ma veloce e sporca. Fai un refactoring per mantenere gestibile l'applicazione ma nulla di eccessivo.

Dopo aver sentito di avere un "prototipo" funzionante è tempo di iniziare il refactoring. Fondamentalmente vuoi rifare l'applicazione come faresti se avessi iniziato da zero sapendo tutto ciò che ora sai. L'importante è ottenere l' architettura corretta, non reimplementare tutte le funzionalità che hai fatto nella prima fase, ma dovresti avere l'architettura in atto per supportarla in seguito.

In questo modo finirai con un'applicazione con un'architettura sonora il più efficiente possibile, nella mia esperienza comunque :)

Costruiscilo

Veloce se il time to market è più importante della qualità

Bene, se la qualità è più importante del time to market

Costruirlo rapidamente ti darà benefici a breve termine e perdite a lungo termine.

Costruirlo bene comporterà perdite a breve termine ma benefici a lungo termine.

Costruirlo bene richiede pazienza e saggezza, ma sarai ricompensato.

Costruirlo velocemente è utile solo per la prototipazione rapida e le cose da buttare via. Gli obiettivi a lungo termine possono essere raggiunti solo con il giusto atteggiamento fin dall'inizio.

Per i progetti che prevedi di distribuire per essere utilizzati da altri, farei sempre errore dal lato del lavoro iniziale. Un'architettura ben congegnata è più facile da estendere se necessario. Prendere scorciatoie è solo il modello per accumulare debiti tecnici.

A volte può essere frustrantemente lento. Vale la pena fare le cose che vale la pena fare.

Costruendolo bene = costruendolo velocemente

Le scorciatoie tendono a girarsi e ti mordono ancora più velocemente di quanto pensi. A volte anche prima di pranzo.

Sul tuo contesto; non astrarre immediatamente. Attenersi a YAGNI e rimuovere la duplicazione. Implementa quel modello basato su Vista quando in realtà hai una seconda vista non perché pensi di averne una in futuro. Quando arriva quella seconda vista, l'astrazione che crei è in genere molto migliore di quella che avresti fatto intorno alla prima singola occorrenza.

Bene, se sai già cosa stai facendo, in fretta se non lo fai

Sono un ricercatore e scrivo molto codice esplorativo prima di avere la minima idea di quale sia il quadro generale o come si svilupperà il progetto. In questi casi è difficile persino vedere come "bene" dovrebbe essere definito. Inoltre, di solito è difficile vedere tutti i piccoli dettagli e i modi in cui le cose potrebbero essere estese in anticipo. Pertanto, si applica il vecchio adagio:

1. Fallo funzionare.
2. Fallo giusto. Renderlo al secondo posto ha il vantaggio di poter meglio definire "giusto" una volta che hai avuto l'esperienza di farlo funzionare.

Costruiscilo bene .. sempre, ma dai l'illusione di andare veloce

ma per renderlo veloce basta ridurlo. Costruisci un piccolo sottoinsieme del tutto sufficientemente significativo per ottenere feedback. L'aggiunta progressiva ad un ritmo costante produrrà quasi lo stesso vantaggio di costruire velocemente senza vendere la tua anima alla reazione a catena delle notti insonni giocando a battibecco.

Penso che dovrebbe sempre essere "costruito bene". Se il time to market è una grande preoccupazione, utilizzare un processo di sviluppo incrementale. Nel peggiore dei casi hai un prodotto con meno funzionalità, ma almeno hai un prodotto di alta qualità da spedire che può essere esteso nelle versioni future delle funzionalità.

Equilibrio

Non è pratico o ingegnerizzare il tuo codice alla perfezione o mescolare un po 'di codice in un batter d'occhio, vero? Si tratta davvero di trovare il giusto equilibrio. Ciò che conta secondo me è quello che fai quando.

Penso che la cosa più importante qui sia garantire assolutamente che il nucleo dell'applicazione, la struttura fondamentale, sia costruito davvero bene. A tenuta d'aria. Una volta ottenuto ciò, a seconda dei vincoli temporali, se nel caso tu abbia poco tempo, potresti mettere insieme un po 'di codice e ri-fattorizzarlo in seguito, e puoi permetterti quel lusso perché ti saresti preso cura di ottenere le basi giusto, e non farebbe male a ricodificare il codice.

Fai la cosa più semplice che potrebbe funzionare. Nel tuo caso particolare, il tuo programma non diventerà molto grande, essendo tu l'unica persona che ci lavora part-time. Non sto sostenendo cattive maniere come goto abuse, nomi variabili anonimi, ecc., Ma non dovresti renderlo più complesso di quanto debba essere. Forse MVC è solo un eccesso per il tuo particolare progetto.

che mi aspetto si trasformerà quando riceverò feedback dalle persone

L'hai detto tu stesso meglio:

Ma mi sono anche trovato nella situazione in cui hai subito un così grande debito tecnico da scorciatoie che il codice è incredibilmente difficile da mantenere e aggiungere nuove funzionalità.

Se hai poco tempo, non aver paura di chiedere altro tempo per completare il progetto dal tuo datore di lavoro usando lo stesso ragionamento. Sono sicuro che te lo concederanno. Detto questo, capisco quanto a volte possa sembrare frustrante lavorare così duramente su qualcosa e non essere in grado di mostrare molto del risultato. Ma non preoccuparti, ci arriverai e costruirlo bene ne varrà sicuramente la pena.

In genere mi piace costruire bene la struttura e risparmiare tempo non preoccupandomi di dettagli di implementazione specifici. Come dici tu, cambieranno comunque. L'idea alla base della costruzione di una sottostruttura ben fatta è che i cambiamenti possono avvenire molto velocemente, una volta costruita la base. Cerco di concentrarmi sull'essere il più generico possibile nelle mie lezioni e renderle riutilizzabili ove possibile. Di solito offro all'utente un'app ben costruita che soddisfa solo i requisiti di usabilità di base. Gli utenti ottengono tutti i tipi di Idea una volta che uno strumento è nelle loro mani, quindi è inutile pensare molto più avanti.

Costruiscilo bene . Se non hai tempo, riduci le funzionalità.

Progettalo il più universale possibile. Ad esempio, progettare un'architettura di plug-in, anche se lo sai, verrà utilizzato solo un plug-in per la prima volta. Usa schemi di configurazione universali (configurazione estensibile, organizzazione del linguaggio), anche all'inizio c'è solo un parametro. È un ottimo investimento e puoi farlo solo all'inizio del progetto.

è meglio concentrarsi su come far funzionare le cose rapidamente e prendere scorciatoie nel codice come mescolare la logica del modello con le tue viste, rompere l'incapsulamento - odori tipici del codice? Oppure, stai meglio prendendo il tempo in anticipo per costruire più architettura

Nelle mie orecchie, nel modo in cui lo metti lì, stai elencando i due estremi. La prima scelta, rompere l'incapsulamento, mettere la logica del modello nelle viste, è solo una programmazione scadente. IMHO, risolvere questi problemi non è la stessa cosa che aggiungere più architettura. Forse a meno che ciò di cui stai parlando sia che il codice UI sta eseguendo istruzioni SQL. Ma poi non direi di costruire più architettura, quindi direi che hai una completa mancanza di design e architettura e dovresti prenderne uno.

Quando si tratta di architettura, sceglierei quello più semplice che risolve il problema in questo momento, e poi si espandono quando sorgono problemi.

Ad esempio, è ciò di cui hai bisogno in questo momento la funzionalità per restituire i dati da una singola tabella del database, non mi preoccuperei dei problemi come come caricare i dati dalle tabelle correlate, anche se saprei che alla fine potrebbe sorgere il problema. Comincerei a preoccuparmene quando riesco a implementare quella funzionalità.

Quindi, per i miei progetti di sviluppo domestico, adotterò il seguente approccio: costruire la soluzione più semplice possibile che risolva il problema con cui sto lavorando in questo momento, ma costruirlo bene. Riformulerei quindi la soluzione in quanto è necessaria una maggiore complessità. Seguire le pratiche del TDD rende sicuro il refactoring e aiuta anche a evitare gli odori di codice (è difficile creare buoni test unitari se si rompe l'incapsulamento).

Questo è per inciso anche l'approccio che adotto quando lavoro professionalmente. ;)

Vorrei raccomandare innanzitutto di alzare il software, coprire ogni aspetto e sopportare prima il software e poi gradualmente decorare e migliorare le sue prestazioni

Di solito vuoi essere nel mezzo di questi due bordi:

Costruiscilo bene = software in tempo reale critico per la vita da cui dipende la vita delle persone. ovvero controllo software: reattori nucleari, macchine per dialisi, macchine per risonanza magnetica , ecc.

Build it fast = software inutile che nessuno utilizza realmente.