Tentazioni dannose nella programmazione

Solo curioso, che tipo di tentazioni nella programmazione si sono rivelate davvero dannose nei tuoi progetti?

Come quando senti davvero l'impulso di fare qualcosa e credi che andrà a beneficio del progetto, oppure ti inganni a credere che lo sia, e dopo una settimana ti rendi conto di non aver risolto alcun problema reale ma di crearne di nuovi o , nel migliore dei casi, ha soddisfatto la tua bestia interiore senza alcun impatto visibile.

Personalmente, trovo molto difficile non refactificare il codice errato. Lavoro con un sacco di codice legacy scadente e ci vogliono alcuni respiri profondi per non toccarlo quando non ho test per dimostrare che il mio refactoring non rompe nulla.

Un altro demone per me nell'interfaccia utente, posso letteralmente passare ore a cambiare il layout dell'interfaccia utente solo perché mi piace farlo. A volte mi dico che sto lavorando sull'usabilità, ma la verità è che adoro spostare i pulsanti.

Quali sono i tuoi demoni programmatori e come li eviti?

La generalizzazione prematura è il mio grande bugaboo; invece di risolvere il problema in prima e in attesa fino a quando c'è una reale necessità di risolvere per il caso generale, vado sempre dopo il caso generale in anticipo e vento fino a scrivere un sacco di codice che è più complesso di quello che deve essere.

Aggiornare:

Vedi " Sin # 1 - Generalizzazione prematura " per una descrizione approfondita.

"Torneremo su questo e lo ripareremo più tardi. Abbiamo solo bisogno che funzioni ora!"

La scadenza è talmente lontana, ho più che abbastanza tempo per farlo, quindi perché non passare un po 'di tempo a navigare in rete?

"Questo è solo un codice di prova del concetto da buttare via. Una volta che gli piace, lo farò davvero bene."

1. Parte del refactoring del codice qualche giorno prima del rilascio.
2. Internet: la più grande distrazione di tutte.
3. Nuova tecnologia : non riesco a togliermi le mani dalla nuova tecnologia.
4. Ottimizza: ottimizza, ottimizza. .. e altro Ottimizza
5. Perfezione : non sono mai stato soddisfatto del codice.
6. TODO: Mancanza di tempo todos che non sarà mai fatto.
7. Stima del tempo: molti PM non lo considerano "stima". Prendono in realtà.
8. Promesse: fare troppe promesse.

Caduta in preda al tentativo di costruire tutto internamente, quando ci sono quadri e librerie esistenti.

I miei demoni ricorrenti: ottimizzazione precoce e ingegnerizzazione eccessiva.

E ancora non riesco ad evitarli al 100% ...

Stime eccessivamente ottimistiche

Quando il tuo manager ti sta fissando, e senti la sensazione di bruciore di dare una stima più bassa di quella che ti sta dicendo l'intestino ... non farlo!

Dopo tutto, il tuo intestino è probabilmente già troppo basso!

Usare una tecnologia / strumento / linguaggio nel tuo progetto semplicemente perché l'hai appena imparato.

Per provare a dimostrare quanto sei bravo uno sviluppatore.

Per considerare il codice che hai scritto come tuo.

Mi prenderò solo una pausa e guarderò stackoverflow.com;)

La peggior tentazione:

Oh, beh ... immagino che un piccolo trucco / hack / correzione sporco non farà male.

Indovina, fa male. :)

Dimenticare che scrivere codice è l'ultima risorsa per risolvere un problema .

Creep

Crea un piano, seguilo e distribuiscilo. E poi torna indietro e aggiungi le cose che la gente chiede.

L'ho visto ancora e ancora. Ti siedi, elabori il progetto e inizi a scrivere codice. Gli utenti sentono alcune sciocchezze confuse sul fatto che la loro funzione preferita sia "mancante" e iniziano a fare pressioni per questo. Il tuo capo ti chiede di aggiungerlo all'undicesima ora, commette fallo sullo schieramento, introduce bug ovunque e 3 mesi dopo, una volta sistemati tutti, ti viene chiesto di rimuoverlo, perché nessuno può capire perché lo metti quella schifosa caratteristica retrò in primo luogo! Non potresti dire che il resto del design lo ha reso inutile?

1. Aggiungi altre funzionalità

2. La competizione ha questa caratteristica. Quindi questa è una caratteristica indispensabile, quindi più programmazione che analisi di strategia, posizionamento, ecc.

3. La competizione NON ha questa funzione. Quindi questa è una caratteristica differenziante quindi più programmazione che analizzare strategia, posizionamento, ecc.

