Qual è la tua opinione di programmazione più controversa?

Questo è decisamente soggettivo, ma vorrei cercare di evitare che diventi polemico. Penso che potrebbe essere una domanda interessante se le persone la trattano in modo appropriato.

L'idea per questa domanda è venuta dal thread dei commenti dalla mia risposta alla "Quali sono le cinque cose che odi della tua lingua preferita?" domanda . Ho sostenuto che le classi in C # dovrebbero essere sigillate per impostazione predefinita: non inserirò il mio ragionamento nella domanda, ma potrei scrivere una spiegazione più completa come risposta a questa domanda. Sono stato sorpreso dal calore della discussione nei commenti (attualmente 25 commenti).

Quindi, quali opinioni controverse hai ? Preferirei evitare il tipo di cose che finiscono per essere piuttosto religiose con una base relativamente scarsa (ad es. Collocazione di parentesi graffe), ma esempi potrebbero includere cose come "i test unitari non sono terribilmente utili" o "i campi pubblici vanno davvero bene". La cosa importante (per me, comunque) è che hai delle ragioni dietro le tue opinioni.

Per favore, presenta la tua opinione e il tuo ragionamento - Incoraggerei le persone a votare opinioni che sono ben argomentate e interessanti, indipendentemente dal fatto che tu sia d'accordo o meno con loro.

I programmatori che non programmano nel tempo libero per divertimento non diventeranno mai così bravi come quelli che lo fanno.

Penso che anche le persone più intelligenti e di talento non diventeranno mai dei veri programmatori a meno che non lo considerino più di un lavoro. Ciò significa che fanno piccoli progetti sul lato, o semplicemente pasticciano con molte lingue e idee diverse nel loro tempo libero.

(Nota: non sto dicendo che i bravi programmatori non facciano altro che programmare, ma fanno di più che programmare dalle 9 alle 5)

L'unica "best practice" che dovresti usare continuamente è "Usa il tuo cervello".

Troppe persone saltano su troppi bandwagon e provano a forzare metodi, schemi, strutture ecc. Su cose che non li giustificano. Solo perché qualcosa è nuovo o perché qualcuno rispettato ha un'opinione, non significa che vada bene per tutti :)

EDIT: Solo per chiarire - Non penso che le persone dovrebbero ignorare le migliori pratiche, le opinioni apprezzate ecc. Solo che le persone non dovrebbero semplicemente saltare ciecamente su qualcosa senza pensare al PERCHÉ questa "cosa" è così grande, È applicabile a ciò che io lo sto facendo e QUALI vantaggi / svantaggi comporta?

"Googling it" va bene!

Sì, lo so che offende alcune persone là fuori che i loro anni di intensa memorizzazione e / o gloriose pile di libri di programmazione stanno iniziando a cadere a terra a una risorsa a cui chiunque può accedere in pochi secondi, ma non dovresti tenerlo contro le persone che lo usano.

Troppo spesso sento risposte google a problemi il risultato di critiche, ed è davvero senza senso. Prima di tutto, si deve ammettere che tutti hanno bisogno di materiali di riferimento. Non sai tutto e dovrai cercare le cose. Ammettendo che, importa davvero dove hai ottenuto le informazioni? Importa se lo hai cercato in un libro, se lo hai cercato su Google o se l'hai sentito da una rana parlante che hai allucinato? No. Una risposta giusta è una risposta giusta.

L'importante è comprendere il materiale, utilizzarlo come mezzo per raggiungere una soluzione di programmazione di successo e il cliente / datore di lavoro è soddisfatto dei risultati.

(anche se stai ricevendo risposte da rane parlanti allucinatorie, dovresti probabilmente ottenere comunque un aiuto)

La maggior parte dei commenti nel codice sono in realtà una forma perniciosa di duplicazione del codice.

Trascorriamo la maggior parte del nostro tempo a mantenere il codice scritto da altri (o noi stessi) e i commenti scadenti, errati, obsoleti e fuorvianti devono essere in cima all'elenco degli artefatti più fastidiosi nel codice.

