Come si fa a bilanciare tra "farlo bene" e "farlo al più presto" nel lavoro quotidiano? [chiuso]


180

Mi ritrovo a riflettere su questa domanda di volta in volta, ancora e ancora. Voglio fare le cose nel modo giusto: scrivere codice pulito, comprensibile e corretto, facile da mantenere. Comunque, quello che finisco per fare è scrivere patch su patch; solo perché non c'è tempo, i clienti stanno aspettando, un bug dovrebbe essere risolto dall'oggi al domani, la società sta perdendo soldi su questo problema, un manager preme forte ecc., ecc.

So perfettamente che a lungo termine sto perdendo più tempo su queste patch, ma poiché questa volta dura mesi di lavoro, a nessuno importa. Inoltre, come diceva uno dei miei manager: "non sappiamo se ci sarà un lungo termine se non lo ripariamo ora".

Sono sicuro di non essere l'unico intrappolato in questi infiniti cicli di scelta reale / ideale. Allora, come colleghi miei programmatori, come affrontate questo?

AGGIORNAMENTO: Grazie a tutti per questa interessante discussione. È triste che così tante persone debbano scegliere quotidianamente tra una quantità e una qualità del loro codice. Tuttavia, sorprendentemente molti, la gente pensa che sia possibile vincere questa battaglia, quindi grazie a tutti per questo incoraggiamento.


12
Semplice: fallo bene e veloce
ren

158
@ren: Beh, suppongo che non sei un programmatore, sei un manager :-)
Flot2011

44
Obbligatorio. xkcd.com/844
MikeTheLiar il

5
Fallo al più presto. Quindi se hai ancora tempo, fallo nel modo giusto.
Laurent Couvidou,

8
Come dice lo zio bob: la via lenta è la via più veloce. Prenditi il ​​tempo necessario per scrivere quei test unitari e scrivi bene il tuo codice. Ciò potrebbe richiedere un po 'più di tempo per l'implementazione della funzione, ma farà risparmiare tempo a lungo termine poiché sarà più facile per gli altri modificare e correggere i bug.
martiert

Risposte:


106

In realtà, questa è una domanda molto difficile perché non esiste una risposta assolutamente giusta. Nella nostra organizzazione abbiamo messo in atto processi migliori per produrre codice migliore. Abbiamo aggiornato i nostri standard di codifica per riflettere come noi, come gruppo, scriviamo codice e abbiamo istituito un ciclo di test / refactor / design / code molto forte. Consegniamo continuamente o almeno ci proviamo. Per lo meno, abbiamo qualcosa da mostrare agli stakeholder ogni due settimane. Riteniamo di essere artigiani del software e il morale è alto. Ma, nonostante tutti questi controlli e saldi, soffriamo dello stesso problema che si presenta.

Alla fine della giornata, stiamo consegnando un prodotto a un cliente pagante. Questo cliente ha esigenze e aspettative, realistiche o meno. Spesso il team di vendita ci mette nei guai solo per ottenere una commissione. A volte il cliente ha aspettative go-live che non sono realistiche o richiedono cambiamenti anche se abbiamo un contratto in essere. Le tempistiche accadono. PTO e giorni persi durante uno sprint possono accadere. Ogni sorta di piccole cose può culminare in una situazione in cui siamo costretti all'enigma di "fallo nel modo giusto" o "fallo al più presto". Quasi sempre, siamo costretti a "farlo al più presto".

Come artigiani del software, sviluppatori, programmatori, persone che programmano per un lavoro - è la nostra naturale propensione a "farlo bene". "Fallo al più presto" è ciò che accade quando lavoriamo per sopravvivere, come la maggior parte di noi. Il bilancio è difficile.

Comincio sempre avvicinandomi al management esecutivo (sono il direttore dello sviluppo software e uno sviluppatore attivo in quel gruppo) per difendere il programma, il team e il lavoro svolto. Di solito a quel punto mi viene detto che il cliente deve averlo ora e deve funzionare. Quando so che non c'è spazio per la negoziazione o per dare, torno indietro e lavoro con la squadra per vedere quali angoli possono essere tagliati. Non sacrificherò la qualità nella funzione che sta guidando la necessità del cliente di ottenerlo al più presto, ma qualcosa andrà e verrà spinto in un altro sprint. Questo è quasi sempre OK.

