Cosa consideri il 1o principio / i di programmazione?

Mi è sempre piaciuto chiedermi "qual è il primo (i) principio (i) di questo?" dopo aver appreso le cose basilari di qualcosa (es. programmazione). È una domanda stimolante, IMO, che può costringerti a pensare ai principi più importanti dietro qualcosa, in particolare un'abilità come la programmazione.

Quindi, quali pensi siano i primi principi della programmazione? Darò la mia risposta di seguito un po 'più tardi.

1. BACIO - Keep It Simple Stupid
2. ASCIUTTO - Non ripetere te stesso
3. YAGNI - Non ne avrai bisogno

Scrivi codice come se fossi tu che dovresti mantenere quel codice.

Sii il più pigro possibile.

Zen, parte I: la programmazione è solo la strada, non la strada.

La programmazione è solo la tecnica per insegnare a un computer cosa deve fare. Avere successo nella creazione di software veloce e affidabile significa conoscere i tuoi algoritmi, le migliori pratiche e tutte le altre cose non necessariamente connesse alla tua Programmazione (linguaggio).

Zen, parte II: se hai fretta, cammina lentamente. Se hai davvero fretta, fai una deviazione.

Sembra sciocco, ma non lasciarti scendere a compromessi che (davvero) potrebbero disturbarti in seguito. Ho una regola: se sei al centro di un programma, cerca di essere il più preciso e buono possibile. Se stai utilizzando metodi basati sul core che sono profondi nel tuo software, prova ad essere più veloce nella codifica. Se stai codificando sopra questi due, puoi anche ottenere un po 'più sciatto.

Gli errori di progettazione sono i più difficili da trovare e / o correggere, il passo successivo sono gli errori di programmazione in parti su cui tutti fanno affidamento, quindi le "parti reali del software in mostra". Se devi correggere un errore di progettazione alla fine di un progetto, ummm, non va bene ... ;-)

Zen, parte III: Conosci il tuo percorso, Neo.

Conosci il tuo ambiente, gli strumenti e le cose su cui fai affidamento su base giornaliera e ordinali in modo che funzioni per te. Meglio se usi il tuo "ambiente" di programmazione così naturale che non devi nemmeno pensarci. Se devi fare un lavoro, non introdurre "cose ​​fantasiose" ma fai il tuo lavoro. Questo materiale può essere introdotto in un nuovo progetto, in particolare quando hai tempo per prepararlo e utilizzarlo.

BACIO (mantienilo semplice, stupido).

Pone davvero la domanda "Come si definisce semplice?" E anche "Quando è qualcosa di troppo semplice per l'attività a portata di mano?" Ecco perché non puoi diventare un buon programmatore solo conoscendo il primo principio di programmazione.

L'ottimizzazione prematura è la radice di tutti i mali. - Donald Knuth

Non reinventare la ruota.

Comprendi prima il problema!

YAGNI - Non ne avrai bisogno . L'idea alla base di YAGNI è programmare per le vostre esigenze, non per potenziali funzionalità potenziali. La premessa è che, attenendosi a ciò che è necessario programmare, (tra le altre cose) si taglierà il bloat del codice, si ridurrà la complessità, si eviterà lo scorrimento delle funzionalità e si ridurranno le restrizioni su cosa si può fare (e come si può fare) nel futuro.

Suppongo che funzioni in tandem con un design modulare: le funzionalità future possono essere aumentate senza riprogettare il codice esistente.

Sapere quando non programmare.

Caffè in, codice fuori.

Se non è stato testato, è rotto.

Esistono due modi per costruire un progetto software: un modo è renderlo così semplice che non ci siano ovviamente carenze e l'altro è renderlo così complicato che non ci sono carenze evidenti. Il primo metodo è molto più difficile.

- Charles Antony Richard Hoare

1. Distinguere tra causa ed effetto (lavorare con i computer)

2. Distinguere tra fatto e opinione (lavorare con le persone)

3. Il più semplice possibile, ma non più semplice (design)

La programmazione è un mezzo non un fine. O forse, "Can non significa dovrebbe".

1. Comprendi perché il programma renderà felice qualcuno (altrimenti, perché non sei fuori a giocare con tutti gli altri bambini?). (Questa persona puoi essere tu.)
2. Sviluppa un modello concettuale del dominio aziendale che catturi tutta la complessità necessaria e non di più.
3. Sviluppa un modello concettuale dell'architettura software che catturi tutta la complessità necessaria e non di più.
4. Tenere spietatamente ogni altra complessità fuori.

Secondo me, il principio più importante è la riduzione della complessità attraverso la creazione di buone astrazioni .

Ciò comprende

• capire il problema da risolvere,
• progettando una soluzione adeguata per esso e
• implementandolo,
• preferibilmente in un modo che mantenga il codice comprensibile e mantenibile,

ma anche la determinazione del punto in cui smettere di creare astrazioni e scendere alle proprietà fondamentali delle tecnologie di implementazione (ad es. sistema di database, linguaggio di programmazione) per impedire la creazione di ulteriori complessità evitabili.

Programma pensando a un pubblico. Con ciò, non dare per scontato che tutto ciò che scrivi non verrà letto e gestito da te o da qualcun altro.

A corollario di ciò: dimostra di aver compreso il problema che stai cercando di risolvere nominando bene variabili, funzioni e classi!

non funziona finché non lo hai mostrato in un test

Pensa prima, codifica più tardi.

Non sei affatto intelligente come pensi di essere. Fare domande. Impara a valorizzare i tuoi colleghi.

Durante il debug, la prima risposta sarà quasi sempre sbagliata.

Il codice che scrivi con l'intenzione di lanciare tende a diventare una pietra angolare di processi molto più grandi. Non lasciare mai nulla di scritto a casaccio.

Qualsiasi problema può essere risolto con un altro livello di riferimento indiretto.

Conosci i tuoi strumenti.

Principio: il software è acquisizione della conoscenza .

Conseguenze: molte tecniche per la rappresentazione della conoscenza, tutte basate sull'astrazione . Ci fornisce livelli, livelli, incapsulamento, separazione delle preoccupazioni.

Molte tecniche per la rappresentazione di procedure, tutte basate su sequenza , scelta , ripetizione .

Scrivi il codice per il prossimo.

Scrivi sempre il codice come se la persona che lo manterrà fosse un serial killer psicotico che sa dove vivi

Inoltre, non pensare mai di sapere tutto sulla programmazione, continua ad imparare

Ho iniziato a programmare studiando elettronica digitale, quindi immagino che le porte logiche di base (e non, e, o, xor, implicino) siano state i primi principi di programmazione.

Riguarda l'utente.

Garbage in - Garbage Out Non importa quanto sia bella l'interfaccia utente se i dati non sono corretti.

SECCO, praticamente tutto il resto ne deriva. KISS è l'altra estremità dell'atto di bilanciamento per assicurarsi di non perseguire l'eleganza del software a livelli di follia.

Inizia con l'output e procedi all'indietro.