Qual è il mito più assurdo sui problemi di programmazione?


101

Per dirla in altro modo ... Qual è il malinteso più frustrante e ritenuto più comune sulla programmazione, che hai riscontrato?

Quali miti / idee sbagliate diffusi e di lunga data trovi difficile da dissipare / correggere per i programmatori .

Per favore, spiega perché questo è un mito.


24
Mi piacerebbe vedere Mythbusters affrontare alcuni di questi.
spong

8
Qualcuno ha intenzione per un canale YouTube di Mythbuggers? :-)
Tamara Wijsman,

1
Ooooh, MythBusters e condizioni di gara! Meesa piace!

@TomWij sarebbe bello avere un sito web con un nome simile!
Junior M

Risposte:


272

Questo perché sei un programmatore, sai come riparare la macchina infestata dai virus di [persona].


34
Analogia auto / clausola di uscita: "Sono un pilota non un meccanico".
Peter Boughton,

15
Questo fumetto è rilevante: theoatmeal.com/comics/computers
lunixbochs


21
@Tim se riesce a cucinare, inizia a offrirla come volontaria per soddisfare le feste dei tuoi amici
Steven A. Lowe,

19
Non è che non so come ... Che non voglio perdere ore a riparare la macchina che si romperà comunque in 2 settimane.
ChaosPandion,

267

Una cosa comune delle risorse umane che mi fa impazzire quando sono alla ricerca di lavoro: l'assunto implicito che tutte le competenze di codifica sono specifiche della lingua, che non esiste alcuna competenza di ingegneria del software che trascenda i set di comandi. Quell'esperienza decennale in Java e altri cinque in Perl significano che saresti completamente inutile in un progetto che usa, diciamo, C #.

"Sì, c'è una curva di apprendimento. Ma ho fatto transizioni più difficili di così. Ti farò un accordo, pagherò l'80% per il primo mese e alla fine di quel periodo se non lo sono ... oh , aspetta, in realtà non stiamo avendo questa conversazione, perché la tua scimmia delle risorse umane ha semplicemente eliminato la mia applicazione. "


91
+ INF per scimmia HR.
Rusty

67
Ho avuto un ragazzo delle risorse umane che mi rifiutava un ruolo perché sapevo come C #, ma stava cercando qualcuno che potesse codificare in dotNet.
burnt_hand,

11
@burnt_hand: Sì, conosco dotNet. Conosco anche Excel e Internet Explorer. Posso contrattare adesso?
Alan Plum,

Mentre sono d'accordo che ci sono enormi sovrapposizioni con sintassi, struttura, SDLC, ecc., Tra Java e C #, se durante l'intervista ti danno qualche test C # ragionevolmente complicato, come farai?
JBR Wilkinson,

2
@Kyralessa - Penso che ora conosco abbastanza bene la teoria di base dell'informatica e delle funzioni dei computer per non commettere errori di base in nessun linguaggio di programmazione. Posso leggere la documentazione. Tuttavia, qualcosa che un determinato linguaggio assume con capacità / volontà / attività ingegneristiche limitate è commettere errori di base nella struttura, nella progettazione, nella correttezza, nella scalabilità, nell'affidabilità e nella manutenibilità del programma che costeranno potenzialmente grandi quantità da correggere. Se non perdi tutti i tuoi clienti a causa della bassa qualità del software nel frattempo (supponendo che il tuo progetto arrivi effettivamente ovunque).
flamingpenguin,

261

Se non stai scrivendo, non stai lavorando.

Credo che gli sguardi zombi in bianco e le passeggiate nel caffè siano essenziali per i programmatori che organizzano le cose nella loro testa.


9
Pagina su, pagina giù ... pagina su, pagina giù ...
adolf garlic

139
Non sono pagato per scrivere, sono pagato per pensare. Fornisco la digitazione come bonus.
Kevin Laity,


11
Questo è il motivo per cui non penso molto ai mercati freelance online che offrono la registrazione di "orario di lavoro" con uno screengrabber e una webcam. WTF? Se ritieni che la mia citazione sia buona, perché ti importa cosa è esattamente quello che faccio nel momento in cui sto caricando?
Alan Plum,

10
"Se avessi più tempo per scrivere codice, scriverei meno righe." - decollare sulla citazione di Abe Lincoln.
JeffO,

158

che puoi accelerare un progetto in ritardo, semplicemente lanciando più persone su di esso.


28
Ah, da The Mythical Man Month. it.wikipedia.org/wiki/The_Mythical_Man-Month
spong

2
Veramente, puoi. -1 (sì, ecco un portatore di miti!)
P Shved,

