Essere stupidi per ottenere una migliore produttività?

Ho trascorso molto tempo a leggere diversi libri su "buon design", "modelli di design", ecc. Sono un grande fan dell'approccio SOLID e ogni volta che devo scrivere un semplice codice, penso a il futuro. Quindi, se l'implementazione di una nuova funzionalità o una correzione di bug richiede solo l'aggiunta di tre righe di codice come questa:

if(xxx) {
    doSomething();
}

Ciò non significa che lo farò in questo modo. Se penso che questo pezzo di codice possa diventare più grande nel prossimo futuro, penserò di aggiungere astrazioni, spostare questa funzionalità altrove e così via. L'obiettivo che sto perseguendo è mantenere la complessità media come prima dei miei cambiamenti.

Credo che dal punto di vista del codice sia una buona idea - il mio codice non è mai abbastanza lungo ed è abbastanza facile capire i significati di diverse entità, come classi, metodi e relazioni tra classi e oggetti.

Il problema è che ci vuole troppo tempo e spesso sento che sarebbe meglio se avessi implementato quella funzione "così com'è". Si tratta solo di "tre righe di codice" rispetto a "nuova interfaccia + due classi per implementare tale interfaccia".

Dal punto di vista del prodotto (quando parliamo del risultato ), le cose che faccio sono abbastanza insensate. So che se lavoreremo alla prossima versione, avere un buon codice è davvero fantastico. D'altra parte, il tempo che hai impiegato per rendere "buono" il tuo codice potrebbe essere stato impiegato per implementare un paio di utili funzioni.

Spesso mi sento molto insoddisfatto dei miei risultati: un buon codice che può fare solo A è peggio di un cattivo codice che può fare A, B, C e D.

È probabile che questo approccio provochi un guadagno netto positivo per un progetto software o è una perdita di tempo?

il buon codice che può fare solo A è peggio del cattivo codice che può fare A, B, C, D.

Questo mi profuma di generalità speculativa . Senza sapere (o almeno essere ragionevolmente sicuri) che i tuoi clienti avranno bisogno delle funzionalità B, C e D, stai semplicemente superando inutilmente il tuo design. Un codice più complesso è più difficile da comprendere e mantenere a lungo termine. La complessità aggiuntiva è giustificata solo da utili funzioni extra. Ma siamo in genere molto cattivi nel predire il futuro. La maggior parte delle funzionalità che riteniamo possano essere necessarie in futuro non saranno mai richieste nella vita reale.

Così:

Un buon codice che può fare solo A (ma lo fa in modo semplice e pulito) è MEGLIO di un cattivo codice che può fare A, B, C, D (alcuni dei quali potrebbero essere necessari in futuro).

Tempo di aneddoto:

Ho avuto due sviluppatori che lavorano per me che si sono orientati all'ingegnerizzazione eccessiva in questo modo.

Per uno di questi, ciò ha sostanzialmente bloccato la sua produttività, soprattutto quando ha avviato un nuovo progetto. Soprattutto se il progetto era, per sua natura, abbastanza semplice. In definitiva, un software che funziona ora è ciò di cui abbiamo bisogno. Questo è diventato così grave che ho dovuto lasciarlo andare.

L'altro sviluppatore che era incline all'ingegnerizzazione eccessiva lo ha compensato essendo estremamente produttivo. Come tale, nonostante tutto il codice estraneo, ha comunque consegnato più velocemente della maggior parte. Tuttavia, ora che è passato, mi trovo spesso irritato dalla quantità di lavoro extra necessario per aggiungere funzionalità in quanto è necessario modificare i livelli di astrazione (del tutto inutili) ecc.

Quindi la morale è che l'ingegneria eccessiva consumerà tempo extra che potrebbe essere speso meglio nel fare cose utili. E non solo il tuo tempo, ma anche di coloro che devono lavorare con il tuo codice.

Quindi non farlo.

Vuoi che il tuo codice sia il più semplice possibile (e non più semplice). Gestire "maybes" non semplifica le cose, se indovini, avrai reso il codice più complesso senza alcun guadagno reale da mostrare.

I principi SOLID e KISS / YAGNI sono opposti quasi polari. Uno dirà che se doSomething () non può essere giustificato come parte integrante del lavoro che la classe che lo chiama sta facendo, dovrebbe essere in una classe diversa che è liberamente accoppiata e iniettata. L'altro ti dirà che se questo è l'unico posto in cui viene usato qualcosa, anche estrarlo in un metodo potrebbe essere stato eccessivo.