Quando non sei in grado di fornire perché ci sono così tanti bug, la qualità del codice è cattiva e peggiora e le scadenze si accorciano, allora ti trovi in ​​una situazione diversa da quella che descrivo. In tal caso, cattiva gestione attuale o passata, cattive pratiche di sviluppo che hanno portato a una scarsa qualità del codice o altri fattori potrebbero portarti in una marcia della morte.

La mia opinione qui è di fare del tuo meglio per difendere il buon codice e le migliori pratiche per iniziare a far uscire la tua azienda dalle trincee. Se non c'è un solo collega disposto ad ascoltare o andare a battere il gruppo contro la direzione, allora potrebbe essere il momento di iniziare a cercare un nuovo lavoro.

Alla fine, la vita reale vince su tutto. Se lavori per un'azienda che ha bisogno di vendere ciò che stai sviluppando, allora incontrerai questo compromesso ogni giorno. Solo sforzandomi di raggiungere presto buoni principi di sviluppo sono riuscito a stare al passo con la curva della qualità del codice.

Il push and pull tra sviluppatori e venditori mi ricorda uno scherzo. "Qual è la differenza tra un venditore di auto usate e un venditore di software? Almeno il venditore di auto usate sa di mentire." Tieni il mento sollevato e cerca di "fare la cosa giusta" mentre procedi.


14
"Spesso il team di vendita ci mette nei guai solo per ottenere una commissione" - A che punto considereresti che le vendite debbano essere ritenute responsabili della vendita di qualcosa che l'azienda non può fornire - supponendo che ce ne sia una? Hai esempi in cui hanno superato il confine tra marketing aggressivo e overselling?
Tom W,

8
@TomW Ho diversi esempi interni, specifici che non potrei pubblicare qui, ma quando succede succede quasi sempre quando abbiamo bisogno di un account di riferimento o verso la fine del trimestre. Abbiamo alcuni venditori molto buoni e altri meno bravi. Recentemente c'è stato un grande cambiamento nella pulizia delle case dopo che si è stabilito che lo sviluppo non era il problema e che l'intera struttura di vendita è cambiata in meglio. Le cose sono andate meravigliosamente da allora. Mi piacerebbe essere più specifico, ma non posso.
Akira71,

9
+1 - "Non sacrificherò la qualità della funzionalità che sta guidando i clienti per ottenerla al più presto, ma qualcosa andrà" ... è stato fantastico.
Gioele B,

59
@TomW - Mi piace sempre sottolineare che il principale architetto navale del Titanic che ha messo in guardia contro il taglio dei costi (Thomas Andrews) è andato giù con la nave mentre il ragazzo più venduto / di marketing che ha sollecitato il taglio dei costi e ha fatto le cose al più presto (Bruce Ismay) è fuggito in una scialuppa di salvataggio.
jfrankcarr,

4
Mi sarebbe piaciuto avere il tempo di digitare una risposta come questa, ma ho un cliente che piange al mio capo al telefono. "Spesso il team di vendita ci mette nei guai solo per ottenere una commissione." Lo stesso qui ... ma in qualche modo ottengono ancora quei bonus!
Kenzo,

62

Una cosa che ho capito nella mia carriera è che c'è sempre tempo per farlo bene. Sì, il tuo manager potrebbe spingere. Il client potrebbe essere incazzato. Ma non sanno quanto tempo ci vogliono per fare. Se tu (il tuo team di sviluppo) non lo fai, non viene fatto; hai tutta la leva.

Perché sai che cosa farà davvero incazzare il tuo manager o il tuo cliente? Scarsa qualità .


43
Mentre di solito c'è tempo per fare un buon lavoro, di solito non c'è tempo per farlo perfettamente. C'è un mondo di differenza tra i due.
Donal Fellows,

2
@DonalFellows ovviamente. "Giusto" è sempre "seguire le migliori pratiche, usando la nostra migliore comprensione del problema a questo punto, al meglio delle nostre capacità". Le persone fanno errori. I requisiti cambiano. Le migliori pratiche cambiano. Non tagliare angoli e rifrattore quando succede qualcosa .
Telastyn,