63
Usiamo un detto colorato "Non puoi mettere 9 donne in una stanza e fare un bambino in un mese".
Walter,

10
La scorsa settimana abbiamo aggiunto 4 persone senza esperienza di progetto per "aiutare" a rispettare un programma non realistico. Il rapporto di questa settimana del progetto porta a elenchi di dirigenti: "Pianificazione dello slittamento Causa: riduzione dell'efficienza dovuta alla curva di apprendimento dei nuovi membri del team" e "Piano di recupero: continuare ad aggiungere più persone laddove esiste l'opportunità". Incredibile.
AShelly,

7
@Walter, ma puoi avere 9 bambini in 9 mesi e una squadra di baseball della Little League in 7 anni.
Huperniketes,

132

Quel software di scrittura è facile.

In che altro modo spieghi tutti questi progetti che durano nel tempo e oltre il budget e le persone (politici, media ecc.) Sono ancora sorpresi, e i clienti si lamentano quando dici loro che il loro "piccolo sito Web" (o qualunque cosa) prenderà effettivamente 6 mesi per sviluppare e costare diverse migliaia di dollari (sterline, euro, [inserire la valuta di scelta])

Con requisiti sfocati e in continua evoluzione, a volte penso che sia sorprendente che qualsiasi software venga mai completato!

So che è un po 'più complicato di così;)


11
E questo è quando tentano di portare lo sviluppo a alternative offshore più economiche. Solo per scoprire molto più tardi che si è rivelato ancora più costoso. E meno di ciò di cui avevano veramente bisogno, a causa delle sfide fisiche di separazione e comunicazione tra il team di sviluppo e il cliente.
7

1
Questo non è solo un problema tra i manager, ma anche i programmatori stessi. Il vero problema tende a essere quel tempo che non viene speso attivamente per scrivere il codice viene spesso perso (probabilmente a causa del diffuso mito di quantificazione della produttività LOC =).
Alan Plum,

3
Non è che i requisiti siano cambiati, non è proprio quello che pensavano di voler.
JeffO,

1
Qualcuno ha respinto la programmazione come "solo un mucchio di dichiarazioni 'if'. OK, forse lo è ... in quel caso, la poesia è "solo un mucchio di parole" ... la produzione del film è "solo un mucchio di scene", ecc.
JoelFan,

2
Ho lavorato per il tipo di manager che pensava che il bit di programmazione fosse la parte facile del lavoro. E no, non ha avuto alcuna esperienza di programmazione lui stesso.
Captain Sensible,

114

La complessità dell'app è direttamente proporzionale alla complessità dell'interfaccia utente. Con questo ragionamento, dovresti essere in grado di costruire Google o Twitter per un fine settimana.


2
questo è vero, potrei costruire Twitter e Google in un solo fine settimana. Non è il loro software che è complesso; per Google, è il loro algoritmo di ricerca (che è più paragonabile a una libreria di codici o driver di database) e Twitter (fino agli ultimi 1,5 anni) era straordinariamente semplice, con solo problemi di scalabilità e database complessi. Ora che è più complesso (richiede più dipendenti), ha anche un'interfaccia utente molto più complessa e molte più interfacce utente.
Orokusaki,

3
Penso di averlo letto sul blog di Joel Spolsky, ma l'articolo menzionato mostra solo come progressi della GUI in relazione ai progressi del back-end. In questo modo puoi dare una stima realistica dei progressi ai ragazzi con i capelli a punta che sono troppo stupidi per capire che la maggior parte dei programmi è costituita da molto più di un piacere per gli occhi.
Evan Plaice,

3
1+ C'è stato un tempo in cui ho provato un progetto relativo a SharePoint (un componente aggiuntivo multilingue) al mio ex capo, dopo aver trascorso ore a lavorare sul complesso codice di backend. Il risultato finale non è stato fatto molto sull'interfaccia utente, il che ha portato il mio capo a credere che sul progetto non sia stato fatto molto. Mi ha fatto incazzare. Non era quello seduto alla tastiera per ore a cercare di aggirare le stranezze di SharePoint, così come la logica di sostituzione del testo.
Jason Evans,

1
Non odiare quando una richiesta enorme, quasi impossibile, è formulata come "puoi aggiungere un pulsante per fare ..."
JoelFan,

Mi chiedo cosa ho fatto negli ultimi anni. Tutti quei progetti a cui ho lavorato a tempo pieno avrebbero dovuto essere completati in pochissimo tempo, perché non avevano alcuna interfaccia utente. :-)
Bart van Ingen Schenau,

95

Tutti i programmatori sono bravi in ​​matematica. :-)