Questo è ciò che rende i buoni programmatori la pena del loro peso in oro. La struttura "corretta" è una base caso per caso, che richiede la conoscenza della base di codice corrente, il percorso futuro del programma e le esigenze del business dietro il programma.

Mi piace seguire questa semplice metodologia in tre passaggi.

• Al primo passaggio, fallo funzionare.
• Al secondo passaggio, puliscilo.
• Al terzo passaggio, renderlo SOLID.

Fondamentalmente, questo è il modo in cui si fondono KISS con SOLID. Quando scrivi per la prima volta una riga di codice, per quanto ne sai sarà una tantum; deve semplicemente funzionare e a nessuno importa come, quindi non avere fantasia. La seconda volta che posizionate il cursore su quella riga di codice, avete smentito la vostra ipotesi originale; nel rivisitare questo codice, probabilmente lo stai estendendo o agganciandolo da qualche altra parte. Ora, dovresti pulirlo un po '; estrarre metodi per bocconcini di uso comune, ridurre o eliminare la codifica copia / incolla, aggiungere alcuni commenti, ecc. ecc. La terza volta che si ritorna a questo codice, è ora un'intersezione importante per i percorsi di esecuzione del programma. Ora dovresti trattarlo come una parte fondamentale del tuo programma e applicare le regole SOLID dove possibile.

Esempio: è necessario scrivere una semplice riga di testo sulla console. La prima volta che succede, Console.WriteLine () va bene. Quindi si ritorna a questo codice dopo che nuovi requisiti impongono anche la scrittura della stessa riga in un registro di output. In questo semplice esempio, potrebbe non esserci un sacco di codice "copia / incolla" ripetitivo (o forse c'è), ma è ancora possibile eseguire alcune operazioni di pulizia di base, magari estrarre un metodo o due per evitare di incorporare operazioni di I / O in una logica aziendale più profonda . Quindi, si ritorna quando il client desidera lo stesso output di testo in una pipe denominata per un server di monitoraggio. Ora, questa routine di uscita è un po 'un grosso problema; stai trasmettendo lo stesso testo in tre modi. Questo è l'esempio da manuale di un algoritmo che trarrebbe beneficio da un modello composito; sviluppare una semplice interfaccia IWriter con un metodo Write (), implementare tale interfaccia per creare classi ConsoleWriter, FileWriter e NamedPipeWriter e ancora una volta per creare una classe composita "MultiWriter", quindi esporre una dipendenza IWriter sulla classe, impostare il composito MultiWriter con i tre scrittori effettivi e collegarlo. Ora è abbastanza SOLIDO; da questo punto in poi, ogni volta che i requisiti impongono che l'output dovrebbe andare ovunque nuovo, è sufficiente creare un nuovo IWriter e collegarlo al MultiWriter, non è necessario toccare alcun codice di lavoro esistente.

il buon codice che può fare solo A è peggio del cattivo codice che può fare A, B, C, D.

1) Avere un codice che fa solo ciò che dovrebbe fare.

Se penso che questo pezzo di codice possa diventare più grande nel prossimo futuro, penserò di aggiungere astrazioni, spostare questa funzionalità altrove e così via.

2) Se pianifichi il codice per eseguire A, B, C e D, il cliente ti chiederà infine E.

Il tuo codice dovrebbe fare quello che dovrebbe fare, non dovresti pensare ora alle future implementazioni, perché non finirai mai di cambiare continuamente il tuo codice e, cosa più importante, sovrastamperai il tuo codice. Dovresti riformattare il tuo codice non appena ritieni che ne abbia bisogno a causa delle funzionalità attuali, non faticando a prepararlo per qualcosa che non ha ancora intenzione di fare, a meno che, ovviamente, non lo abbia pianificato come parte dell'architettura del progetto.

Ti consiglio di leggere un buon libro: Il programmatore pragmatico . Ti aprirà la mente e ti insegnerà cosa dovresti fare e cosa non dovresti fare.

Anche Code Complete è una grande risorsa piena di informazioni utili che ogni sviluppatore (non solo programmatore) dovrebbe leggere.

