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

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.

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

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

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.

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

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ì;)

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.

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

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?

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

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?

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

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

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.

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.

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

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.

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.

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

Java è solo C ++ con classi diverse.

Java è lento .

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.

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

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

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

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

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!

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.

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.

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

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.

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