Commentatori: i commenti hanno lo scopo di cercare chiarimenti, non di discussione estesa. Se hai una soluzione, lascia una risposta. Se la tua soluzione è già stata pubblicata, ti preghiamo di votarla. Se desideri discutere questa domanda con altri, utilizza la chat . Vedi le FAQ per maggiori informazioni.

Penso che le capacità matematiche siano in qualche modo legate alle capacità di programmazione.
Diego,

@Diego: anche se ciò non significa necessariamente che tutti i programmatori siano comunque bravi in ​​matematica.
Omega,

95

Ogni ragazzino adolescente che fa hacking con il computer è equivalente (o superiore) in abilità a un programmatore di lavoro veterano.

Mio nipote di 14 anni è bravo con i computer e gli sto pagando $ 10 / ora per falciare il prato. Perché dovrei pagarti sei cifre per scrivere il prossimo FaceBook?


5
Probabilmente si trovano nel loro ambiente, cioè lavorano da soli secondo i propri standard. Mettili in una squadra in cui devono comunicare ed è lì che soffrono.
Adolf Aglio,

36
La contro domanda potrebbe essere: "Cosa gli pagheresti per costruire la tua casa?"

7
Un bambino senza qualifiche, ma scrive un codice accurato, può battere Mr. Spaghetti ogni giorno.
Zaz,

13
Per colpa di Hollywood
MAK,

6
Quando ho iniziato, mi aspettavo che ciò che avevo insegnato e raccolto all'università fosse solo l'inizio, e avrei lavorato con persone più esperte che erano programmatori migliori e sviluppatori più informati, e avrei imparato molto da loro. L'esperienza mi ha insegnato diversamente. È assolutamente importante, ma senza abilità e passione, l'esperienza è solo tempo perso.
Peter Boughton,

69

Quel tempo reale significa veloce.

Dichiarando "I pacchetti devono essere elaborati in tempo reale." è inutile e il gemello malvagio ... risponde "Quanto velocemente deve accadere X?" con "Real-time" è forse meno che inutile ... al confine con stupidi piuttosto che ignoranti.

In tempo reale significa che, in poche parole, quella funzione Y richiederà sempre X quantità di tempo e che qualsiasi deviazione indica un errore grave. La durata di X non definisce "in tempo reale", potrebbe essere di sei microsecondi o sei giorni. Che tu possa determinare la funzione Y impiegherà il tempo X definisce "in tempo reale". I sistemi in tempo reale sono deterministici secondo questa definizione.

Quindi smettila ..


real-time = near-time
brian chandley,

4
Ho sempre pensato che il tempo reale significasse che qualsiasi cosa stesse accadendo stava accadendo quando lo richiedevi, non un riferimento al tempo impiegato.
burnt_hand,

14
Questo è probabilmente solo uno di quei casi in cui un concetto mal chiamato contribuisce alla confusione.
JohnFx,

2
@JohnFx Ben messo. I concetti hanno bisogno del contesto.
Rusty

2
@Richard: In effetti, iTunes impiega sempre qualche minuto prima di riprodurre qualsiasi cosa. Oh, non è quello che volevi dire?
configuratore

69

Perché non lo scrivete semplicemente la prima volta, piuttosto che passare così tanto tempo a digitare il codice errato e poi a leggere il codice cercando di trovare i bug?

:-) :-) :-) :-)


34
Francamente, questa è una buona domanda. Il momento più semplice per rendere buono il codice è quando viene scritto per la prima volta.
DJClayworth,

10
Abbiamo un'impostazione nella configurazione dell'app: <add Key = "Bugs" Value = "true" />
burnt_hand

1
@DJClayworth - non sempre funziona. In alcuni casi, il problema è così grande, mal definito o semplicemente difficile che avvicinarsi alla "giusta" la prima volta è troppo aspettarsi. In tal caso, è meglio scrivere un "primo taglio" che non sia del tutto sbagliato, piuttosto che passare giorni / settimane / mesi a progettare e riprogettare all'infinito nel tentativo di farlo bene la prima volta.
Stephen C

Questa potrebbe essere la versione del laico di "Perché non state facendo TDD?" Che, per essere onesti, è una bella domanda, se troppo semplice per lo sviluppo del mondo reale.
Dan Ray,

1
@Stephen C: sì, ma c'è una differenza nel farlo per lo più giusto (invece che perfettamente giusto) vs fare per lo più tutto ciò che è giusto e sinistro solo per farlo funzionare. So che non è quello che hai detto, ma penso ancora che debba essere detto.
n1ckp,

65