4. Risolvere un problema aziendale con più programmazione. ad esempio, una migliore esperienza nell'amministrazione del server linux su cui è ospitato il tuo sito web non può essere acquisita attraverso la programmazione di più funzionalità. A volte devi solo imparare a risolvere il problema piuttosto che ricodificare tutto in C # .Net

5. Risolvere un problema di marketing con più programmazione. ad esempio, abusando del concetto di mucca viola di Seth Godin che stai risolvendo indirettamente un problema di marketing programmando più funzioni nel tuo prodotto per renderlo una "mucca viola". A volte, è solo un mostro mutante.

6. Risolvere un problema di produttività con più programmazione sostenendo a te stesso che il tempo impiegato per scrivere questo script verrà salvato in poche ore in futuro invece di programmare cose veramente importanti

7. Pianificazione del codice ma non ancora del codice perché si desidera "farlo correttamente"

8. Codificare una versione sporca e promettere che lo "migliorerai in seguito" ma non tornerai mai più a "migliorarlo"

9. Non fare un mockup o una sitemap perché è "così problematico". Posso solo fare lo screenshot delle pagine dei concorrenti per i modelli e la sitemap per disegnare a mano libera "dopo" che non lo è mai. E poi vai direttamente alla programmazione della prima pagina che visualizzo nella mia mente.

Confessione: ho commesso personalmente errori 1, 3, 7, 8. Ho anche commesso 2, 4, 5, 6 ma spesso mi sono illuso di non averlo fatto.

Attualmente sto rimediando 9.

EDIT Non ho capito che la domanda ci impone di mettere soluzioni.

1) Aggiungi altre funzionalità Solo non farlo. Collabora con la tua azienda, il marketing, i fondatori, i consulenti, ecc. E spoglia la tua applicazione in una sola cosa.

Vai a leggere su Twitter, Groupon , ecc. Su come riducono le cose a una sola cosa che ha portato al loro successo.

Se pensi che funzioni solo se vuoi costruire grandi aziende, ripensaci. Ctrl + F per questa riga "Più funzionalità aggiungo al software, peggio vende. (Questo è, inutile dirlo, altamente non intuitivo per la maggior parte degli sviluppatori di software.)" In questo link

2) La competizione ha questa caratteristica. Quindi questa è una caratteristica indispensabile

Vedi soluzione 1

3) La competizione NON ha questa funzione. Quindi questa è una caratteristica differenziante

Vedi soluzione 1

4) Risolvere un problema aziendale con più programmazione.

Se hai bisogno di assumere qualcuno per insegnarti, dare una consulenza o farlo per te e poi documentare come lo ha fatto, in modo che tu possa farlo da solo la prossima volta. FALLO E BASTA!! Non riscrivere il codice, non passare GO, non raccogliere $ 200.

5) Risolvere un problema di marketing con più programmazione.

Se le persone non capiscono cosa stai vendendo, è un problema di marketing. Torna alla soluzione 1 e fai perno.

6) Risolvere un problema di produttività con più programmazione

Aspettare.

Aspetta di sentire che la tua produttività ha sofferto di un particolare problema di produttività per un periodo superiore a 2 settimane e che ragionevolmente accadrà per altre 2 settimane.

Ora, valuta la quantità di tempo impiegata per programmare uno script per risolvere questo problema. Ricorda di prendere la tua stima peggiore e moltiplicare per 2.

Moltiplica il tuo preventivo per la tariffa oraria.

Ora rivedi le soluzioni alternative: esternalizzare, acquistare una soluzione pronta all'uso, non fare nulla al riguardo, ecc

Scegli la soluzione più economica.

Attenersi ad essa.

7) Pianificazione del codice ma non ancora del codice perché si desidera "farlo correttamente"

Fai esercizio. Sentirai una scarica di endorfine che motiveranno il tuo culo e ti faranno pianificare di agire. Lo so perché ho appena fatto panchine 5x5 e squat 5x5.

8) Codificare una versione sporca e promettere che "migliorerai in seguito" ma non tornerai mai più a "migliorarlo"

Imposta un file system tickler in GTD. e follow-up aggressivo. Segui tutte le promesse a te stesso e agli altri.

9) Non fare un mockup o una sitemap perché è "così problematico".