Penso che alla fine molte persone li cancellino, in particolare quelle mostruosità da fioriere.

Molto meglio concentrarsi sul rendere leggibile il codice, sul refactoring se necessario e sulla riduzione al minimo dei modi di dire e delle stranezze.

D'altra parte, molti corsi insegnano che i commenti sono molto più importanti del codice stesso, portando a questa riga successiva si aggiunge uno stile di commento alla fattura .

XML è altamente sopravvalutato

Penso che troppi saltino sul carrozzone XML prima di usare il loro cervello ... XML per roba web è fantastico, poiché è progettato per questo. Altrimenti, penso che alcune definizioni di problemi e idee progettuali dovrebbero impedire qualsiasi decisione di utilizzarlo.

I miei 5 centesimi

Non tutti i programmatori sono uguali

Molto spesso i manager pensano che DeveloperA == DeveloperB semplicemente perché hanno lo stesso livello di esperienza e così via. In realtà, le prestazioni di uno sviluppatore possono essere 10 volte o addirittura 100 volte quelle di un altro.

È politicamente rischioso parlarne, ma a volte ho voglia di sottolineare che, anche se molti membri del team possono sembrare di pari abilità, non è sempre il caso. Ho anche visto casi in cui gli sviluppatori principali erano "oltre ogni speranza" e gli sviluppatori junior hanno svolto tutto il lavoro effettivo, ma mi sono assicurato che avessero ottenuto il merito. :)

Non riesco a capire perché la gente pensi che Java sia assolutamente il miglior "primo" linguaggio di programmazione da insegnare nelle università.

Per uno, credo che il primo linguaggio di programmazione dovrebbe essere tale da evidenziare la necessità di imparare il flusso di controllo e le variabili, non gli oggetti e la sintassi

Per un altro, credo che le persone che non hanno avuto esperienza nel debug delle perdite di memoria in C / C ++ non possano apprezzare appieno ciò che Java porta sul tavolo.

Anche la naturale progressione dovrebbe essere da "come posso fare questo" a "come posso trovare la libreria che lo fa" e non viceversa.

Se conosci solo una lingua, non importa quanto bene la conosci, non sei un grande programmatore.

Sembra esserci un atteggiamento che dice che una volta che sei veramente bravo in C # o Java o in qualsiasi altra lingua che hai iniziato a studiare, allora è tutto ciò di cui hai bisogno. Non ci credo: ogni lingua che ho mai imparato mi ha insegnato qualcosa di nuovo sulla programmazione che sono stato in grado di riportare nel mio lavoro con tutti gli altri. Penso che chiunque si limiti a una lingua non sarà mai buono come potrebbe essere.

Mi indica anche una certa mancanza di curiosità e volontà di sperimentare che non coincidono necessariamente con le qualità che mi aspetterei di trovare in un programmatore davvero bravo.

Prestazioni non importa.

Le istruzioni di stampa sono un modo valido per eseguire il debug del codice

Credo che sia perfettamente corretto eseguire il debug del codice sporcandolo System.out.println(o qualunque altra istruzione di stampa funzioni nella tua lingua). Spesso, questo può essere più veloce del debug e puoi confrontare gli output stampati con altre esecuzioni dell'app.

Assicurati di rimuovere le istruzioni di stampa quando vai in produzione (o meglio, trasformale in istruzioni di registrazione)

Il tuo compito è metterti senza lavoro.

Quando scrivi software per il tuo datore di lavoro, qualsiasi software che crei deve essere scritto in modo tale da poter essere raccolto da qualsiasi sviluppatore e compreso con il minimo sforzo. È ben progettato, scritto in modo chiaro e coerente, formattato in modo pulito, documentato dove deve essere, costruisce quotidianamente come previsto, verificato nel repository e opportunamente aggiornato.

