it-swarm.it

Cosa dovrebbe sapere ogni programmatore sulla programmazione?

Per favore, rimanere su questioni tecniche, evitare comportamenti, problemi culturali, di carriera o politici.

52
Maniero
  1. Il bug è nel il tuo codice , non nel compilatore o nelle librerie di runtime.

  2. Se vedi un bug che non può accadere, controlla di aver compilato e distribuito correttamente il tuo programma. (Soprattutto se stai usando un complicato IDE o framework di build che cerca di nascondere i dettagli disordinati da te ... o se la tua build comporta molti passaggi manuali.)

  3. I programmi simultanei/multi-thread sono difficili da scrivere e più difficili da testare correttamente. È consigliabile delegare il più possibile a librerie e framework concorrenti.

  4. Scrivere la documentazione fa parte del tuo lavoro come programmatore. Non lasciarlo fare a "qualcun altro".

[~ ~ #] modifica [~ ~ #]

Sì, il mio punto n. 1 è sopravvalutato. Anche le migliori piattaforme applicative progettate hanno la loro parte di bug e alcune di quelle meno ben progettate sono piene di loro. Tuttavia, dovresti sempre sospettare prima il tuo codice e iniziare a incolpare i bug del compilatore/libreria solo quando hai chiara prova che il tuo codice non è in errore.

Nei giorni in cui ho fatto lo sviluppo di C/C++, ricordo casi in cui i presunti "bug" dell'ottimizzatore si sono rivelati dovuti a me/ad altri programmatori che hanno fatto cose che le specifiche del linguaggio dicono che hanno risultati indefiniti. Questo vale anche per linguaggi apparentemente sicuri come Java; per esempio. dare una lunga occhiata al Java (capitolo 17 di JLS).

92
Stephen C
  • Come leggere il codice di altre persone.
  • Il codice non esiste se non è selezionato nel sistema di controllo versione.
84
pramodc84

I calcoli in virgola mobile sono non precisi.

76
Chinmay Kanchi

Non smettere di imparare.

63
systempuntoout

Che la cosa numero 1 che puoi fare per aumentare la qualità e la manutenibilità del tuo codice è RIDURRE LA DUPLICAZIONE.

44
Chris Holmes

Risoluzione dei problemi e capacità di debug

A malapena trascorrono del tempo su questo argomento in nessuno dei corsi di programmazione che ho seguito, e nella mia esperienza è uno dei maggiori determinanti di quanto sia produttivo un programmatore. Piaccia o no, trascorri molto più tempo nella fase di manutenzione della tua app rispetto alla nuova fase di sviluppo.

Ho lavorato con moltissimi programmatori che eseguono il debug cambiando casualmente le cose senza alcuna strategia per trovare il problema. Ho avuto questa conversazione dozzine di volte.

Altro programmatore: Penso che dovremmo provare a vedere se lo risolve.
Me: Va bene, supponendo che lo risolva. Cosa ti dice su dove si trova l'origine del problema?
Altro programmatore: Non lo so, ma dobbiamo provare qualcosa .

39
JohnFx
  1. Non essere intelligente; essere chiaro.
  2. Utilizzare prima del riutilizzo.
  3. I nomi contano.
  4. Una funzione fa 1 cosa e lo fa bene.
  5. Piccolo è meglio di grande.
37
KevBurnsJr

Le basi. Attualmente i programmatori apprendono tecnologie e non concetti. È sbagliato.

34
clrod

Ogni programmatore dovrebbe sapere che inserisce sempre assunzioni nel codice, ad es. "questo numero sarà positivo e finito", "questo codice sarà in grado di connettersi al server in un batter d'occhio".

E dovrebbe sapere che dovrebbe prepararsi per quando quelle ipotesi si rompono.

26

Ogni programmatore dovrebbe conoscere i test.

19
Tom Duckering

Impara concetti. Puoi Google la sintassi.

17
pramodc84

Pensiero critico e logico. non puoi fare nulla di buono senza di essa.

16
Mladen Prajdic
14
Carlos

Test unitari. Questo è un ottimo modo per codificare i tuoi presupposti su come usare il codice.

14
btlog
13
Maniero

Conoscenza del dominio. Le specifiche non sono mai al 100%; conoscere il dominio reale con cui si sta sviluppando aumenterà SEMPRE la qualità del prodotto.

13
Steven Evers

È più difficile di quanto pensi.

Sebbene sia facile (ish) mettere insieme qualcosa che funzioni se usato normalmente, gestire input errati, tutti i casi Edge e corner, possibili modalità di errore ecc. Richiede tempo e probabilmente sarà la parte più difficile del lavoro.

Quindi devi anche rendere l'applicazione buona.

13
ChrisF

Puntatori, ovviamente. :)