Vai a spendere $ 75 su un'edizione desktop di malsup di balsamiq. Lo so perché l'ho comprato 3 settimane fa. Mi ha fatto rifare i miei modelli perché mi sento un artista, un architetto e un visionario tutto in 1, anche se i miei disegni nel mondo reale fanno schifo. Il carattere usato in balsamiq ti ricorda inconsapevolmente che questo è solo un modello, non incastonato nella pietra che ti aiuta in RAD.

Fine EDIT

Un paio di birre mi aiuteranno a lavorare meglio e più a lungo.

"Sì, posso riformattare questo gigantesco pasticcio di 2000 linee di spaghetti in un giorno ..."

"Posso cavarmela senza un test per quello. È troppo difficile testarlo."

ed è il fratello cattivo,

"Devo fare un test per questo, non importa quanto sia difficile scrivere o capire."

Procrastinazione e stima ottimistica dei compiti sono i miei peccati più grandi.

Stretching, push-up o pull-up (o qualsiasi altro esercizio fisico) per il primo e umore pessimistico prima di dare una stima per il secondo.

"È molto più " semplice " reimplementare la funzionalità da zero piuttosto che comprendere il codice esistente."

Una tentazione enormemente dannosa di cui ha sofferto il progetto in cui mi trovo è l '"effetto piattaforma interna". Questo è un approccio che gli architetti, ormai lontani da tempo, hanno messo nella loro infinita saggezza, che ha creato un progetto che genera circa 20 milioni di dollari all'anno ma costa 60 milioni da aggiornare e mantenere (cifre approssimative ovviamente ma questa è la grandezza del problema).

NIH - Non inventato qui

Ho davvero delle difficoltà a dare a soluzioni di terze parti una buona opportunità. Tutti dovrebbero essere naturalmente scettici sulle soluzioni di terze parti che non sono state create su misura per loro, ma ho difficoltà a essere al 100% obiettivo.

Il risparmio di tempo può essere così grande che anche se 9 volte su 10 la soluzione di terze parti dovrebbe essere evitata, devo essere abbastanza obiettivo da realizzare quella che funzionerà.

Progettazione, codifica e / o test unitari sulla base di "dati campione" forniti invece di analizzare una copia del database effettivo dei clienti. La scadenza era breve e continuavano a dire che stava arrivando, ma non è mai successo. Quando è stato schierato, l'esplosione è stata spettacolare. Davvero, chi si sarebbe aspettato che un cliente avesse 3 clienti principali.

Non avvierò mai più un progetto fino a quando non avrò una copia dei dati reali .

Il C'è devo essere una libreria che fa che da qualche sindrome.

strettamente legato a

Il plug-in feticcio

Il perfezionismo uccide; probabilmente il motivo principale per cui i progetti non hanno successo.

Bene, a volte la programmazione mi porta alla bottiglia.

Riscrivere invece di refactoring.

Pensare che ci debba essere un modo migliore per farlo. Non mi accontenterò di qualcosa che potrebbe essere "abbastanza buono". Non prendo niente di meno che la perfezione! Di solito questo viene evitato parlando con altri che potrebbero avere una prospettiva diversa su un problema o vedere una soluzione da una diversa angolazione.

Automatizzare tutto al punto da dedicare più tempo alla manutenzione degli strumenti che al lavoro effettivo.

Soluzione: proprio come con l'ottimizzazione del codice, trova prima i colli di bottiglia della produttività e solo dopo che sono stati scoperti, risolverli con una buona automazione .

Quali sono i tuoi demoni programmatori?

A parte ciò che alcuni altri hanno menzionato.

Priorità : ignorare il lavoro prioritario rispetto al progetto e lavorare prima su altre cose nel progetto perché sono più interessanti!

Come li eviti?

Con un po 'più di autodisciplina. Seriamente, autodisciplina e automotivazione per fare la cosa giusta aiutano ad evitare la maggior parte di questi "demoni".

Non abbiamo ancora ottenuto l'approvazione da parte del cliente, ma la scadenza si avvicina, quindi ecco alcuni suggerimenti preliminari in modo che tu possa iniziare ...

Più tardi, dopo aver finito di costruire il progetto per abbinare i comp ...

Oh, ecco le revisioni del cliente, vogliono solo cambiare alcune cose minori *

(* la funzionalità principale è completamente diversa)

Quindi continui a refactoring del codice originale, basato sul modello originale difettoso invece di ricominciare da zero perché sei sotto la pressione di una scadenza breve e presumi che quelle siano state le ultime revisioni.

Sono sempre morso da questo. È difficile evitare come sviluppatore web. Il mio miglior consiglio è di spingere per più tempo in modo da poter apportare le modifiche nel modo corretto.