Se vieni investito da un autobus, licenziato, licenziato o lasci il lavoro, il tuo datore di lavoro dovrebbe essere in grado di sostituirti in un attimo e il ragazzo successivo potrebbe entrare nel tuo ruolo, raccogliere il tuo codice ed essere attivo e in esecuzione in una settimana al massimo. Se lui o lei non può farlo, allora hai fallito miseramente.

È interessante notare che ho scoperto che avere questo obiettivo mi ha reso più prezioso per i miei datori di lavoro. Più mi sforzo di essere usa e getta, più divento prezioso per loro.

1) La farsa delle app aziendali :

Penso che l'intera cosa dei quadri "Enterprise" sia fumo e specchi. J2EE, .NET, la maggior parte dei framework Apache e la maggior parte delle astrazioni per gestire tali cose creano molta più complessità di quanto non risolvano.

Prendi qualsiasi normale ORM Java o .NET o qualsiasi framework MVC apparentemente moderno per entrambi che fa "magia" per risolvere compiti noiosi e semplici. Finisci per scrivere enormi quantità di brutte targhe XML che è difficile convalidare e scrivere rapidamente. Hai enormi API in cui la metà di queste sono solo per integrare il lavoro delle altre API, interfacce impossibili da riciclare e classi astratte necessarie solo per superare l'inflessibilità di Java e C #. Semplicemente non abbiamo bisogno di gran parte di questo.

Che ne dite di tutti i diversi application server con la loro sintassi maledetta descrittore, i database eccessivamente complessi e i prodotti groupware?

Il punto di ciò non è che complessità == cattiva, è quella complessità non necessaria == cattiva. Ho lavorato in installazioni aziendali di grandi dimensioni dove era necessario in parte, ma anche nella maggior parte dei casi sono necessari pochi script sviluppati in casa e un semplice frontend Web per risolvere la maggior parte dei casi d'uso.

Proverei a sostituire tutte queste app enterprise con semplici framework Web, DB open source e banali costrutti di programmazione.

2) N-anni di esperienza richiesti:

A meno che tu non abbia bisogno di un consulente o un tecnico per gestire un problema specifico relativo a un'applicazione, API o framework, non hai davvero bisogno di qualcuno con 5 anni di esperienza in quell'applicazione. Ciò di cui hai bisogno è uno sviluppatore / amministratore in grado di leggere la documentazione, che abbia conoscenza del dominio in qualunque cosa tu stia facendo e che possa apprendere rapidamente. Se hai bisogno di sviluppare in qualche tipo di linguaggio, uno sviluppatore decente lo prenderà in meno di 2 mesi. Se hai bisogno di un amministratore per il web server X, tra due giorni avrebbe dovuto leggere le pagine man e i newsgroup ed essere al passo con i tempi. Niente di meno e quella persona non vale ciò che viene pagato.

3) Il curriculum comune di laurea in "informatica":

La maggior parte dei diplomi in informatica e ingegneria del software sono tori. Se il tuo primo linguaggio di programmazione è Java o C #, stai facendo qualcosa di sbagliato. Se non ottieni diversi corsi pieni di algebra e matematica, è sbagliato. Se non approfondisci la programmazione funzionale, è incompleta. Se non puoi applicare invarianti di loop a un banale per loop, non valga la pena di essere un presunto scienziato informatico. Se esci con esperienza nelle lingue xey e orientamento dell'oggetto, è pieno di s ***. Un vero informatico vede un linguaggio in termini di concetti e sintassi che utilizza e vede le metodologie di programmazione come una tra le tante e ha una buona comprensione delle filosofie sottostanti sia che la scelta di nuovi linguaggi, metodi di progettazione o linguaggi di specifica dovrebbero sii banale.

Getter e setter sono molto abusati