Se non sei mai andato all'università, non sei adatto per il lavoro


27
Inoltre: un programmatore con una laurea è meglio di un programmatore senza e dovrebbe essere pagato di conseguenza. Lo stesso probabilmente vale per l'età e il sessismo. Questo tipo di assurdità mi fa infuriare: se non sai come scrivere un buon codice, non me ne può fregare di meno di dove sei andato e cosa hai fatto. Questo potrebbe essere un altro caso di cultura programmatore / secchione (abilità == autorità) in conflitto con la cultura aziendale (grado == autorità).
Alan Plum,

1
Eppure le persone che insegnano all'Università sembrano anche pensare di poter generalizzare il comportamento dei programmatori e dei progetti osservando come gli studenti operano quando sono uniti. Le comunicazioni dell'ACM sono valide per 4-6 articoli del genere all'anno.
MIA

1
@Billy Che ne dici di qui, dove un diploma universitario significa jack, ma un diploma universitario ti garantirà tutto? Entrambi vanno a scuola, entrambi sono probabilmente migliori dell'altro, ma c'è una differenza sociologica
Tarka,

4
@Billy: in Canada, l'università ti conferisce una laurea e le università ti danno diplomi. I college sono più simili a "scuole dove apprendi cose pratiche". Pensa al college della comunità negli Stati Uniti rispetto al normale college / università. Qui in genere hanno programmi applicativi specializzati di due anni. Non puoi ottenere una laurea (master, ecc.) Da un college. Fondamentalmente, andresti al college per studiare come scrivere software e all'università per studiare informatica. Ai titoli universitari viene data una preferenza molto più forte nelle assunzioni.
Adam Lear

4
Le università insegnano almeno una cosa importante: la mentalità . Questo è molto importante, ma quelli che non lo sanno ... beh, non lo sanno.

61

Quell'ottimizzazione prematura significa che non dovresti ottimizzare affatto. Ho visto database più orribilmente cattivi perché nessuno voleva considerare le prestazioni (fondamentali per qualsiasi sistema di database) nella progettazione in quanto si trattava di un'ottimizzazione prematura di qualsiasi altro problema di progettazione del database. Spazzatura, ci sono noti assassini delle prestazioni, smetti di usarli come prima scelta.

Un altro mito, è troppo difficile riformattare il database. No, ma devi considerare come eseguire il refactoring in fase di progettazione per farlo in modo efficace. E a proposito, più tempo aspetti per risolvere quel fastidioso problema di prestazioni basato sul design, più difficile sarà risolvere.

Un altro mito negativo, la progettazione di database dovrebbe riflettere i principi OOP. No, i database sono progettati per funzionare con set non con principi OOP. Alcune cose OOP causeranno orribili problemi di prestazioni e altre sono solo sciocche in termini di database.

Infine, è necessario applicare l'integrità dei dati nell'applicazione. I database dureranno oltre l'applicazione e perderebbero le regole quando l'applicazione viene sostituita, le applicazioni multiple accederanno a loro e spesso ci sarà la necessità di eseguire query dirette per riparare cose che non passano attraverso l'applicazione. Non ho mai visto un database che si rifiuta di imporre l'integrità dei dati nella base di dati che ha buoni dati.


+1 in particolare per i commenti sui controlli di integrità del database.
Frank Shearar,

+1 Soprattutto per l'ultimo paragrafo. Ho battuto quel tamburo più di una volta.
Binary Worrier,

5
+1 per il primo paragrafo. L'ottimizzazione prematura è la radice di tutti i mali; scrivere codice errato per nessun motivo insanguinato è anche peggio.
configuratore

3
"Alcune cose OOP causeranno orribili problemi di prestazioni e altre sono solo sciocchezze in termini di database" - potresti dire quale? Conosco OOP, ma non molto sui database e sono interessato a quanto lontano posso portare idee da una parte all'altra.
Tom Anderson,

@HLGEM Sarei anche interessato agli esempi che @Tom si sta chiedendo ...
Armand,

53

Che esiste una fonte mitica di migliori pratiche assolute.

Nessuna deviazione può mai essere giustificata.

Nessun documento che afferma di definire qualcosa come una buona pratica può mai essere messo in discussione.


1
meglio un membro del team che i tuoi manager ...
Bill

5
Puoi inviarmi quel documento?
AShelly,

1
Completamente d'accordo. A chi importa se mescoli schede e spazi nel codice Python?
Zaz,

4
@Josh - qualcuno che deve visualizzare il codice sorgente usando una catena di strumenti che ha un'idea diversa di dove si trovano le posizioni della scheda.
Stephen C,