11

I dati sono più importanti del codice.

Se i tuoi dati sono intelligenti, il codice può essere stupido.

Il codice stupido è facile da capire. Anche i dati intelligenti.

Quasi ogni dolore algoritmico che io abbia mai avuto è stato dovuto al fatto che i dati si trovavano nel posto sbagliato o abusavano del suo vero significato. Se i tuoi dati hanno un significato inseriscilo nel sistema dei tipi.

11
Gonzales

Codice completo 2 - da copertina a copertina

11
Kyle B.

Quale lingua e ambiente è più adatto per il lavoro. E non è sempre il tuo preferito.

10
Dan Diplo

Dividere e conquistare. Di solito è il modo migliore per risolvere qualsiasi tipo di problema pratico dalla pianificazione al debug.

10
Rick Minerich

La vera abilità si riflette nella capacità di eseguire bene un progetto semplice, non nella capacità di far funzionare un progetto complicato.

Questa abilità deriva da una maggiore padronanza dei fondamenti, non dalla padronanza degli arcani. Un programmatore di alto livello non è definito dalla sua capacità di codificare ciò che gli altri non possono (usando funzioni di livello superiore, programmazione funzionale avanzata, what-have-you) ma piuttosto dalla loro capacità di affinare una codifica perfettamente banale. Scelta della decomposizione appropriata della funzionalità tra le classi; costruzione robusta; utilizzando tecniche di programmazione difensiva; e usando schemi e nomi che portano ad una maggiore autocertificazione, questi sono il pane e il burro della programmazione di alto livello.

Scrivere un buon codice a cui tu o qualcun altro potete tornare in una settimana al mese o un anno e capire come usare, modificare, migliorare o estendere quel codice è cruciale. Ti fa risparmiare tempo e fatica mentale. Unge le ruote della produttività rimuovendo i blocchi stradali su cui ti saresti imbattuto prima (forse interrompendo il tuo treno di pensieri, o forse prendendo ore o giorni di sforzo lontano da altri lavori, ecc.) Semplifica la concentrazione sui problemi difficili e a volte risolve i problemi.

In una parola: eleganza. Ogni classe, ogni metodo, ogni condizione, ogni blocco, ogni nome di variabile: ricerca dell'eleganza.

8
Wedge

Non incolpare mai l'utente di ciò che potrebbe essere risolto con un'esperienza utente più pulita o una migliore documentazione. Spesso, i programmatori presumono automaticamente che l'utente sia un idiota che non può fare nulla di buono, quando il problema è una scarsa esperienza generale o mancanza di comunicazione. I programmi sono pensati per essere utilizzati e trattare l'utente con disprezzo significa in primo luogo perdere il punto della programmazione.

8
user8

Ogni programmatore dovrebbe sapere come usare il debugger e sapere come usarlo bene .

6
Brian R. Bondy

Come usare Google

5
bruno077

Strutture dati

5
Maniero

Valutazione del corto circuito, sebbene sia una delle prime cose che ti insegnano sugli operatori booleani.