Ho visto milioni di persone affermare che i campi pubblici sono cattivi, quindi li rendono privati ​​e forniscono getter e setter per tutti loro. Credo che questo sia quasi identico a rendere pubblici i campi, forse un po 'diverso se stai usando i thread (ma generalmente non è il caso) o se i tuoi accessor hanno una logica di business / presentazione (almeno qualcosa di "strano").

Non sono a favore di campi pubblici, ma contro la creazione di un getter / setter (o proprietà) per ognuno di loro, e quindi affermando che farlo è incapsulamento o nascondere informazioni ... ah!

AGGIORNARE:

Questa risposta ha sollevato alcune controversie nei suoi commenti, quindi cercherò di chiarirlo un po '(lascerò l'originale intatto poiché questo è ciò che molte persone hanno votato).

Prima di tutto: chiunque usi campi pubblici merita il tempo di prigione

Ora, creare campi privati ​​e quindi utilizzare l'IDE per generare automaticamente getter e setter per ognuno di essi è quasi altrettanto negativo che utilizzare campi pubblici.

Molte persone pensano:

private fields + public accessors == encapsulation

Dico che la generazione (automatica o meno) della coppia getter / setter per i tuoi campi va effettivamente contro il cosiddetto incapsulamento che stai cercando di ottenere.

Infine, vorrei citare lo zio Bob in questo argomento (tratto dal capitolo 6 di "Codice pulito"):

C'è una ragione per cui manteniamo private le nostre variabili. Non vogliamo che nessun altro dipenda da loro. Vogliamo che la libertà cambi il tipo o l'implementazione per un capriccio o un impulso. Perché, quindi, così tanti programmatori aggiungono automaticamente getter e setter ai loro oggetti, esponendo i loro campi privati come se fossero pubblici?

I diagrammi UML sono estremamente sopravvalutati

Naturalmente ci sono diagrammi utili, ad esempio un diagramma di classe per il modello composito , ma molti diagrammi UML non hanno assolutamente alcun valore.

Opinione: SQL è il codice. Trattalo come tale

Cioè, proprio come C #, Java o altri linguaggi oggetto / procedure preferiti, sviluppa uno stile di formattazione che sia leggibile e gestibile.

Odio quando vedo il codice SQL formattato libero sciatto. Se urli quando vedi entrambi gli stili di parentesi graffe su una pagina, perché o perché non urli quando vedi un SQL o SQL formattato libero che oscura o offusca la condizione JOIN?

La leggibilità è l'aspetto più importante del tuo codice.

Ancor più della correttezza. Se è leggibile, è facile da risolvere. È anche facile da ottimizzare, facile da cambiare, facile da capire. E spero che anche altri sviluppatori possano imparare qualcosa da esso.

Se sei uno sviluppatore, dovresti essere in grado di scrivere codice

L'anno scorso ho fatto un bel po 'di interviste e, da parte mia, avrei dovuto testare il modo in cui la gente pensava e come implementavano algoritmi da semplici a moderati su una lavagna bianca. Inizialmente avevo iniziato con domande come:

Dato che Pi può essere stimato usando la funzione 4 * (1 - 1/3 + 1/5 - 1/7 + ...) con più termini che danno una maggiore precisione, scrivere una funzione che calcola Pi con una precisione di 5 cifre decimali .