molto tempo ho bisogno di scrivere un semplice pezzo di codice, penso al futuro

Forse qui è il problema.

Nelle prime fasi, non hai idea di quale sarebbe il prodotto finale. O se ce l'hai, è sbagliato. Di sicuro. È come un ragazzo di 14 anni che qualche giorno fa ha chiesto a Programmers.SE se deve, per la sua carriera futura, scegliere tra le app web e non ricordo cos'altro: è abbastanza ovvio che tra qualche anno le cose gli piace, cambierà, sarà interessato da altri domini, ecc.

Se, per scrivere tre righe di codice, crei una nuova interfaccia e due classi, sei troppo ingegnerizzato. Otterrai un codice che sarà difficile da mantenere e difficile da leggere , solo perché per ogni riga di codice utile hai due righe di codice che non ti servono. Senza contare la documentazione XML, i test unitari, ecc.

Pensaci: se voglio sapere come una funzione è implementata nel tuo codice, sarebbe più facile per me leggere venti righe di codice, o sarebbe più veloce e più semplice aprire dozzine di classi semi-vuote e interfacce per capire quale si usa quale, come sono correlati, ecc.?

Ricorda: una base di codice più grande significa più manutenzione. Non scrivere più codice quando puoi evitarlo.

Il tuo approccio è dannoso anche per gli altri lati:

• Se è necessario rimuovere una funzione, non è più facile capire dove viene utilizzato un metodo specifico a venti righe, piuttosto che perdere tempo a capire le dipendenze tra dozzine di classi?

• Durante il debug, non è più facile avere una piccola traccia dello stack o preferisci leggere dozzine di righe per capire come viene chiamato da cosa?

Per concludere, sembra simile all'ottimizzazione prematura . Stai cercando di risolvere il problema senza nemmeno essere sicuro che ci sia un problema in primo luogo e dove si trova. Quando lavori sulla versione 1 del tuo prodotto, implementa le funzionalità che devi implementare in questo momento; non pensare a qualcosa che ti aspetti di implementare tra due anni nella versione 14.

Scrivere un sacco di codice che (probabilmente) non verrà mai usato è un ottimo modo per ottenere un P45 . Non hai una sfera di cristallo e non hai idea della direzione finale che lo sviluppo richiederà, quindi passare il tempo su queste funzioni costa solo denaro per nessun ritorno.