1
Interpreto "è la migliore pratica" come "non posso giustificarlo". Lo uso certamente così.
Tom Anderson,

51

Il fatto che il marketing sembra pensare che l'aggiunta di una tonnellata di piccole funzionalità sia meno lavoro rispetto all'aggiunta di una singola, ma piuttosto pesante, funzionalità. Che probabilmente è un caso più specifico dell'idea sbagliata che "il cambio di attività non ha costi generali".


12
E la cosa ancora più divertente del marketing non avere idea di quali funzioni siano facili e quali dannatamente quasi impossibili.
derobert,

4
@derobert Esatto, ho spesso avuto l'esperienza che alcune delle persone di marketing più premurose hanno in realtà paura di persino chiedere alcune funzionalità semplici / facili che pensavano fossero molto difficili da implementare. Anche se provo il contrario molto più spesso: ecco un lotto di X funzioni "facili" che abbiamo già venduto al cliente, per favore fallo entro ieri ....
Giel

50

Quel codice di commento non è necessario o quel "buon codice non ha bisogno di commenti". A volte è necessario spiegare cosa sta facendo un bit complesso di codice. Inoltre, commentare sezioni di codice ti aiuta a leggere molto più efficacemente.


14
@DisgruntledGoad - È vero però. L'incomprensione in questo "mito" deriva dal fatto che troppi programmatori considerano il loro codice monolitico confuso "buono". if user.is_logged_in: print('Welcome')non ha bisogno di un commento.
Orokusaki,

3
@orokusaki Non tutti gli algoritmi sono così semplici.
Jouke van der Maas,

25
@orokusaki stai sbagliando "il buon codice non ha bisogno di commenti" con "il semplice codice non ha bisogno di commenti". Il buon codice non è sempre semplice.
DisgruntledGoat

3
@Jouke van der Mass: ovviamente. Ma non importa quanto sia complesso l'algoritmo, l'obiettivo è quello di esprimere l'algoritmo semplicemente. vale a dire che un buon codice esprime algoritmi, regole, ottimizzazioni complesse, in modo semplice e comprensibilmente non comprensibile. Esprimere cose semplici è semplicemente relativamente semplice. Esprimere cose complesse è semplicemente dove sta l'abilità.
flamingpenguin,

2
@orokuskai: il buon codice è semplice. Le cose che sta facendo possono essere complesse, ma la semplicità (eleganza) del codice è ciò che lo rende buono secondo me! Naturalmente, il codice fa molte altre cose e il codice della spazzatura può farti guadagnare un sacco di soldi. Ma il mio obiettivo è scrivere codice semplice anche in situazioni complesse.
flamingpenguin,

50

Il mito peggiore: se stai programmando da molto tempo, puoi facilmente diventare un Project Manager.

E che dovresti diventare un project manager se stai programmando da molto tempo.


3
O peggio ancora, se non hai mai programmato o gestito un progetto di programmazione, leggere alcuni libri e magicamente far accadere il software. Sono stato su quella strada con un PM precedente e non mi interessa ripeterlo finché vivo.
Evan Plaice,

4
Ancora peggio: poiché tutti i grandi programmatori del team preferiscono scrivere codice piuttosto che scrivere report, dovremmo promuovere il programmatore mediocre a Project Manager. Il pensiero è che sarà "abbastanza tecnico". Il fatto è che finisce per essere un filtro di disinformazione tra la squadra e la direzione superiore.
AShelly,

2
Inoltre: se sei il miglior programmatore, dovresti ovviamente diventare il project manager e da quel momento in poi smetti di programmare tu stesso! No, grazie mille, ma prenderò comunque il rilancio. Nota: non sto parlando di diventare un programmatore capo o qualcosa del genere, sto parlando dei manager che pensano che sia un'idea intelligente promuovere tutti al loro livello di incompetenza sufficiente.
Alan Plum,

1
Conosciuto anche come Peter Principle. en.wikipedia.org/wiki/Peter_Principle
Spoike

ben detto davvero
Michael Easter

50

Se utilizziamo qualcosa di diverso da Java, C # e C ++ nel nostro progetto, non troveremo programmatori che lo supportino.


Non ne avevo mai sentito parlare, ma è valido. Ovviamente se usi un linguaggio oscuro, potrebbe succedere.
Maniero,