È un problema che dovrebbe farti pensare, ma non dovrebbe essere fuori portata per uno sviluppatore esperto (si può rispondere in circa 10 righe di C #). Tuttavia, molti dei nostri candidati (presumibilmente preselezionati dall'agenzia) non hanno nemmeno potuto iniziare a rispondere o spiegare come avrebbero potuto rispondere. Quindi dopo un po 'ho iniziato a porre domande più semplici come:

Dato che l'area di un cerchio è data da Pi per il raggio al quadrato, scrivere una funzione per calcolare l'area di un cerchio.

Sorprendentemente, più della metà dei candidati non è stata in grado di scrivere questa funzione in nessuna lingua (posso leggere le lingue più popolari, quindi lascio che usino qualsiasi lingua di loro scelta, incluso lo pseudo-codice). Avevamo "sviluppatori C #" che non potevano scrivere questa funzione in C #.

Sono stato sorpreso da questo. Ho sempre pensato che gli sviluppatori dovrebbero essere in grado di scrivere codice. Sembra che, al giorno d'oggi, questa sia un'opinione controversa. Certamente è tra i candidati al colloquio!

Modificare:

C'è molta discussione nei commenti sul fatto che la prima domanda sia buona o cattiva e se dovresti porre domande così complesse in un'intervista. Non approfondirò qui (questa è una domanda completamente nuova) oltre a dire che in gran parte ti manca il punto del post .

Sì, ho detto che le persone non potevano fare alcun passo avanti con questo, ma la seconda domanda è banale e molte persone non potevano fare alcun passo avanti con quello! Chiunque si definisca uno sviluppatore dovrebbe essere in grado di scrivere la risposta alla seconda in pochi secondi senza nemmeno pensare. E molti non possono.

L'uso della notazione ungherese dovrebbe essere punito con la morte.

Questo dovrebbe essere abbastanza controverso;)

I modelli di progettazione danneggiano il buon design più di quanto non lo stiano aiutando.

La progettazione del software IMO, in particolare una buona progettazione del software, è troppo varia per essere catturata in modo significativo nei modelli, specialmente nel numero ridotto di modelli che le persone possono effettivamente ricordare - e sono troppo astratti per essere ricordati più di una manciata. Quindi non stanno aiutando molto.

D'altra parte, troppe persone si innamorano del concetto e cercano di applicare modelli ovunque - di solito, nel codice risultante non è possibile trovare il disegno reale tra tutti i Singletons (e completamente privi di significato) e le Fabbriche astratte.

Meno codice è meglio di più!

Se gli utenti dicono "tutto qui?" E il tuo lavoro rimane invisibile, è fatto bene. La gloria può essere trovata altrove.

PHP fa schifo ;-)

La prova è nel budino.

I test unitari non ti aiuteranno a scrivere un buon codice

L'unico motivo per avere unit test è assicurarsi che il codice che già funziona non si rompa. Scrivere prima i test o scrivere il codice nei test è ridicolo. Se scrivi ai test prima del codice, non saprai nemmeno quali sono i casi limite. Potresti avere un codice che supera i test ma non riesce ancora in circostanze impreviste.

Inoltre, i buoni sviluppatori manterranno bassa la coesione, il che renderà improbabile che l'aggiunta di nuovo codice causi problemi con le cose esistenti.

In effetti, lo generalizzerò ancora di più,

La maggior parte delle "Best Practices" nell'ingegneria del software sono lì per impedire ai programmatori malvagi di fare troppi danni .

Sono lì per tenere a mano i cattivi sviluppatori e impedire loro di fare errori stupidi. Naturalmente, poiché la maggior parte degli sviluppatori è cattiva, questa è una buona cosa, ma i buoni sviluppatori dovrebbero ottenere un passaggio.

Scrivi piccoli metodi. Sembra che i programmatori adorino scrivere metodi molto lunghi in cui fanno più cose diverse.

Penso che dovrebbe essere creato un metodo ovunque tu possa nominarne uno.

Va bene scrivere codice spazzatura di tanto in tanto

A volte è sufficiente un codice di immondizia rapido e sporco per eseguire un determinato compito. Pattern, ORM, SRP, qualunque cosa ... Lanciare una console o un'app Web, scrivere un sql in linea (si sente bene) e soddisfare i requisiti.

Codice == Design

Non sono un fan dei sofisticati diagrammi UML e della documentazione infinita di codice. In una lingua di alto livello, il tuo codice dovrebbe essere leggibile e comprensibile così com'è. Documentazioni e diagrammi complessi non sono davvero più facili da usare.

Ecco un articolo sul tema del codice come design .

Lo sviluppo del software è solo un lavoro

