Quando diventa eccessivo?

Stai facendo troppi quando lo sviluppatore medio non riesce a capire cosa hai fatto leggendo il tuo codice.

• Esegui frequenti revisioni del codice con il tuo team.
• Discuti con le architetture, le tecnologie o i modelli che prevedi di utilizzare. (nelle riunioni quotidiane stand-up se li hai)

Combatto tutti gli architetti guidati dal CV che incontro. Desidero dome esistito! ;)

Credo che il mondo stia sprecando un'enorme quantità di denaro che potremmo usare per migliorare la nostra vita (programmatrice).

Quando i processi superano i risultati.

Troppe volte abbiamo visto che se gli sviluppatori si concentrano maggiormente sul processo piuttosto che sui risultati (come nella qualità, nella scadenza, ecc.) iniziano le cose cattive.

Questo è il motivo per cui non dovrebbe mai essere dimenticato che lo scopo delle revisioni del codice, dei modelli di progettazione, ecc. è quello di rendere il codice migliore, ma non sono loro stessi l'obiettivo.

Per me mi piace l'approccio che Kent Beck propone in XP (non è sicuro che sia la "sua" idea o quella di qualcun altro ma è lì che l'ho sentito per la prima volta):

È abbastanza difficile risolvere i problemi di oggi senza cercare di capire quali sono i problemi di domani e risolverli.

Gli sviluppatori possono dedicare molto tempo a soluzioni per requisiti che non esistono, casi limite che non si verificheranno mai o anche problemi reali in cui l'impatto del problema è significativamente inferiore al costo di impedirlo.

Questo è il tempo che potrebbe essere messo in cose che gli utenti vorranno e utilizzeranno veramente, cose che daranno loro benefici che supereranno in maniera massiccia anche i disagi che saranno causati nell'improbabile caso in cui una di queste cose avvenga realmente.

Al di là anche di questo risultato non ottimale per l'utente, l'impatto sullo sviluppatore dell'over engineering in questo modo tende ad essere un codice complesso che è più difficile da supportare e più difficile da migliorare.

Quindi per me se sai, o puoi essere abbastanza sicuro, che qualcosa è un requisito o che causerà un problema, allora indirizzalo, altrimenti non farlo.

Potrebbe essere necessario tornare indietro e rielaborarlo quando si scopre che c'era un requisito più ampio rispetto a quello originariamente implementato, ma in generale lo sforzo totale inserito nel progetto sarà comunque inferiore perché nella maggior parte dei casi ciò non accadere.

La tua domanda è abbastanza aperta, quindi la interpreterò come "fare troppo su una parte del progetto":

Per me, è facile passare troppo tempo su qualcosa che in realtà non fornisce molto guadagno per il cliente. Spesso, sono le piccole cose come "Beh, funziona, ma non del tutto come lo voglio anch'io", dove il cliente probabilmente non si preoccuperebbe se funzionasse in questo modo o in un altro.

Quando ciò accade, dovrei fermarlo e dedicare del tempo a cose che sono più importanti. È meglio che il prodotto funzioni nel suo insieme, ma hai queste parti più piccole che funzionano perfettamente.

Scrivere codice tracer (da Codice completo ) è probabilmente una buona idea per evitare questo: si avvia il progetto scrivendo un codice che connette l'intero codice - dalla GUI (o vicino ad esso) tutto il modo per il back-end e poi indietro. In questo modo hai sempre qualcosa che funziona e non passi il tempo a perfezionare le piccole cose fino a quando l'intera cosa non funziona.

Tuttavia, è una questione di disciplina e di priorità.

Quando rispondo no a "sto diventando pazzo, non l'ho fatto più tardi e mi morde ..

IRL I limiti di tempo e risorse di solito mi danno prima di dover fare questa domanda molto però. A quel punto, ti concentri solo sui bit più importanti / realizzabili e speri per il meglio.

davvero un processo di apprendimento senza fine! ... e penso che rimanga così! L'equilibrio è quando le cose sono abbastanza efficienti e hai il tempo di fare qualcos'altro oltre alla programmazione. Sono d'accordo con il gabinetto "una questione di disciplina e di priorità" e jim hopkins su quello diventa istinto dopo un po '. So che perfezionare le piccole parti è ciò che ci rende felici, ma alla fine è tutto ciò che rende felice l'utente finale. quindi direi che il bilanciamento (o forse il compromesso) è quello di rendere felice l'utente / cliente / cliente (che dovrebbe essere il piano A) e poi se c'è tempo a lavorare sul perfezionamento - rendendo più efficienti le "parti piccole" e / o tutto il resto per favore. Ad un certo punto devi dire "abbastanza" però :) altrimenti sì, diventerà un overkill!

lo scenario peggiore è ovviamente quando l'utente finale / cliente / cliente sei tu! :)