5
@bigown, "oscuro"? Quanto oscuro? La TCL è oscura? Haskell? Pascal (Delphi)? Pitone? Penso che non siano oscuri. Molte persone pensano di esserlo, e solo un insieme molto ristretto di linguaggi (C ++, C # e Java) è consentito nello sviluppo "serio".
P Shved,

5
@bigown: oh, vuoi dire oscuro come COBOL? : p
AnonJr

2
Una volta ho lavorato per una piccola azienda facendo codice Objective-C su Linux. Il CEO - che non era un ingegnere ma aveva alcune conoscenze tecniche - non poteva credere che ci fossero programmatori ObjC in giro o che chiunque altro lo usasse. In realtà non hanno mai avuto problemi ad assumere buoni sviluppatori.

4
Ho letto una tesi secondo cui è vero esattamente il contrario: per i linguaggi che sono oscuri (o almeno commercialmente insignificanti) ma interessanti, divertenti e interessanti (che in quel contesto significava Python e Ruby), ci sono più programmatori che lavori. Inoltre, sono tutte persone che parlano lingue interessanti, divertenti e interessanti, quindi devono essere intelligenti. Quindi, in realtà, lavorare in Python significa che sarà più facile assumere programmatori intelligenti che se si lavora in Java. Non so se ci credo, ma è almeno plausibile come l'idea ortodossa!
Tom Anderson,

42

Java è solo C ++ con classi diverse.


57
+1 Una volta ho avuto un intervistatore che mi chiedeva "qual è la differenza tra C ++ e Java?" Quindi ho elencato alcune differenze. Compilatore nativo vs. JVM, standard ANSI vs. proprietario, garbage collection, classloader, ecc. Ruggì: "SBAGLIATO! Non c'è differenza! Sono identici!" Non era uno studente, era il direttore tecnico.
Bill Karwin,

11
@Bill, la mia risposta sarebbe quindi, "allora perché riferirsi a loro con nomi completamente diversi?"
Jesse C. Slicer,

2
@Bill, quindi hai fallito il test e sei stato assunto?

20
La mia risposta sarebbe "Arrivederci".
Foole,

6
@Foole Non intendi System.exit (1)?
Barry Brown,


33

Probabilmente il più pericoloso che ho visto, perché viene accettato così prontamente, è che essere in grado di scrivere codice velocemente è una buona cosa, e quindi più velocemente puoi scrivere [inserire funzionalità qui] in una determinata lingua, migliore è la lingua è.

Questo è un serio esempio di ottimizzazione prematura, dal momento che molto più lavoro richiede la conservazione del codice che la sua creazione. Ciò significa che è molto più importante scrivere un codice che sia facile da leggere, comprendere e eseguire il debug del codice che sia facile da scrivere rapidamente, e facilitare il codice di facile lettura è una misura molto più utile della qualità del linguaggio.


14
questo è esattamente quello che è successo a uno dei prodotti per i quali lavoro; lo sviluppo affrettato è stato visto come brillante. Il prodotto ha VISTO ok e lo sviluppatore è stato elogiato dall'alta direzione. Un altro sviluppatore junior è stato quindi incaricato di correggere un "piccolo" bug e, dopo una settimana di tentativi di comprensione del codice, ha rinunciato e ha cercato la guida di un senior .. che non riusciva a credere a quanto fosse spazzatura il codice. La direzione superiore ha rifiutato di accettare è un grosso problema per due anni, dopo di che alla fine hanno concordato che era un mucchio di spazzatura e che doveva essere nuovamente codificato da zero - e proprio questa volta
Sk93

4
Esiste un mito consolidato tra i responsabili tecnici secondo cui i tuoi abili sviluppatori sono dieci volte più produttivi degli sviluppatori non qualificati. Il risultato diretto di questo mito è che qualsiasi sviluppatore in grado di produrre rapidamente codice , indipendentemente da quanto sia difettoso o difficile da mantenere, ottiene elogi e promozione.
rtperson,

3
Hai bisogno di un linguaggio potente. Vedi la discussione di Paul Grahams sulle lingue e su cosa ti consente di fare: paulgraham.com/power.html

4
@ Thorbjørn: ho letto quell'articolo e Paul Graham ha sbagliato. È un sostenitore di Lisp, quindi trasforma i fatti in argomenti egoistici per far sembrare buono Lisp. Forse nemmeno in modo coscienzioso, dal momento che in realtà non ci vuole molta torsione. C'è molta sovrapposizione tra leggibilità e succinta, mentre sottolinea verso la fine dell'articolo. Ma le conclusioni che trae sono completamente fuori sincrono con lo stato di sviluppo del software nel mondo reale. Sì, hai bisogno di un linguaggio potente, ma sta misurando il potere con criteri sbagliati ed è dannoso credere a ciò che dice.
Mason Wheeler,

3
@rtperson: che la produttività possa variare di un fattore dieci non è un mito. Che le persone che finiscono in fretta siano necessariamente più produttive è.
David Thornley,

31

Le lezioni di produzione possono essere applicate al processo di sviluppo del software.


6
Dipende dalle lezioni. Quando ho lavorato in una fabbrica di materassi, abbiamo appreso che il cambio di attività era dannoso per la nostra produzione. Molto importante dato che siamo stati pagati dal numero di materassi realizzati e non dall'ora ... e una lezione che si applica anche qui per gli stessi motivi.
AnonJr

Questo è un mito così persistente quando lavori in un luogo che produce principalmente hardware. I cerchi attraverso i quali passiamo per adattare la "costruzione" del nostro software allo stesso modello di una "parte" hardware sono incredibili ...
AShelly,

5
Il fatto è che la produzione di software è banale. È facile fare copie e non costa molto fare milioni di copie. Questo porta le persone a ignorare del tutto la parte di produzione e provare ad applicare la produzione al processo di progettazione.
David Thornley,

+100 per questo, specialmente le persone che hanno studiato economia pensano questo
Kugel,

1
Tutti dovrebbero leggere Jack Reeves: developerdotstar.com/mag/articles/reeves_design_main.html - questa è l'origine (o almeno un'affermazione anticipata e potente) dell'idea che il codice sorgente sia un disegno non un prodotto . I programmatori sono come i progettisti nella sala di disegno, non i macchinisti nella fabbrica, e la gestione della programmazione deve essere come la gestione di altri tipi di progettazione ingegneristica, non manifatturiera.
Tom Anderson,