3
@DonalFellows - "Il nemico dell'eccellenza è la perfezione". Un programma scritto in modo sostenibile, che soddisfa i requisiti dei clienti e lo fa con prestazioni accettabili, è un programma che viene "fatto". Niente torre d'avorio al riguardo.
Keith

1
@DonalFellows Nessuno ha usato la parola perfetto, una soluzione perfetta è una soluzione sbagliata, Telastyn sta parlando di una soluzione giusta. La soluzione giusta è quella che soddisfa i requisiti ed è improbabile che possa causare problemi in futuro, pur essendo facile da gestire in caso affermativo. Gli assoluti sono sempre sbagliati.
Jimmy Hoffa,

7
+1 - Per Telastyn, mentre tutti i clienti vogliono che le loro cose vengano fatte adesso. MOLTO ALTRO clienti vogliono che le loro cose funzionino più di quanto non lo facciano adesso. Sembra che tutti coloro che non sono d'accordo con Telastyn affermino che perderanno un cliente se non viene fatto rapidamente. Questa è di gran lunga l'eccezione e non la regola. Qual è la regola, che la maggior parte delle persone che non sono d'accordo, è che stanno ignorando che perderanno molti più clienti offrendo prodotti scadenti. L'affermazione che il cliente lo desidera ora è la solita scusa delle persone che non si preoccupano della qualità. Quindi sono scettico sul rischio dichiarato.
Dunk,

21

Questo si riduce a quello che ho iniziato a pensare come "The Eternal Conflict" (tra business e ingegneria). Non ho la soluzione in quanto è un problema che non scompare mai, ma puoi fare cose per mitigare.

  • Comunicare valore

Ciò che la gente spesso non capisce è che come ingegneri stiamo solo assumendo che il problema del "business di successo" sia sempre scontato. Vogliamo che il nostro codice sia carino, ordinato e mantenibile in modo da poter aggiungere nuove funzionalità e modificare quelle esistenti rapidamente e con un minimo di clienti che eseguono il QA per noi scoprendo bizzarri casi marginali che sarebbero stati vanificati da un codice migliore. Mantenere i clienti e mantenere un vantaggio competitivo con funzionalità e finezza che nessun altro è in grado di produrre abbastanza velocemente sono entrambe le conquiste aziendali a cui il buon codice contribuisce direttamente e informa gran parte del motivo per cui desideriamo un codice migliore in primo luogo.

Quindi spiegalo. "Vogliamo fare X nella nostra base di codice perché se non lo facciamo avrà un impatto negativo sul business a causa di Y" o "... perché migliorerà la nostra capacità di rimanere competitivi migliorando la nostra capacità di trasformare i nuovi miglioramenti e funzionalità più velocemente ".

E fai del tuo meglio per cercare di ottenere prove tangibili del funzionamento dei miglioramenti. Se il miglioramento di un sottoinsieme di un'app ha comportato una funzionalità / un miglioramento più rapidi, controlla lo strumento di backlog che potresti utilizzare per dimostrarne l'evidenza e segnalalo alle riunioni appropriate.

  • Porta il team sulla stessa pagina maledetta

Gli ego sono spesso un problema. Una cosa di cui i team di ingegneri hanno molto bisogno è stabilire il valore di avere un qualche tipo di approccio coerente concordato per risolvere determinati tipi di problemi rispetto a tutti quelli che fanno la propria coppa di Kool Aid d'jour perché conoscono meglio. Va bene credere che la preferenza dell'altro sia peggiore della tua, ma apprezza la coerenza rispetto all'essere più giusti se il suo approccio è praticabile ed è un argomento che non puoi vincere. Il compromesso per coerenza è fondamentale. Quando le cose sono coerenti, è più difficile sbagliarle poiché il modo coerente stabilito di solito sarà anche il modo più veloce.

  • Scegli gli strumenti giusti

