Quando diventa eccessivo?

Prima di tutto, mi scuso perché non so come creare un thread della community; quindi qualcuno mi aiuti per favore.

Come sviluppatore, su molte piattaforme, tecnologie e persino a livello di infrastruttura; Mi ritrovo sempre a chiedere, quando sto facendo TROPPO troppo?!?

È stato un processo di apprendimento senza fine, da quando ho iniziato. Una (1) cosa che ho imparato è che i requisiti sono a malapena validi per un lungo periodo di tempo, e come tale una piccola previsione può fare molto.

Ma dov'è l'equilibrio e come fai a sapere quando stai perdendo tempo, non guadagnando ?!

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

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

Combatto contro tutti gli "architetti" guidati da CV che incontro. Vorrei che la cupola esistesse! ;)

Credo che il mondo stia sprecando un enorme mucchio di soldi che potremmo usare per migliorare la nostra vita (da programmatore).

Quando i processi superano i risultati.

Troppe volte abbiamo visto che se gli sviluppatori si stanno concentrando maggiormente sul processo piuttosto che sui risultati (come in termini di qualità, scadenze, ecc.) Iniziano le cose brutte.

Questo è il motivo per cui non si dovrebbe mai dimenticare che lo scopo delle revisioni del codice, dei modelli di progettazione, ecc. È di migliorare il codice, ma non sono l'obiettivo stesso.

Per me mi piace l'approccio che Kent Beck propone in XP (non sono sicuro che si tratti della "sua" idea o 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 inesistenti, casi limite che non si verificheranno mai o addirittura problemi reali in cui l'impatto del problema è significativamente inferiore al costo di prevenirlo.

Questo è il tempo che potrebbe essere messo in cose che gli utenti vorranno e utilizzeranno davvero, cose che daranno loro benefici che supereranno enormemente anche l'inconveniente che sarà causato nell'improbabile caso in cui una di queste cose accada realmente.

Al di là di questo risultato non ottimale per l'utente, l'impatto sullo sviluppatore dell'ingegnerizzazione eccessiva in questo modo tende a superare il 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 sta per causare un problema, risolvilo, altrimenti non lo fai.

Potrebbe essere necessario tornare indietro e rielaborarlo quando si scopre che c'era un requisito più ampio di quello implementato originariamente, ma in generale lo sforzo totale che si fa attraverso il progetto sarà ancora inferiore perché nella maggior parte dei casi ciò non accadrà.

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

Per me, è facile dedicare troppo tempo a qualcosa che in realtà non offre molto guadagno al cliente. Spesso sono le cose minuscole come "Beh, funziona, ma non del tutto come lo voglio anch'io" dove probabilmente al cliente non importerebbe se funzionasse in questo modo o in un altro.

Quando ciò accade, dovrei fermarlo e dedicare 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 il codice tracciante (da Codice completo ) è probabilmente una buona idea per evitarlo: si avvia il progetto scrivendo il codice che collega l'intero codice - dalla GUI (o vicino ad esso) fino al backend e poi indietro. In questo modo hai sempre qualcosa che funziona e non passi il tempo a perfezionare le piccole cose finché l'intera cosa non funziona.

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

Quando rispondo di no a "sto per diventare matto non l'ho fatto più tardi e mi morde ..

I vincoli di tempo e risorse IRL di solito mi prendono prima che io debba porre questa domanda molto però. A quel punto ti concentri solo sui bit più importanti / realizzabili e speri per il meglio.

un processo di apprendimento senza fine davvero! ... e penso che rimanga così! L'equilibrio è quando le cose sono abbastanza efficienti e hai il tempo di fare qualcos'altro oltre alla programmazione. Concordo con Gablin "una questione di disciplina e di definizione delle priorità" e Jim Hopkins su che dopo un po 'diventerà istinto. 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 l'equilibrio (o forse il compromesso) è prima rendere felice l'utente finale / cliente / cliente (che dovrebbe essere il piano A) e poi se c'è tempo di lavorare sul perfezionamento - rendere più efficienti le "piccole parti" e / o tutto il resto per favore. Ad un certo punto devi dire "abbastanza" però :) altrimenti sì, diventerà eccessivo!

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