31

che come programmatore sai tutto sulle ultime tendenze hardware, overclocking, case mod, ecc. amici e parenti ti consultano quando acquistano i loro ingranaggi.


5
Continuavo a tenere il passo con alcune di queste cose al liceo, ma al giorno d'oggi trovo che sono generalmente irrilevanti per quello che faccio e mentre alcuni sono in ordine, preferirei di gran lunga pagare qualcuno che conosce le loro cose e usare il tempo che salva facendo quello che mi piace (cioè scrivendo codice). Forse un altro malinteso "buono con i computer".
Alan Plum,

2
+1, o leggermente tangente - Poiché sei un programmatore, hai una ventola a 300 LED super duper raffreddata ad acqua che gira lampeggiante nella gamma nuova di zecca spedita dall'impianto di produzione prima che fosse rilasciata. Ehm non proprio! È una macchina abbastanza veloce, in una custodia nera molto economica. Non importa davvero oltre!
Surgical Coder,

Ridi, c'è un assistente PM al lavoro che ha un impianto di gioco onnipotente a casa, rotola sempre verso l'area Dev per chiedere se dovrebbe comprare (Prodotto A) o (Prodotto B) ... in una nota non correlata, lui presume anche che tutti i team di sviluppo si ritrovino su 4Chan, (cosa che attualmente fa.) - sospiro
ocodo

+1 parola. Questo è perfetto. Sono uno sviluppatore di software e mi è stato chiesto di configurare Internet di qualcuno per così tante volte e praticamente tutto ciò che faccio è tentativi ed errori più ricerche di Google. Mi piace di più quando qualcosa di completamente estraneo si rompe dopo che hai fatto un favore a qualcuno e poi è colpa tua.
Anne Schuessler,

30

Che quando i programmatori affermano che è molto difficile da fare / semplicemente impossibile, le risorse umane pensano che siano pigre e non motivate


2
Includi anche la gestione
Prasham

Quando dici di no, pensano che sei semplicemente una persona difficile con cui lavorare.
Captain Sensible,

+100 e con sufficiente "motivazione", possono cambiare la tua risposta. Oppure vai a un altro sviluppatore [meno esperto] e lascia intenzionalmente fuori la metà dei dettagli per convincerlo a dire di sì, solo per finire a metà dello sviluppo e imbattersi nell'esatto problema di cui li hai avvertiti.
wildpeaks,

28

Ci deve essere un programma open source per la mia attività. Non puoi semplicemente scaricarlo e modificare le mie esigenze.


2
+1. Oh, sì, tutto ciò che dobbiamo fare deve essere già in open source.
sharptooth,

7
molte volte c'è ... almeno questo è vero per lo sviluppo web.
WalterJ89,

@ WalterJ89: potrebbe essere lì, ma ciò non significa che sia una buona idea usarlo. Open source non significa automaticamente un buon codice.
Alan Plum,

vero .. ma nel caso di Wordpress, Drupal, jQuery, ... potrebbero esserci aree in cui il libero non è eccezionale, come l'e-commerce ma il più delle volte il web è molto aperto, e trovo che mi diverta a lavorare con un comunità open source molto più di un help desk propietorio.
WalterJ89,