Esistono due scuole di framework / set di strumenti / librerie / qualunque cosa. "Prepara il 99% per me, quindi devo sapere / fare molto poco" vs. "Stammi lontano quando non ti voglio lì, ma aiutami il fai-da-te molto rapidamente e coerentemente con le cose che voglio davvero da utilizzare sulla carota anziché sul principio "stick". Favorisci il secondo. Flessibilità e controllo granulare non dovrebbero mai essere sacrificati sull'altare della rapida inversione di tendenza perché a biz, "non possiamo farlo perché i nostri strumenti non ci permettono" non è mai una risposta accettabile e la domanda sorgerà sempre per non ingegneria del prodotto banale / monouso. Nella mia esperienza, gli strumenti inflessibili vengono quasi sempre spalancati o aggirati in modo non elegante e rendono un grande pasticcio non mantenibile. Più spesso che non, le soluzioni flessibili / più facili da modificare sono altrettanto o quasi altrettanto veloci a breve termine, indipendentemente. Veloce, flessibile e gestibile sono possibili con gli strumenti giusti.

  • FFS, se gli ingegneri non decidono, ottenere almeno l'input dell'ingegnere sulla scelta degli strumenti

Ho l'impressione che si tratti di una domanda dal punto di vista dello sviluppatore, ma mi sono trovata in troppe situazioni in cui le decisioni tecnologiche sono state prese con zero input da ingegnere. Che diavolo è quello? Sì, qualcuno alla fine deve effettuare la chiamata finale, ma ottenere alcune opinioni qualificate se sei un manager non tecnico, non quello che dice un addetto alle vendite o un sito demo sui propri prodotti. Tutto ciò che promette di risparmiare denaro perché le persone non hanno bisogno di essere così intelligenti o perché protegge gli sviluppatori da se stessi è una sporca, sporca menzogna. Assumi talenti di cui ti puoi fidare. Spiega loro ciò che vuoi da uno stack o altra soluzione tecnologica e prendi sul serio il loro contributo prima di decidere su quale carrozzone tecnologico saltare.

  • Focus sulla progettazione oltre l'implementazione

Gli strumenti sono per l'implementazione e come tali possono aiutarti, ma la prima priorità deve essere l'architettura indipendentemente da qualsiasi set di giocattoli che hai per costruire quell'architettura. Alla fine della giornata KISS e DRY e tutte le filosofie eccellenti che si estendono da quelle questioni più che se si tratti di .NET o Java o forse qualcosa che è sia gratuito che non fa schifo.

  • Registra le tue preoccupazioni

Quando il lato biz insiste che lo fai nel modo sbagliato, salva quell'e-mail, specialmente la parte in cui hai detto perché ti costerebbe. Quando tutte le tue previsioni diventano realtà e si verificano gravi problemi dannosi per le aziende, è allora che hai una grande pila di argomenti per prendere più seriamente le preoccupazioni degli ingegneri. Ma cronometra attentamente le cose. Nel mezzo dell'inferno ardente è un brutto momento per un "te lo ho detto" sul seguente codice di fuoco. Spegni il fuoco e porta la tua lista di preoccupazioni precedentemente ignorate a una riunione / conversazione retrospettiva, e cerca di concentrarti sulle preoccupazioni ingegneristiche espresse e ignorate e sul ragionamento che hai capito perché venivano ignorate, non sui nomi delle persone reali prendere la decisione di ignorare. Sei un ingegnere. Rimani sui problemi, non sulle persone. " Abbiamo espresso preoccupazione per X perché temevamo che potesse causare problemi a Y. Ci hanno detto Z e di rimandare a che fare con esso. "


Risposta molto bella e approfondita. Posso aggiungere che ho già avuto un brutto caso di scegliere gli strumenti giusti , che ha prodotto una grande perdita di tempo. Potremmo spedire il prodotto un mese dopo, dopo la decisione di abbandonare questo prodotto e utilizzare qualcosa che non ci blocca.
mhr

1
Mi sento bene con questa risposta, ma ho anche trovato il mio primo lavoro in cui biz e dev non sono costantemente alla gola dell'altro e l'impatto è delizioso. Abbiamo appena fatto le cose. Non sempre quando vorremmo, ma in realtà prendiamo in considerazione il futuro e questo mostra sia il prodotto che la nostra capacità di modificarlo in base alle esigenze. L'inevitabile Big Ball of Mud è una bugia, IMO.
Erik Reppen,

19

