it-swarm.it

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 nulla problemi reali ma invece ne ha creati 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?

97
Dan

La generalizzazione prematura è il mio grande bugaboo; invece di risolvere prima il problema prima e aspettare fino a quando non c'è una reale necessità di risolvere il caso generale, vado sempre dopo il caso generale e finisci per scrivere una tonnellata di codice che è più complesso di quanto debba essere.

Aggiornare:

Vedere " Sin # 1 - Generalization prematuro " per una descrizione approfondita.

67
John Bode

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

197
user18041

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

105
user281377

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

103
davidhaskins
  1. Refactoring parte 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 verrà mai fatto.
  7. Stima del tempo: Molti PM non lo considerano "stima". Prendono di fatto.
  8. Promesse: Dare troppe promesse.
74
Amir Rezaei

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

I miei demoni ricorrenti: ottimizzazione prematura e ingegnerizzazione eccessiva.

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

48
Tomas Narros

Stime eccessivamente ottimistiche

Quando il tuo manager ti sta fissando, e senti il ​​bruciore di dare una stima più bassa di quella che ti dice il tuo intestino ... non farlo !

Dopotutto, il tuo intestino è probabilmente già troppo basso!

46
Nicole

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

Per provare a dimostrare quanto sei bravo uno sviluppatore.

Per considerare il codice che hai scritto come tuo.

33
biziclop

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

32
Richard Miskin

La peggior tentazione:

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

Indovina, fa male. :)

goto

31
Goran Jovic
25
Dan

Creep

Crea un piano, seguilo e distribuiscilo. E quindi 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?

23
Satanicpuppy
  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 che il tempo impiegato per scrivere questo script verrà salvato tra ore in futuro invece di programmare effettivamente cose davvero 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 "più tardi" che non è 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 più funzioni Basta non farlo. Collabora con la tua azienda, il marketing, i fondatori, i consulenti, ecc. E spoglia la tua applicazione in una sola cosa.

Leggi 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, IS è 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 esso.

7) Pianificazione per codificare ma non ancora codificare perché si desidera "farlo correttamente"

Fai esercizio. Sentirai un'ondata 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 lo "migliorerai più tardi" 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 font usato in balsamiq ti ricorda inconsapevolmente che questo è solo un modello, non incastonato nella pietra che ti aiuta in RAD.

Fine EDIT

20
Kim Stacks

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

17
Adam Crossland

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

16
Hila

"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."

16
Wayne Conrad

Procrastination e stima ottimistica dell'attività sono i miei peccati maggiori.

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.

15
Nikita Barsukov

"È molto ' più facile ' reimplementare la funzionalità da zero piuttosto che capire il codice esistente."

13
k3b

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).

10
AlexC

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.

I risparmi di tempo possono essere così enormi che anche se 9 volte su 10 la soluzione di terze parti dovesse essere evitata, devo essere abbastanza obiettivo da realizzare quello che funzionerà.

10
Nicole

La sindrome deve esserci una libreria che lo fa da qualche parte sindrome.

strettamente legato a

The Plugin Fetish

9
Newtopian

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.

9
dwidel

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

8
Naftuli Kay

Riscrivere invece di refactoring.

7
Dave O.

Bene, a volte la programmazione mi porta alla bottiglia.

7
mipadi

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.

6
JB King

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

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

5
Dan

Quali sono i tuoi demoni programmatori?

A parte ciò che alcuni altri hanno menzionato.

Prioritization: Ignorando il lavoro prioritario rispetto al progetto e lavorando 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".

4
Mahesh Velaga

Il mio cervello è sfinito da questo progetto. Mi limiterò a fare una breve pausa su questo progetto secondario per ringiovanirlo.

3
emragins

"There must be a better solution to this."

E finisci per pensare e pensare e lasciare che la tua mente vada alla deriva in una terra lontana fino a quando non ti rendi conto che sei andato via per troppo tempo. Dovrebbe andare bene, ma non quando hai una scadenza.

3
gladysbixly

Non abbiamo ancora ottenuto l'approvazione da parte del cliente, ma la scadenza si sta avvicinando, quindi ecco alcuni suggerimenti preliminari in modo da poter iniziare ...

Più tardi, dopo aver completato la costruzione del 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.

3
travis

Scrittura di nuovo codice dopo la data di blocco del codice.

La data di blocco del codice deve essere impostata su pietra. Qualsiasi nuovo codice scritto dopo deve essere spostato nella versione futura, poiché potrebbe richiedere tutti i tipi di test di regressione.

3
Mag20

Per rispondere alla domanda su come evitarli: familiarizza con Anti-Patterns in modo da poterli chiamare quando li riconosci.

3
Lee Kowalkowski

Cleverness. Certo, non sempre. Un po 'di intelligenza e concisione renderanno il tuo codice molto bello e mantenibile. Ma solo perché puoi farlo

x=foo?true:bar?biz,FooBar(true)?!foo:baz,FooBar(false):baz;

invece di un paio di righe di istruzioni if, non significa che dovresti.