Non fraintendetemi, mi piace molto lo sviluppo del software. Ho scritto un blog negli ultimi anni sull'argomento. Ho trascorso abbastanza tempo qui per avere> 5000 punti reputazione. E lavoro in una start-up facendo in genere 60 ore settimanali per molto meno denaro di quanto potrei ottenere come appaltatore perché il team è fantastico e il lavoro è interessante.

Ma nel grande schema delle cose, è solo un lavoro.

Si colloca in importanza sotto molte cose come la famiglia, la mia ragazza, gli amici, la felicità ecc. E sotto altre cose che preferirei fare se avessi una scorta illimitata di denaro come andare in moto, yacht a vela o snowboard.

Penso che a volte molti sviluppatori dimentichino che lo sviluppo è solo qualcosa che ci consente di avere le cose più importanti nella vita (e di averle facendo qualcosa che ci piace) piuttosto che essere l'obiettivo finale in sé.

Penso anche che non ci sia nulla di sbagliato nell'avere binari nel controllo del codice sorgente ... se c'è una buona ragione per farlo. Se ho un assembly per cui non ho i sorgenti, e potrei non trovarmi necessariamente nello stesso posto su ogni macchina devs, di solito lo inserirò in una directory "binaries" e lo farò riferimento in un progetto usando un percorso relativo .

Molte persone sembrano pensare che dovrei essere bruciato sul rogo per aver menzionato "controllo del codice sorgente" e "binario" nella stessa frase. Conosco anche luoghi che hanno regole rigide che dicono che non puoi aggiungerli.

Ogni sviluppatore dovrebbe avere familiarità con l'architettura di base dei computer moderni. Questo vale anche per gli sviluppatori che prendono di mira una macchina virtuale (forse anche di più, perché gli è stato detto più volte che non devono preoccuparsi della gestione della memoria, ecc.)

Gli architetti / designer di software sono sopravvalutati

Come sviluppatore, odio l'idea di Software Architects. Fondamentalmente sono persone che non programmano più a tempo pieno, leggono riviste e articoli e poi ti spiegano come progettare software. Solo le persone che effettivamente scrivono software a tempo pieno per vivere dovrebbero farlo. Non mi importa se sei stato il miglior programmatore del mondo 5 anni fa prima di diventare architetto, la tua opinione è inutile per me.

Come è controverso?

Modifica (per chiarire): penso che la maggior parte degli architetti del software siano grandi analisti aziendali (parlare con i clienti, scrivere requisiti, test, ecc.), Penso semplicemente che non abbiano spazio nella progettazione di software, di alto livello o altro.

Non esiste un approccio "unico per tutti" allo sviluppo

Sono sorpreso che questa sia un'opinione controversa, perché mi sembra un senso comune. Tuttavia, ci sono molte voci su blog popolari che promuovono l'approccio allo sviluppo "taglia unica", quindi penso di poter essere effettivamente in minoranza.

Le cose che ho visto essere propagandate come l' approccio corretto per qualsiasi progetto - prima che siano note informazioni al riguardo - sono cose come l'uso di Test Driven Development (TDD), Domain Driven Design (DDD), Object-Relational Mapping (ORM) , Agile (maiuscola A), Orientamento agli oggetti (OO), ecc. Ecc. Che comprende tutto, dalle metodologie alle architetture ai componenti. Tutto con simpatici acronimi commerciabili, ovviamente.

Le persone sembrano addirittura arrivare a mettere badge sui loro blog come "I'm Test Driven" o simili, come se la loro stretta aderenza a un singolo approccio qualunque fosse il dettaglio del progetto del progetto sia effettivamente una buona cosa .

Non lo è.

La scelta delle metodologie e architetture e componenti corretti, ecc., È qualcosa che dovrebbe essere fatto in base al progetto e dipende non solo dal tipo di progetto su cui stai lavorando e dai suoi requisiti unici, ma anche dalle dimensioni e dalla capacità della squadra con cui stai lavorando.