C'è solo una soluzione. Riservare circa il 10-20% del tempo di progetto / lavoro per il refactoring. Se è difficile convincere il management che si tratta di un compito giustificabile, dare loro l'unico vero argomento: senza rifattorizzare il costo della manutenzione del codice crescerà esponenzialmente nel tempo. È utile disporre di alcune metriche / articoli / risultati della ricerca per sostenere questa tesi durante l'incontro con il manager :)

Modifica: ci sono alcune buone risorse su "refactoring vs aumento dei costi di manutenzione" menzionate in questo white paper: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf


12
C'è un'opzione migliore: rendere il refactoring parte della tua normale abitudine di codifica. Dayly. Oraria. Ogni volta che aggiungi o modifichi una funzione. Quindi non è necessario riservare altro tempo o "convincere la direzione".
Doc Brown,

È valido solo quando non è necessario gestire codice già scritto. È un'attività comune aggiungere nuovo valore al codice sorgente vecchio / legacy / ereditato. Ma quando guardi quel codice non sai da dove cominciare e senti che è più facile riscrivere quel codice piuttosto che imparare come funziona. Prova a giustificare queste stime: due giorni per aggiungere nuovo valore, sei giorni per riformattare il vecchio codice per renderlo mantenibile. Spesso si sente "non refactoring, basta aggiungere il nuovo valore, scopriremo più tardi cosa fare con quel vecchio codice".
Andrzej Bobak,

1
@ Flot2011 Quindi hai una sola soluzione. Lascia che il refactoring "quotidiano" sia il tuo compito di routine. Ad esempio, ogni martedì si concentra solo sul miglioramento della qualità del codice. Assicurati che sia rispettato dalla direzione e assicurati che sappiano che il refactoring non è una perdita di tempo. Senza queste due condizioni incontrate prima o poi abbandoneranno l'idea di migliorare "qualcosa che è già qui e funziona".
Andrzej Bobak,

1
@DocBrown Funziona quando parli con la direzione. Se parli con lo sviluppatore senior e gli dici che aggiungerai due campi al modulo e ti ci vorranno 3 giorni ... Beh buona fortuna :).
Andrzej Bobak,

2
Dover gonfiare le stime per ottenere i tempi di manutenzione è problematico per una serie di motivi. Talvolta vale la pena sostenere un debito tecnico. Cosa succede quando biz nota improvvisamente che in una situazione di emergenza ci sono voluti 15 minuti per schiaffeggiare due nuovi campi in quando l'ultima volta ci sono voluti 8 giorni. IMO, biz deve essere consapevole del debito tecnologico e dell'impatto a lungo termine che ha. Il problema deve essere compreso o pagando ora o pagando 5 volte tanto più tardi quando tutto è stato detto.
Erik Reppen,

14

Ogni volta che hai tempo per fare qualcosa di giusto, usalo - scrivi il codice migliore che puoi e miglioralo costantemente. Non rendere il tuo lavoro più difficile diventando sciatto e introducendo debiti tecnici quando non ce n'è bisogno.

Le chiamate di emergenza per correggere un bug grave non sono cose che puoi controllare da solo, quando si verificano, devi reagire al più presto, questa è la vita. Naturalmente, se hai l'impressione che tutto il tuo lavoro consista in chiamate di emergenza e non hai mai abbastanza tempo per fare le cose nel modo giusto, allora sei sulla strada per esaurirti e dovresti parlare con il tuo capo.

Se ciò non aiuta, esiste ancora la "strategia di Scotty" per avere abbastanza tempo per fare le cose nel modo giusto: moltiplicare tutte le stime per un fattore 4:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/


La strategia di Scotty funziona. Non far sapere al tuo capo che lo stai facendo. Spesso il tempo necessario nella realtà è doppio. È sempre meglio finire presto che tardi.
Luca,

11