A proposito, sì, so che c'è un po 'di ridondanza nel mio esempio ... Se l'hai anche preso da solo :)

3
Earlz

Tutti gli altri, oltre alla funzione "brividi": "Sarebbe davvero bello se lo facesse, e so che il cliente lo adorerà e lo avrebbe inserito nelle specifiche se ci avessero pensato". Cerco di evitare questo chiedendo dove nelle specifiche reali esiste il requisito per questa funzionalità davvero interessante.

Inoltre, spesso non ricevo specifiche scritte.

2
PSU

"è solo il pilota, quindi non è necessario semplificare la manutenzione o l'espansione".

Nella mia esperienza è più comune vedere il pilota entrare in produzione e il prodotto dovrebbe essere un pilota da demolire rispetto al pilota da rottamare e il prodotto reale sviluppato allo stato pronto per la produzione.

2
jwenting

Trascorrere troppo tempo a modificare l'editor. Prova di trovare la migliore combinazione di caratteri e colori per la programmazione.

2
dheerosaur

"Mi è stata assegnata una funzione che si interfaccia con [software/ad esempio: sharepoint]. Probabilmente dovrei sapere tutto quello che c'è da sapere su quel software."

Quindi trascorri settimane alla ricerca di quel prodotto, quando la funzionalità avrebbe potuto essere scritta e testata in un giorno o due. La fame di conoscenza ha un ventre oscuro. rawr

2
Steven Evers

"Commenterò/documenterò più tardi"

non succede mai, l'autore va avanti e poi scopri che non commentano il loro codice quando il lavoro ti è stato assegnato.

2
sunwukung

Iniziare ad attaccare un nuovo progetto, senza capirlo, e di solito lo evito ricercando un po 'il dominio del progetto prima di iniziare a lavorare con esso, solo per avere un buon punto di partenza e per dimostrare che il progetto è più complesso di Inizialmente ci sono passato.

Ho anche il problema che mi piace spostarmi con i pulsanti, sono fantastici !! Ma forse è perché sto facendo sistemi multimediali e progettazione dell'interfaccia utente ... Quindi per me la soluzione a questo problema è stata quella di includerlo nel mio curriculum e studiare qualcosa al riguardo, in modo da avere una scusa valida se qualcuno vede io gioco molto con l'interfaccia utente. (E questo include mettere lo sfondo verde, il testo arancione e le icone con molto giallo.)

1
Coyote21

Elenco molto completo: anti-pattern .

1
vartec
/**
* Calculates the return value for humptyDumpty
*
* return int modifiedHumptyDumpty
*/
function awesomeWayToCalculateSomething(int humptyDumpty) {
.. 
}

TODO: Devo documentarlo correttamente.

Will _never_ succede

1

Usare una funzione del linguaggio, un linguaggio o un modello di progettazione non perché è la migliore soluzione al problema, ma puramente per il gusto di usarlo.

1
Dima

Penso di aver in mente che gli enum sono molto più utili di quanto non siano in Java. Tendo a provare a fare troppo con loro e poi mi impantano perché non supportano davvero il polimorfismo.

1
MattLBeck

impegnandosi a evitare lo sviluppo interno, il 90% di una ruota non è meglio che inventarne una.

1

Usare un framework senza capirlo appieno. Ma poi di nuovo. un framework è pienamente compreso solo dai suoi creatori (la maggior parte dei casi). Non ho una vera soluzione per quell'elemento, ma sto cercando di capire il più possibile da un framework.

1
user18483

Risolvere un bug che ti ha disturbato perché è "così semplice", ma non lo dice mai al controllo qualità e/o al cliente.

Queste correzioni bloccano sempre la produzione.

1
Scott McIntyre

Qualcuno ha detto generalizzazione prematura, ma specializzazione prematura può essere altrettanto negativo. Con la generalizzazione prematura, è possibile ottenere un software che funziona per il 50% dei casi, ma la specializzazione prematura può funzionare per il 5% o nessuno. Alla fine, il management avrebbe preferito il 50% rispetto al 5%.

1
MPelletier

Fare innumerevoli ore di lavoro extra per l'azienda nel mio tempo libero solo per scoprire "che non era la direzione che stavano cercando".

1
user13280

Quali sono i tuoi demoni programmatori,

Tutto ciò che è già stato menzionato, in particolare la voglia di refactoring come un matto.

e come li eviti?

Prima di iniziare qualsiasi modifica non banale, mi tolgo le mani dalla tastiera per 5 secondi e soppeso rapidamente i possibili risultati del cambiamento piuttosto che lasciarlo. Quindi di nuovo prima di impegnarsi, soppesare le stesse conseguenze per circa un minuto.

1
Cheezmeister

Per trovare un comodo divano per lavorare o lavorare a letto.

1
kiewic

Essere "perfetto"

Anche se evitare di farlo bene la prima volta è un problema, non è poi così grave come una continua attenzione alla perfezione. Basta farlo, non esiste una cosa come perfetta, e se c'è, è puramente temporale o già fatto e non vale la pena ripeterlo.

0
blunders