Cercare di prevedere ciò che potrebbe essere necessario dal codice in futuro spesso finisce per essere inutilmente sovraccarico di ingegneria (un'abitudine che sto cercando di scuotere). Direi solo di fare le tre righe. Quando sorge la necessità (e non prima), il refactor. In questo modo il tuo codice fa sempre ciò di cui ha bisogno senza essere troppo complicato ed evolve naturalmente una buona struttura attraverso il refactoring.

Dico spesso che la codifica è come il lato chiaro / lato oscuro della Forza - il lato "leggero" richiede più sforzo ma produce risultati maggiori. Il lato "oscuro" è rapido e semplice e offre immediatamente maggiori vantaggi ma ti corrompe lungo la strada. Una volta che avvierai il sentiero oscuro, dominerà per sempre il tuo destino.

Mi imbatto in questo tutto il tempo, in ogni lavoro che abbia mai avuto, è come una maledizione che non posso sfuggire. La cultura aziendale è sempre il percorso del lato oscuro e rapidi hack / correzioni per estrapolare nuove funzionalità e i miei motivi e le mie grida di refactoring e di scrittura del codice cadono correttamente nel vuoto, se non porta alla mia conclusione per " cercando di cambiare le cose "(non ho scherzato che accadesse una manciata di volte, perché volevo introdurre schemi di progettazione e allontanarmi da attacchi rapidi).

La triste verità è che spesso il modo stupido / lato oscuro è il modo in cui devi camminare, devi solo assicurarti di camminare leggermente. Mi sono reso conto lentamente e tristemente che i programmatori che comprendono il modo giusto di scrivere software, ovvero seguire SOLID, usare modelli di progettazione, obbedire al SoC, ecc. Sono molto meno comuni degli hack clueless che scriveranno una ifdichiarazione per correggere un bug, e quando sorgono più bug basta aggiungere a quella frase invece di pensare "Forse c'è un modo migliore per farlo" e rifattorizzare il codice in modo che sia estendibile correttamente.

Essere consapevoli di ciò che potrebbe accadere (futuro) non è MAI negativo. Pensare a quale potrebbe essere un modo migliore per fare qualcosa fa parte di ciò che ti rende bravo nel tuo lavoro. La parte più difficile è determinare se il tempo trascorso: il rapporto di payoff è giustificato. Abbiamo visto tutti situazioni in cui le persone fanno il "facile se" per fermare l'emorragia immediata (e / o urlare) e che quando si sommano si ottiene un codice confuso. Molti di noi hanno anche sperimentato un'astrazione esagerata che è un mistero una volta che il programmatore originale va avanti, che produce anche codice confuso.

Vorrei esaminare la tua situazione e porre queste domande:

1. Questo codice è fondamentale per la missione e sarà significativamente più stabile se ricodico? In chirurgia parlano, questo refactoring salva vita o è semplicemente elettivo e cosmetico?

2. Sto considerando il codice di refactoring che sostituiremo tra 6 mesi?

3. Sono disposto a dedicare tanto tempo per documentare il design e il mio ragionamento per i futuri sviluppatori quanto devo dedicare al refactoring?

4. Per quanto riguarda il mio elegante design per l'aggiunta di funzionalità future, è questo nel codice a cui gli utenti richiedono modifiche ogni settimana o è la prima volta che lo tocco quest'anno?

Ci sono momenti in cui YAGNI e KISS vincono il giorno, ma ci sono giorni in cui un cambiamento fondamentale ti porterà dalla spirale discendente alla merda. Finché sei realistico nella tua valutazione non solo di ciò che desideri, ma di ciò che gli altri dovranno fare per mantenere il tuo lavoro, sarai in grado di determinare meglio quale sia la situazione. Oh, e non dimenticare di scrivere quello che hai fatto e perché. Salverà coloro che ti seguono, ma anche te stesso quando dovrai tornare più tardi.

Nella seconda edizione di "Il linguaggio di programmazione C ++" di Stroustrups, (non ho la pagina disponibile) ho letto

Non aggiungere il codice spontaneamente sul posto.

e sono andato bene seguendo il consiglio. Ovviamente ci sono dei compromessi e devi trovare un equilibrio, ma i frammenti corti sono meglio testabili di un grosso pasticcio di spaghetti.

Ho spesso sperimentato che, differenziando da un caso a due casi, se pensi a 2 come n-casi, apri una porta a molte nuove possibilità, alle quali potresti non aver pensato.

Ma poi devi fare la domanda YAGNI: ne vale la pena? Sarà davvero utile? Essere esperti significa che raramente sbaglierai e come principiante più spesso sbagli.

Dovresti essere abbastanza critico da riconoscere un modello e rilevare se il tuo codice è difficile da mantenere, a causa di troppa astrazione o difficile da mantenere, perché tutto è risolto sul posto.

La soluzione non è questa o quella, ma a pensarci. :)

"un buon codice che può fare solo A è peggio di un cattivo codice che può fare A, B, C e D."

Questo può avere un senso nello sviluppo del prodotto; Ma la maggior parte dei professionisti IT lavora nei "progetti" piuttosto che nello sviluppo dei prodotti.

Nei "progetti IT", se si programma un buon componente, funzionerà senza problemi per la durata del progetto - che potrebbe non durare più di 5 o 10 anni, quindi lo scenario aziendale potrebbe diventare obsoleto e un nuovo progetto / ERP il prodotto potrebbe averlo sostituito. Durante questo periodo di vita di 5/10 anni, a meno che l'here non sia un difetto nel tuo codice, nessuno noterà la sua esistenza e i meriti dei tuoi pensieri migliori non saranno notati! (a meno che tu non sia bravo a suonare forte la tua tromba!)

Non molti hanno l'opportunità di programmare "Windows Ctl + Alt + Canc" e quei pochi hanno questa possibilità che non possono realizzare il potenziale futuro del loro codice!

Molti libri sullo sviluppo snello e / o agile aiuteranno a rafforzare questo approccio: fai ciò che è necessario in questo momento. Se sai che stai costruendo un framework, quindi aggiungi le astrazioni. Altrimenti, non aggiungere complessità fino a quando non ne hai bisogno. Raccomando Lean Software Development , che introdurrà molti altri concetti che possono fare una differenza sostanziale nella produttività.