Vedo il mio lavoro come fornire il miglior software di qualità possibile entro i limiti di tempo previsti per il progetto. Se sono preoccupato che il livello di qualità sia basso, allora coinvolgerò il proprietario del progetto. Descrivo le mie preoccupazioni e discuto i potenziali rischi della distribuzione del software in quello stato. A questo punto accadrà una delle 3 cose:

  1. Il proprietario del progetto non vorrà accettare i rischi e riporterà il programma per consentirci di dedicare più tempo alla qualità del software.

  2. Il proprietario del progetto non vorrà accettare i rischi ma non può spostare indietro il programma. In questo caso, dobbiamo negoziare su quali caratteristiche / funzionalità rimuovere dall'ambito del progetto per dedicare più tempo alla qualità del software per le parti principali dell'applicazione.

  3. Il proprietario del progetto accetterà i rischi e il software di bassa qualità uscirà nei tempi previsti. A volte il rischio aziendale di non distribuire nulla (o distribuire in ritardo) è molto maggiore del rischio aziendale di distribuire software di bassa qualità e solo il proprietario del progetto può prendere quella decisione.

Scrivere software è molto simile a dipingere un ritratto. È impossibile dire che un ritratto sia "giusto" o "perfetto". Perfetto è il nemico del fatto. Potresti letteralmente passare 1 mese a lavorare su un singolo metodo e non è ancora considerato "perfetto" da alcuni. Il mio compito è dipingere un ritratto di cui il cliente sia soddisfatto.


7

Questo non funzionerà in ogni caso, ma ho avuto un po 'di fortuna usando questa strategia se il problema è un problema di produzione rotto che deve essere risolto con urgenza. Stimare il tempo per eseguire una correzione rapida per avviare la produzione e il tempo per eseguire la correzione di qualità per il futuro. Presenta le stime al tuo capo / cliente e ottieni il tempo approvato per entrambi. Quindi esegui la correzione rapida per avviare la produzione e una correzione a lungo termine immediatamente dopo quando la pressione del tempo urgente è disattivata. Trovo che se lo presento come ho bisogno questa volta per fare il lavoro giusto, ma posso mettere in atto una correzione temporanea fino a quando non posso farlo, che i miei clienti sembrano apprezzare questo approccio. Fa funzionare di nuovo il pungolo e si prende cura del bisogno a lungo termine.


7

L'equilibrio ottimale potrebbe essere quello di dedicare tutto il tempo extra a farlo nel modo giusto che sprecheresti a correggere i bug eliminati facendolo correttamente. Evitare la doratura della soluzione. Nella maggior parte dei casi la soluzione Volkswagen fatta nel modo giusto è buona come la soluzione Cadillac. Di solito è possibile effettuare l'aggiornamento in un secondo momento quando è dimostrato che è necessaria la Cadillac.

La correzione del codice che non ha seguito le migliori pratiche spesso richiede molto più tempo. Cercare di trovare da dove proviene il null quando la chiamata assomiglia ad abcde (), può richiedere molto tempo.

L'applicazione di DRY e il riutilizzo del codice esistente sono in genere molto più veloci della codifica e del test di un'altra soluzione. Inoltre semplifica l'applicazione delle modifiche quando si verificano. Devi solo modificare e testare un set di codice, non due, tre o venti.

Obiettivo per un solido codice di base. Un sacco di tempo può essere sprecato cercando di renderlo perfetto. Esistono buone pratiche che portano a un codice veloce, ma non necessariamente il più veloce possibile. Oltre a ciò, cercare di anticipare i colli di bottiglia e ottimizzare il codice man mano che viene costruito può farti perdere tempo. Ancora peggio, l'ottimizzazione potrebbe rallentare il codice.

Quando possibile, fornire la soluzione di lavoro minima. Ho visto settimane sprecate soluzioni di doratura. Prestare estrema attenzione all'ambito.

Ho trascorso un po 'di tempo lavorando a un progetto che avrebbe dovuto durare sei mesi. Quando mi sono iscritto, era in corso da un anno e mezzo. Il responsabile del progetto aveva posto una domanda all'inizio al project manager: "Vuoi che lo faccia nel modo giusto o che sia reattivo?" In una settimana, una funzionalità è stata implementata lunedì, mercoledì e venerdì; Martedì e giovedì la funzionalità è stata rimossa.

EDIT: quando il codice viene eseguito a un livello soddisfacente, lasciarlo. Non tornare indietro per risolverlo se ti viene in mente un modo migliore per farlo. Se devi prendere una nota. Se sono necessarie modifiche, rivedi la tua idea e implementala, se ha ancora senso.