Gli errori dell'utente non lo sono; sono errori di usabilità:

  • Le funzionalità pericolose dovrebbero essere annullabili, non solo avvertite. Ecco rm, che ancora non funziona con il cestino.
  • Fai cosa meno dannosa se l'utente si rompe (ESC, Ctrl-C). Idealmente, il sistema dovrebbe trovarsi nello stesso stato di prima di eseguire il comando. rm, di nuovo.
  • Le opzioni dannose dovrebbero essere lontane da quelle innocue. Facendo clic con il pulsante destro del mouse su un file nel cestino di GNOME, è possibile visualizzare "Elimina in modo permanente" direttamente accanto a "Ripristina" :(

Non scegliere specificamente su GNU Tools o GNOME, ma questi erano gli esempi più facili da trovare.

4
l0b0

Come stimare con precisione il tempo impiegato da una funzionalità per implementare. Ancora più importante, come comunicare che non stai cagando quando invii quella stima.

4
wheaties

Lo stile di programmazione è importante:

  • rientri coerenti
  • uso coerente dello spazio bianco (ad esempio attorno agli operatori),
  • collocamento coerente di {} questioni,
  • gli identificatori ben scelti contano,
  • eccetera.

... e il buon design conta.

Idealmente, il programmatore impara queste cose prima (o durante) la sua prima revisione del codice. Nel peggiore dei casi, il programmatore li impara quando il capo gli dice di apportare in fretta alcune modifiche non banali a un codice orribile.

4
Stephen C

Parlando di sviluppatori di software commerciali qui ... Ovviamente potrebbe non applicarsi a un sistema di sicurezza DOD o ad un hedge fund quant.

  • Concentrati su ciò che funziona, non su ciò che è intelligente, KISS.
  • Tieni presente la regola 80/20 e non passare tutto il tempo a cercare di compiacere/vendere la minoranza.
  • Segui un corso in strutture/algoritmi di dati.
  • Test, test, test.
  • Non perdere tempo nel codice in produzione e attualmente funzionante. A meno che tu non abbia un flusso di cassa eccessivo e nessuna nuova idea. Allora va bene.
  • La stragrande maggioranza del tuo tempo sarà dedicata allo smistamento attraverso l'innesto e non alla risoluzione di interessanti problemi di programmazione. A meno che tu non stia intervistando, nel qual caso le persone vogliono solo vedere come risolvi interessanti problemi di programmazione.
3
red-dirt

Che ci sono -

1) Altri paradigmi di programmazione oltre a solo OO (orientamento dell'oggetto) 2) Altri IDE migliori oltre Visual Studio (questo è specialmente per i programmatori che hanno lavorato solo su Windows e solo su tecnologie MS)

3
Manoj Waikar

Come funziona il computer davvero, fondamenti del linguaggio, algoritmi/strutture di dati, analisi dell'algoritmo e qualche misura della teoria della complessità.

3
Paul Nathan

Non riesco a credere che questo non sia stato menzionato

Il valore di ogni programmatore è che sale deve essere in grado di produrre software pronto per il mondo .

Con questo intendo seguire i principi di base dell'internazionalizzazione come esternalizzare tutte le stringhe ecc.

Non riesco a credere quante volte ho visto stringhe o dialoghi inglesi con codifica rigida con stringhe troncate ecc. Quando il prodotto è stato tradotto.

2
Jimmy Collins

Il test unitario non è un proiettile d'argento. Puoi ancora introdurre bug, scrivere test sbagliati e non dovrebbe essere l'unica forma di test che fai.

2
aqwert

I computer non capiscono la semantica. Supponi di avere questo:

var ferrari = new Ferrari();
ferrari.DriveTo(Places.Seattle);

Sul computer, potresti anche aver usato nomi di tipi diversi e usato:

var mxEEcceqs = new safHBBdueWE();
mxEEcceqs.HYBbQAW(n3dNm.pDojeW);

Nominare le cose è molto importante, ma non commettere l'errore di presumere che il computer sappia cosa "intendi" solo perché hai chiamato il tuo tipo "Ferrari" o il tuo metodo "DriveTo".

2
xofz

Ordine di esecuzione.

Rimarrai stupito, parlando con i programmatori contro le persone che non hanno mai visto o toccato il codice o i finti programmatori *, la cosa che non ottengono è l'ordine di esecuzione. Se incontri qualcuno che non riesce a capire le strutture di controllo, prendi per prima questa idea. Scoprirai che imparano più velocemente dopo.

* sì, quelle persone che sono in grado di ottenere un lavoro come programmatori, ma quando fai loro la domanda tecnica più semplice, vanno in rovina .. Penso che tutti ne abbiamo incontrato uno.

2
Philip

Ogni programmatore dovrebbe conoscere la "scienza" in Informatica (schemi di progettazione, algoritmi, oggetti, ecc ...) se riesci a padroneggiarlo, puoi programmare usando qualsiasi linguaggio, è solo una questione di abituarsi alla sintassi.

2
JD Frias

Che cosa sono lex e analisi, solo una vaga panoramica va bene. Meglio ancora, passando familiarità con almeno un framework generatore di parser.

La maggior parte dei più orribili WTF che ho visto sono le routine di analisi personalizzate delle persone. Inizialmente orribile da programmare, peggio da mantenere.

2
angusgr

Valutazione.

Un programmatore dovrebbe sapere come vengono valutate le dichiarazioni che scrivono. a(line.of(code) is aSequenceOf(evaluations)) e se non capisci come appare quella linea dopo ogni passaggio della sua valutazione, sarai estremamente limitato come programmatore nella tua capacità di sfruttare le funzionalità del linguaggio.

Non sto solo parlando di base

if (bool == false):
    return true
else:
    return false

che ovviamente può essere semplicemente sostituito da return !bool.

Mi riferisco anche alla capacità di comprendere la tua lingua al punto da poter inventare qualcosa del genere:

string[] thingsToOutput;
for(int i = 0; i <= thingsToOutput.Length; print(thingsToOutput[i++]));    

Quando ho visto per la prima volta una frase del genere mi ha fatto esplodere un po 'la mente; non mi era venuto in mente che avrei potuto sfruttare il ciclo for in questo modo. La persona che ha scritto quell'affermazione ha compreso più a fondo le possibilità a loro disponibili: ha visto più porte aperte di me, il che ha dato loro più libertà e potere nella loro capacità di progettare il codice.

Ora, se è buono il codice è un problema - se una di quelle porte dovrebbe deve essere aperta - questo è al dibattito. Resta che con grande potere derivano grandi responsabilità.

2
doppelgreener

Che conoscere la risposta a questa domanda non ti rende un programmatore

2
hplbsh

Nozioni di base sulle licenze software

  • La differenza tra una licenza di copyleft "virale" (GPL) rispetto ad Apache compatibile con sorgenti chiuse e MS-PL/MS-RL non virale.

  • Quando utilizzare LGPL e quando non farlo.

  • Compatibilità della licenza. Ad esempio, puoi collegare una moderna libreria con licenza Apache a un codice GPLv3, ma non a GPL 1 o 2.

  • Se possiedi il codice sorgente nella sua interezza, puoi pubblicarlo con quante (o poche) licenze desideri.

Nota per S.O. comunità:
Non esitare a modificare questa risposta come ritieni opportuno ... principalmente per informazioni non adatte alla sezione commenti qui sotto.

2

Crittografia. Non devi essere in grado di scrivere il tuo algoritmo di crittografia, ma devi avere una conoscenza di base di come funzionano la crittografia, l'autenticazione dei messaggi e la PKI. Ho lottato troppo a lungo con prove cieche ed errori in questo settore. Recentemente ho raccolto il libro "Cryptography Engineering" (di Ferguson, Schneier, Kohno) ed è stato un vero colpo d'occhio.

2
Tobias

Conosci il tuo sistema operativo/piattaforma prima di iniziare a scrivere codice.

Se si codifica Windows/Linux/Android/iOS ecc., Iniziare imparando il sistema operativo. Se scegli come target qualcos'altro come il Web, lo stesso vale.

1
Amir Rezaei

scrivi il codice per le persone!

niente più numero magico!

non scrivere tutto il codice in una riga!

1
linjunhalida
  1. costruire qualcosa che la gente vuole
  2. costruisci qualcosa che vuoi usare ogni giorno
  3. se non commenti il ​​tuo codice, assicurati che sia pulito
  4. commenta il tuo codice
1
Michael Ossareh

Non esiste un bug che non possa accadere.

1
Rayne

"Hello world" non è un'applicazione completa, in quanto non vi è alcuna affermazione dimostrata/programmatica secondo cui l'output è in realtà "Hello world". Il codice non è completo fino a quando non è stato testato dall'unità.

1
stimpy77

Alcuni di questi sono già stati pubblicati, ma ecco la mia lista:

  • Costruisci sui requisiti, non aggiungere cose che non ti servono, specialmente se "pensi" che lo farai. Se ne hai bisogno in seguito, aggiungilo quindi.
  • Come utilizzare la ricerca di Google. Non disturbare il tuo collega, fino a quando non hai guardato.
  • Non essere intelligente.
  • Non viene eseguito fino a quando non soddisfa TUTTI i requisiti, testato, documentato e verificato in SVN.
  • Corretti standard di codifica, ad es. Convenzioni di denominazione
1
Tyler Egeto

Scopri come distribuire bene il codice, i test e il pacchetto software.

Una delle peggiori abitudini degli sviluppatori che ho visto nell'industria è una comune ignoranza di come mettere il tuo software nelle mani di altre persone, ecco alcuni brutti segni:

Nuovo ambiente di sviluppo-itus:

  • Volevo imparare Ruby quindi abbiamo scritto le nostre cose in esso, il cliente e la build principale dovranno prendere un ambiente Ruby ora

Versione-UTI:

  • Il nostro team è passato alla versione X + 1 del compilatore perché è l'ultima, non l'abbiamo detto a nessuno?
  • Abbiamo bisogno della libreria versione Y, oh, le tue cose non funzionano con quello?
  • Abbiamo testato su una versione molto vecchia, non funziona con l'ultima build?
  • Abbiamo hackerato una versione speciale del kernel per far funzionare la versione

Solo binario-UTI:

  • Il nostro ambiente di compilazione è davvero complicato, ti forniremo solo binari

Multi-core-ITU:

  • Disabilita SMP, le nostre cose funzionano solo su un ambiente uniprocessore

Hard-coded-funzione-UTI:

  • Rimuovi il commento da questo #define per abilitare la funzione X, cosa vuoi dire che lo vuoi in fase di esecuzione?
1
tonylo

Semplicità, chiarezza, generalità. http://www.math.harvard.edu/computing/programming/rules.html

  • costruire sistemi come reti di processi semplici collegati da prese/tubi
  • scambiare dati in un semplice formato di testo: set di record di coppie "chiave: valore" o TSV

"Lo strumento di debug più efficace è ancora un attento pensiero, unito a dichiarazioni di stampa posizionate con giudizio." BWK

1
user2137

Più sai come funziona la sicurezza sulla tua piattaforma preferita, meglio è.

1
Ripped Off

Usa lo strumento giusto per il lavoro.

Il programmatore è l'elemento importante e la lingua e gli strumenti dovrebbero essere scelti in base al problema. Non abbiate paura di nuove lingue e progetti.

1
Jonathan Hendler
1
Daniel Grillo

Non c'è pianto nella programmazione!

1
Billy Coover
  1. una conoscenza approfondita dei concetti di base, ad es. tipi di dati, interfacce
  2. una comprensione di livello medio-alto dello strumento che stanno utilizzando ad es. conoscenza specifica .net/Java
  3. un'idea ragionevole delle "altre tecnologie con cui le tue cose si interfacciano", ad es. come funzionano i database
  4. all'incirca dove è diretta la loro base tecnologica, ad es. cos'è il cloud computing e quale impatto avrà sulla loro attuale gamma di competenze
1
adolf garlic

Come scrivere un programma FizzBuzz.

1
CtrlDot

Quando devi distribuire un'applicazione o mettere un sito Web in produzione al di fuori dei confini della tua azienda, tutto ciò che pensavi non avesse importanza, lo fa.

1
JeffO

Il codice è bello solo se fa quello che dovrebbe fare.

1
sambeau
  • Binario con conoscenza di base di firmati e non firmati.
  • Comprendi come funziona qualsiasi sistema numerico posizionale.
  • Comprendi come le strutture di dati di base sono archiviate in memoria.
1

La correzione del codice richiede più intelligenza rispetto alla scrittura iniziale dello stesso codice.

Pertanto, se scrivi il codice al limite della tua intelligenza, per definizione non sei abbastanza intelligente da risolverlo quando si rompe.

1
Adam Bachman

Scrivi prima le strutture dei tuoi dati, ciò significa tutto, dagli schemi di database ai meccanismi di rotazione/serializzazione.

La maggior parte dei progetti riguarda la memorizzazione e lo spostamento dei dati dal punto A al punto B in formato C.

Quando tutto è stato detto e fatto, circa il 90% del tuo codice sarà logico per eseguire la formattazione, ma il vero killer ha solo un formato per accedere e scrivere i tuoi dati. Una volta che hai un'API per l'accesso ai dati, puoi giocare con la formattazione come preferisci, ma una volta che avvii la produzione con un'API di archiviazione, può davvero farti capire che hai rovinato tutto.

1
user2040

Nelle 5 domande essenziali sullo schermo del telefono di Steve Yegge, sta cercando di assicurarsi che gli intervistati abbiano una conoscenza di base di:

  1. Coding. Il candidato deve scrivere un codice semplice, con sintassi corretta, in C, C++ o Java.
  2. Design OO. Il candidato deve definire base OO concetti e elaborare classi per modellare un semplice problema.
  3. Scripting e regex. Il candidato deve descrivere come trovare i numeri di telefono in 50.000 pagine HTML.
  4. Strutture dati. Il candidato deve dimostrare le conoscenze di base delle strutture di dati più comuni.
  5. Bit e byte. Il candidato deve rispondere a semplici domande su bit, byte e numeri binari.

http://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

Al momento in cui ha scritto questo, era su Amazon, ma ora lavora (e probabilmente conduce interviste) su Google. Questo ti fa superare lo schermo. Ecco come ha descritto ciò che stava cercando:

quello che sto cercando qui è un vuoto totale in una di queste aree. Va bene se lottano un po 'e poi lo capiscono. Va bene se hanno bisogno di alcuni suggerimenti o suggerimenti minori. Non mi importa se sono arrugginiti o lenti. Quello che stai cercando sono i candidati che sono completamente all'oscuro, o orribilmente confusi, sull'area in questione.

1
Lou Franco

La documentazione è molto importante. Ancora di più se stai costruendo qualcosa da zero. Aiuta a documentare le tue idee prima di scrivere qualsiasi codice.

L'ho imparato a mie spese.

1
Pablo

Non posso ancora commentare, ma sull'argomento "Capacità di test e debug", questa piccola gemma di Ned Batchelder è una lettura obbligata. (Quindi guadagna, molto di ciò che ha da dire sul debug e le asserzioni è degno di considerazione.)

0
Stan Rogers

Ogni programmatore dovrebbe sapere che l'unica cosa che sa è che non sa nulla. C'è molto da imparare.

0
sharjeel

Ogni programmatore dovrebbe associare le azioni FindNextSelected e FindPreviousSelected (visual studio) ai tasti della tastiera (preferibilmente F4 e F2). Ottieni due cose da questo:

  1. Modo più veloce per navigare tra i diversi punti di utilizzo variabile/funzione/sottostringa (più veloce rispetto a "Trova tutti i riferimenti")
  2. Possibilità di diff cose all'interno di un documento. Saltando avanti e indietro durante la ricerca di alcune sottostringhe puoi vedere le differenze tra le diverse posizioni. Non è necessario utilizzare Winmerge quando è necessario confrontare parti dello stesso documento.
0
AareP

Conoscere la sintassi di base delle espressioni regolari incluso il raggruppamento condizionale. Stai lontano dall'uso dei componenti aggiuntivi del comando regex specifici della libreria o almeno commenta/elabora quelle parti.

0
Bob Dobelina

Come farlo.

... Cosa vuoi dire che ho bisogno di 15 caratteri?

0
Randall Schulz

Programma con in mente la manutenibilità.

0
Jesse

Espressioni regolari THE Book about regular expressions

Non posso dire quante volte semplici espressioni regolari abbiano convertito i dati che la gente pensava avrebbero impiegato giorni per manipolare. Deve essere presente in ogni toolbox del programmatore.

Certo, non possiamo dimenticare xkcd: Wait, forgot to escape a space. Wheeeeee—taptaptap—eeeeee.

0
neves

Ogni programmatore dovrebbe sapere come funziona un processore.

0
Brian Makin

Be Master of Something, ma Be Consapevole di Tutto !!!!

0
user11020

Ci sono alcuni ottimi suggerimenti qui, ma sono sorpreso che nessuno abbia menzionato l'eccellente serie di articoli di Ulrich Drepper: Cosa ogni programmatore dovrebbe sapere sulla memoria .

0
Mansur

Tutti i problemi in informatica può essere risolto da un altro livello di riferimento indiretto.

0
FreeMemory

Progetta il tuo codice e se il tuo manager vuole usare un RAD prova a ottenere il maggior numero di dettagli possibile. Quindi, quando vengono aggiunte più funzionalità, prova a pensare se il codice esistente può essere riscritto prima accumulando solo più codice e si finisce con un highrise invece di una casa.

0
Luke Tongs

ogni programmatore dovrebbe avere una solida base nell'ingegneria del software e anche concetti di analisi/progettazione del sistema e sistemi di informazione. in questo modo se sono chiamati a contribuire in modo sostanziale all'analisi/progettazione dei sistemi e/o all'architettura dell'informazione, saranno in una posizione di conoscenza + opionion ... mentre normalmente sembra essere solo un'opinione personale che di solito deriva semplicemente da preferenze personali della migliore soluzione al problema. l'ingegneria del software è un po 'più difficile da misurare, ma le conoscenze preliminari sono disponibili là fuori e in corsi di laurea universitari adeguati in cui insegnano più di un semplice modo di mettere insieme un po' di codice. comunque questo non è pensato per essere negativo perché lo spirito principale è solo il miglioramento, ma poi ho lavorato con alcune persone che non hanno alcuna conoscenza IT o ci sono gli "script kiddies" con una sola idea che codificano e ricodificano (e solo in il loro linguaggio preferito) e vedono ogni problema solo come una ripetizione di soluzioni precedentemente applicate (da quel programmatore.) Quindi preferirei di gran lunga se i programmatori si concentrassero di più sull'immagine più ampia in termini di ingegneria del software (SSADM) e vedessero i problemi come opportunità fare meglio per il cliente.

0
chris

Esegui prima il codice o la logica nella tua testa o carta. Non correre per colpire la compilazione ed eseguire il comando per testarlo.

0
Aditya Kothadiya

Si trova in poche lettere, davvero:

Ok, sto semplificando troppo, ma fondamentalmente se sei abbastanza autodidatta, non smetti mai di imparare e sei un po 'perfezionista, dovresti avere le basi per diventare un buon programmatore.

Qualsiasi cosa oltre a ciò sarebbe più specifica per ruoli e tecnologie particolari.

0
haylem

Se qualcosa può andare storto, allora lo farà. Assumi il caso peggiore

0
Adham Saad

Non dimenticare la persona che utilizzerà il software che stai creando.

0
Dan Goldstein

Riconosci che tutto ciò che può andare storto andrà storto. Trascorrere pochissimo tempo a scrivere codice, ma riconoscere e riutilizzare i modelli comuni. Codice refactor costantemente per raggiungere il design ideale.

0
zkarthik

Tutti i dati devono vivere da qualche parte. Puoi trovarlo se guardi abbastanza duro.

0
Jonathan

Devono conoscere il potere delle chiusure e iniziare a usarle.

0
nickik

Notazione esadecimale. Anche campi di bit: ANDing, ORing (inclusivo ed esclusivo), complementare (1 e 2), spostamento dei bit.

0
tcrosley

Il mio primo voto sarebbe per le Convenzioni sui nomi.

0
Gopi

Quando qualcuno ti chiede di costruire qualcosa, ricorda: ti stanno anche chiedendo di mantenerlo. Forse, per sempre.

0
Yevgeniy Brikman

Che qualunque programma facciano, più che dire a una macchina come fare un lavoro, sono un modo molto inequivocabile di mostrare agli altri esseri umani come fare un lavoro.

0
vpit3833