7
Anche il contrario è un mito. Che non puoi usare FOSS per soddisfare le tue esigenze aziendali.
capolinea il

27

Ho avuto più di una persona che mi chiedeva cosa significhi programmare solo per realizzare a metà della conversazione che pensano davvero che programmiamo direttamente in binario o usando simboli matematici.

Non so se voglio sfatare quel mito, mi fa sembrare davvero intelligente!


6
Non aiuta che la maggior parte delle persone non sappia nemmeno cosa sia davvero la programmazione ... hanno questa vaga idea che sta creando software ... ma non hanno davvero un'idea chiara di cosa sia il software ...
Spudd86

7
"Scriviamo ricette per maglieria". Le nonne tendono a capirlo.

Conosco persone che scriveranno un programma in C, quindi rifanno le parti più critiche per le prestazioni in Assembly.
Zaz,

1
@Josh - a meno che non ci sia un problema di prestazioni, sembra una perdita di tempo.
JohnFx,

1
@oosterwal - Assembly non è binario, né usa simboli matematici.
JohnFx,

26

Penso che il più grande malinteso sia che è più importante essere in grado di scrivere il codice facilmente che essere in grado di leggere e comprendere il codice.


5
* v (int) (vuoto) ++
Rusty

1
@Rusty: posso trovare esempi molto, molto peggiori se non devo nemmeno essere sintatticamente corretto.

4
Ahh, sì, "Scrivi solo" codice ...
Paddyslacker

24

La programmazione è proprio come il lavoro in catena di montaggio. Stai lavorando a un prodotto per un certo periodo (forse con i colleghi) e alla fine lo spedisci. Proprio come costruire una casa di mattoni.

Contra: la programmazione contiene molta creatività e pianificazione. È arte. Come il muratore, anche un programmatore conosce la differenza tra modellare un mattone e progettare un'intera cattedrale.


6
Concordo sulla differenza rispetto al lavoro in catena di montaggio, ma per molti versi non penso che sia molto diverso dalla costruzione di una casa.
Billy ONeal,

24

Il porting di un programma su C ++ lo renderà automaticamente più veloce.


Vorrei estendere ad altre lingue di basso livello. È possibile ottenere il contrario quando il programmatore non sa cosa sta facendo.
Maniero,

2
Un'altra variante comune è il passaggio a un'architettura client-server. "L'aggiornamento a SQL renderà la mia app molto più veloce!" Non necessariamente.
JohnFx,

Sì, è piuttosto il contrario molte volte. I database di tipo SQL sono buoni per essere ACID o quasi, hanno un prezzo. E potrebbe essere peggio, il pensiero sbagliato sulle tecniche SQL potrebbe essere dannoso per le prestazioni.
Maniero,

6
Porting su C ++ / C per quelli scritti in Python / Perl / Ruby / ecc. Porting su asm per quelli scritti in C / C ++: P. Mi chiedo a cosa vorresti portarti? progettandolo nell'hardware?
MAK,


21

Qualsiasi ambiente di programmazione con un visual designer di qualche tipo lo farà in modo che gli utenti aziendali possano "scrivere" il programma e che non siano necessari veri programmatori.


9
Ah sì. È sempre divertente quando alcune aziende creano un nuovo strumento di creazione per rendere ridondanti i programmatori e quindi tutti coloro che lo adottano vanno avanti e assumono specialisti <strumento di creazione> ben pagati per usarlo effettivamente. Caso in questione: Joomla! e tutto quel non senso.
Alan Plum,

HA HA HA HA HA HA HAAA HA +1 :)
Billy ONeal

Cobol ci ha già provato :)
Carra il

20

Riutilizzo di OOP. È il più grande errore commercializzato nella programmazione.


1
Bene. L'HP XL WESM è all'incirca l'85% uguale al Symbol WS5100 (è in corso OEMming). Vorresti copiare e incollare quella percentuale del mio codice di monitoraggio e configurazione in modo che ci siano il doppio dei bug, o preferiresti che lo riscrissi da zero e impiegassi quaranta volte il tempo e ce ne siano cinque volte il numero? Oppure sei solo sotto pressione da parte di una gestione folle che pensa che sia una delle tante panacee magiche a rendere più veloce $ project?

1
Il riutilizzo nel piccolo è stato risolto 40 anni fa e oltre. Il riutilizzo in generale è difficile e non è stato ancora risolto IMHO. Proprio come dice Robert Glass in Fatti e errori dell'ingegneria del software
MarkJ,
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.