Se esistono aree in cui implementare le estensioni per le funzionalità imminenti, non implementare le estensioni. È possibile lasciare un commento marcatore per ricordare dove apportare le modifiche.


A meno che DRY non significhi implementazione confusa, illeggibile, di enormi schemi ereditari a cascata. Non farlo. Mi dispiace, lo dico molto, ma lo odio davvero. Inoltre, +1 per una soluzione di lavoro minima nella maggior parte dei casi. A volte alcune caratteristiche architettoniche lungimiranti possono essere utili purché non esagerino.
Erik Reppen

1
Il codice @ErikReppen, che è confuso, illeggibile e un'implementazione di enormi schemi ereditari a cascata fallirebbe con la mia definizione di DRY. Se è necessario capire il codice ogni volta che lo si utilizza, il progetto chiaramente non riesce a SECCO anche se l'implementazione passa.
BillThor il

Tuttavia, può comportare un sacco di riutilizzo del codice. La parte fastidiosa è arrampicarsi su un albero di 18 classi o prototipi per trovare l'effettiva definizione di un metodo che sta facendo qualcosa di veramente fastidioso soprattutto se ci sono sostituzioni.
Erik Reppen,

6

Fallo funzionare e poi rendilo perfetto

Potrei trarre qualche indizio per questo - ma se il tempo è essenziale, allora la tua priorità principale dovrebbe essere quella di farlo funzionare, semplice come quello. Commenta ampiamente le carenze del tuo codice e prendi nota di ciò che hai fatto in qualsiasi software di gestione del progetto / tempo che stai utilizzando.

Spero che questo ti dia più tempo per tornare a questi problemi e renderli perfetti.

Ovviamente non esiste una risposta assolutamente corretta a questo, ma è una risposta a cui cerco di attenermi. Tuttavia, potresti non trovarlo adatto al tuo stile di lavoro attuale. Il che mi porta all'alternativa ...

Basta trovare un metodo che funzioni per te ; e poi attenersi ad esso. Ognuno ha il proprio modo di gestire i progetti e non esiste un approccio "taglia unica". Trova un approccio e rendilo tuo.


3
Quando la direzione sa che funziona. Lo prendono come fatto e non vogliono che tu spenda altri sforzi per il refactoring, ecc.
Adronius

5