È divertente il modo in cui le persone parlano del modo giusto / sbagliato di fare le cose. Allo stesso tempo, il compito della programmazione è ancora dolorosamente difficile e non offre buone soluzioni per scrivere grandi sistemi complessi.

Può darsi che un giorno noi programmatori riusciremo finalmente a capire come scrivere software complessi. Fino ad allora ti suggerisco di iniziare sempre con l'implementazione del prototipo "stupido", e poi dedicare appena il tempo necessario al refactoring in modo che i tuoi college possano seguire il tuo codice.

Avendo visto progetti così generalizzati prematuramente che non si adattavano affatto ai requisiti reali che sono venuti in seguito, ho escogitato una regola per me:

Per requisiti ipotetici scrivere solo un codice ipotetico.

Cioè: si consiglia di pensare ai cambiamenti che potrebbero verificarsi in seguito. Ma usa solo queste intuizioni per scegliere un design per il codice che può essere facilmente modificato e refactored se tali requisiti effettivamente si presentano. Puoi anche scrivere un codice nella tua testa (codice ipotetico) che vorresti scrivere in quel caso, ma non scrivere alcun codice reale!

Penso che la mentalità che ti aiuterà è quella di cercare sempre soluzioni concrete ai problemi di codifica anziché soluzioni astratte. Le astrazioni devono essere aggiunte solo quando aiutano effettivamente a semplificare la base di codice (quando, ad esempio, consentono di ridurre la base di codice).

Molti programmatori hanno scoperto che le astrazioni emergono quasi da sole, quando asciugano il loro codice. I modelli di progettazione e le migliori pratiche ti aiutano a trovare opportunità per fare proprio questo, ma non sono obiettivi che vale la pena perseguire.

Penso che l'eccessiva ingegneria spesso sembra insicurezza riguardo alla scrittura del codice. Tutti i principi e gli schemi astratti dovrebbero essere trattati come strumenti per aiutarti. Quello che succede spesso è che sono trattati come standard, uno deve conformarsi.

Credo che un programmatore sia sempre in una posizione migliore per decidere come astrarre di un assioma.

Il resto è già stato detto da KeithS

Chiediti quali sono i vantaggi di un buon design:

• Più facile da capire
• Più facile da mantenere
• Portatile
• Rimane utile per molto tempo
• Facile aggiungere nuove funzionalità

Ora, chiediti se l'aggiunta di tutti quegli strati di astrazioni si aggiunge davvero a uno dei punti sopra menzionati. In caso contrario, lo stai facendo SBAGLIATO .

Se riesci ad aggiungere nuove funzionalità aggiungendo 3 righe di codice in questo modo:

if (condition()) {
  doSomething()
}

Poi si prega, si prega di fare così. Questo indica che il tuo design precedente era buono e facile da adattare. Solo una volta che le tue classi iniziano a crescere oltre un certo limite, usa il refactoring per dividere le funzioni ed eventualmente estrarre nuove classi.

La mia regola empirica è che le nuove funzionalità dovrebbero essere implementate nel modo più minimalista possibile, solo quando qualcosa è troppo grande da capire in anticipo (diciamo, impiega più di 1 giorno o mezza giornata per implementare) è possibile aggiungere un progetto globale approssimativo. Da lì in poi, aggiungi i livelli di astrazione solo quando la dimensione del codice aumenta. Successivamente rifattori! Dopo un po 'dovrebbe anche esserti naturale quando hai bisogno di progettare un pezzo un po' di più o andare per la strada veloce. Un'altra indicazione che un codice può utilizzare per la pulizia è quando lo riutilizzi. Ogni volta che aggiungi una nuova funzionalità o chiami il vecchio codice in una nuova posizione, è un buon momento per guardare il vecchio codice e vedere se puoi migliorarlo un po 'prima di aggiungerlo di nuovo. In questo modo, l'hot code diventerà lentamente più pulito, mentre le parti poco interessanti marciranno lentamente e non impiegheranno il tuo tempo prezioso.

Se lavori così, non progetterai mai nulla. Potrebbe volerci un po 'di disciplina per tornare al vecchio codice quando si desidera aggiungere qualcosa di nuovo o lasciare un nuovo codice leggermente più brutto di quello che si desidera, ma si lavorerà verso qualcosa di produttivo anziché troppo ingegnerizzato.