"Fare la cosa giusta" significa fare i giusti compromessi per una situazione particolare. Alcuni di loro sono:

  1. Tempi e costi di sviluppo
  2. Facilità di lettura, debug e aggiornamento del codice in un secondo momento (tutto, dai nomi delle variabili all'architettura)
  3. Accuratezza della soluzione (casi limite)
  4. Velocità di esecuzione

Ovviamente, se un pezzo di codice verrà usato una volta e gettato via, il numero 2 può essere sacrificato per uno qualsiasi degli altri. (Ma attenzione: potresti pensare di buttarlo via, quindi scoprire che devi continuare a usarlo e mantenerlo, a quel punto sarà più difficile convincere le persone a darti il ​​tempo di migliorare qualcosa che "funziona".)

Se tu e / o il tuo team continuerete a utilizzare e aggiornare del codice, prendere scorciatoie ora significa solo rallentarvi in ​​seguito.

Se al momento stai fornendo codice errato (debole su # 4) e impiegando molto tempo per farlo (debole su # 1), ed è perché stai cercando di aggiornare il codice debole su # 2, beh, hai ho un argomento solido e pragmatico per cambiare le tue pratiche.


1
Vorrei suggerire: "Se NESSUNO riuscirà mai a mantenere un pezzo di codice ...": scrivere spazzatura, scaricare e correre non dovrebbe essere un'opzione (per chiunque abbia una coscienza), ma succede troppo spesso; appaltatori / consulenti / manager che si assicurano che siano fuori dalla porta appena prima che "colpisca" il ventilatore.
Phill W.

@PhillW. - assolutamente d'accordo. Modificato di conseguenza.
Nathan Long

4

Se è un bug, fallo al più presto, se è una nuova funzionalità, prenditi il ​​tuo tempo.

E se lavori per un'azienda che non rispetta il lavoro degli sviluppatori, potresti non avere altra scelta che farlo velocemente e sacrificare la qualità.

Ho lavorato per un certo numero di aziende che sarebbero passate da un progetto all'altro e fare tutto in fretta. Alla fine, hanno avuto scarso successo in ogni progetto perché l'implementazione (non solo la programmazione) è stata velocizzata.

Le migliori aziende là fuori capiscono che un buon software richiede tempo e maestria.


3

In caso di emergenza, creare la soluzione di patching. Crea un nuovo bug nel tracciamento dei bug menzionandolo. Rendi giusto, ogni volta che hai tempo adatto.


5
Il problema è che non c'è quasi mai tempo adatto, questo è esattamente il problema, e bug di questo tipo avranno sempre la priorità più bassa.
Flot2011,

Direi che questo è vero solo se per "emergenza" intendi "qualcosa che accade non più di una volta ogni sei mesi" e per "quando hai tempo" intendi "entro una settimana circa". Altrimenti la tua domanda di follow-up diventa "aiuto, il cliente ha bisogno di qualcosa al più presto, ma il codice che devo cambiare è un casino confuso e mi ci vorranno settimane per risolvere!"
Nathan Long,

3

Penso di fare quello che fanno tutti coloro che sono bloccati a lavorare in questo settore. Lo faccio il più velocemente possibile e se devo tralasciare alcune delle cose carine che potrebbero aiutare a prevenire i problemi in futuro o rendere più semplice la risoluzione dei problemi in futuro, lo faccio. Non è una situazione ottimale ma quando sei bloccato con scadenze basate su stime basate su stime, basate su molte variabili sconosciute, è praticamente il meglio che puoi fare.


3

Ecco un buon piano:

  1. Fai in modo che il tuo piano fai-da-te richieda esattamente la stessa quantità di tempo che fai-al-più presto.
  2. Ottimizza il tuo tempo per farlo fino a quando il tuo ambiente è felice; mantenere la qualità
  3. ???
  4. Successo

1

Faccio la maggior parte delle cose nel modo consueto, il primo modo che mi viene in mente. È veloce e mi piace pensare di essere un programmatore decente e al primo tentativo faccio quasi tutte le cose ragionevolmente bene.

Ogni tanto (vorrei dire due volte al giorno, ma due volte alla settimana è più realistico), soprattutto quando trovo qualcosa di estremamente noioso da fare in modo sistematico, penso "quale sarebbe un modo FANTASTICO per farlo ?" e passo il tempo extra per trovare o inventare un modo migliore per farlo.

Se continuo a farlo abbastanza spesso, il mio codice di routine continuerà a migliorare, penso.


1

Il software è roba strana e il processo di sviluppo del software è più strano.

A differenza della maggior parte delle cose nella vita reale, ma come la maggior parte delle cose da fare con i computer

Più veloce è più affidabile

Questo va contro ogni intuizione che la tua vita finora ti ha insegnato, le auto altamente sintonizzate si rompono più spesso di quelle standard, le case costruite rapidamente si sfaldano più rapidamente, i compiti a casa sul retro dello scuolabus non ottengono voti alti.

Ma le procedure metodiche lente non producono software migliore. I ragazzi che trascorrono settimane sfornando documenti sui requisiti e giorni su diagrammi di classe prima di scrivere codice non producono software migliore. Il ragazzo che ottiene i requisiti di base, chiarisce alcuni problemi, scarabocchia un diagramma di classe sulla lavagna e ottiene la codifica del suo team quasi sempre produrrà software più affidabile e migliore, e lo farà in giorni anziché mesi.


Non sono sicuro di essere d'accordo con te, ma è un punto di vista interessante e non ortodosso. +1 per pensare fuori dagli schemi.
Flot2011,

-1

Il lavoro non fa per te.

Codice di bassa qualità scritto "perché non c'è tempo, i clienti stanno aspettando, un bug dovrebbe essere risolto dall'oggi al domani, la società sta perdendo soldi su questo problema, un manager preme forte" è un sintomo di una società mal gestita.

Se vuoi essere orgoglioso del tuo lavoro e scrivere un codice di alta qualità, la cosa migliore da fare è trovare un datore di lavoro che lo capisca e ti pagherà per farlo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.