I più strani principi di programmazione che non hai mai sentito parlare

Annuncio pubblicitario

Ti abbiamo già guidato attraverso principi di programmazione più essenziali 10 principi di programmazione di base che ogni programmatore deve seguireScrivi sempre il codice che può essere gestito da chiunque possa finire a lavorare sul tuo software. A tal fine, ecco alcuni principi di programmazione per aiutarti a ripulire il tuo atto. Leggi di più devi conoscerlo, ma esiste un'altra classe di principi di programmazione che può essere dimostrata ancora più vantaggioso di quelli.

Considerando che i principi di cui sopra ti insegnano come essere inteligente con il tuo codice, i seguenti principi ti insegneranno ad essere saggio con il tuo codice. Alcuni sono strani e molti sono divertenti, ma sono tutti ugualmente pratici e importanti. Badate!

1. Il principio gonfio

Questo ha così tante varianti che è difficile sceglierne una come principale. Forse la versione più "ufficiale" è la legge dell'involucro del software, più comunemente chiamata Legge di Zawinski, dal nome di Jamie Zawinski e menzionato in L'arte della programmazione UNIX:

“Ogni programma tenta di espandersi fino a quando non può leggere la posta. Quei programmi che non possono espandersi così sono sostituiti da quelli che possono farlo. "

Parla della tendenza dei programmi ad attrarre sempre più funzionalità nel tempo e inevitabilmente alla deriva verso una complessità crescente. Potresti saperlo come strisciamento di funzionalità, che è l'aggiunta continua di nuove funzionalità che non hanno nulla a che fare con lo scopo principale del programma. Lo scorrimento delle caratteristiche porta a gonfiarsi e spesso non è desiderabile.

Questo può valere anche per le prestazioni del software:

"Il software si espande per consumare tutte le risorse disponibili."

Negli anni '90, i dischi rigidi, le CPU e la RAM erano molto più restrittivi di quanto lo siano oggi e i programmatori hanno lavorato duramente per adattarsi il più possibile ai limiti. Eppure ora che abbiamo unità più grandi, CPU più veloci e più RAM, facciamo ancora fatica a rispettare i limiti. Tutto si gonfia nel tempo. È tuo compito tenerlo sotto controllo.

2. La mentalità "peggio è meglio"

Quasi come in risposta al principio Bloat, abbiamo il Peggio è una mentalità migliore, coniato per la prima volta da Richard P. Gabriel in un saggio ha scritto sulla qualità del software:

"Il software che è limitato, ma semplice da usare, può essere più attraente per l'utente e il mercato rispetto al contrario."

In altre parole, è saggio capire il un problema il tuo software mira a risolvere e poi essere molto bene a quell'unica cosa. Mantienilo semplice. Più ti diverti, più ingestibile diventa il progetto e più diventa indesiderabile per gli utenti.

Cosa succede quando lo ignori? Si finisce con il Software Peter Principle:

"Un progetto troppo complesso alla fine diventerà troppo complesso per essere compreso anche dai suoi stessi sviluppatori."

Viene dal più ampio principio Peter, che afferma che quando i dipendenti vengono promossi in base alla loro attuale competenza e non la competenza prevista nella loro prossima posizione, tutti i dipendenti alla fine finiscono in una posizione di incompetenza. Prendi questo principio e applicalo al software e vedrai perché un software peggiore può spesso essere migliore.

3. La legge di Eagleson

"Qualsiasi codice che non hai guardato per sei o più mesi potrebbe anche essere stato scritto da qualcun altro."

Questo detto apparentemente demotivazionale è in realtà qualcosa da abbracciare. Il fatto è che nessuno è perfetto. Potresti pensare di essere un geniale programmatore in questo momento, ma c'è sempre qualcosa in più che puoi imparare, sempre più spazio per crescere. Se ripensi al vecchio codice e al limite, probabilmente significa da allora hai imparato qualcosa di nuovo.

Detto in altro modo: se guardi indietro a un vecchio progetto e non riesci a vedere nulla che puoi migliorare o fare diversamente la prossima volta, probabilmente rimani stagnato come programmatore.

4. Principio del minimo stupore

"Se una funzione necessaria ha un elevato fattore di stupore, potrebbe essere necessario ridisegnare la funzione."

Pubblicato per la prima volta nel IBM Systems Journal nel 1984, questo principio è ancora sorprendentemente rilevante oggi, forse più che mai.

Tocca essenzialmente il delicato equilibrio tra innovazione e familiarità: se lo è un software troppo diverso da altri nel suo genere e non conforme alle aspettative degli utenti, quindi probabilmente non lo adotteranno. È meglio cercare miglioramenti incrementali che siano abbastanza grandi da essere impressionanti ma abbastanza piccoli da rimanere familiari.

5. Legge dell'entomologia cibernetica

"C'è sempre un altro bug."

Chiamato spesso Legge di entomologia cibernetica di Lubarsky, non è chiaro chi sia realmente questo Lubarsky. Tuttavia, il suo principio suona vero per tutti i programmatori: non importa quanto tu scriva il tuo codice in modo pulito, non importa come testando i moduli in modo affidabile, indipendentemente dalla frequenza con cui si esegue il refactoring delle classi, ci sarà sempre un altro bug.

In un certo senso, questo è un principio di liberazione. Mentre dovremmo assolutamente lottare per un codice privo di bug, è anche importante ricordare che il perfezionismo è nemico del bene. Cerca i bug, correggili quando si presentano e poi vai avanti.

6. Legge di Kernighan

"Il debug è due volte più difficile della scrittura del codice in primo luogo. Pertanto, se scrivi il codice nel modo più intelligente possibile, per definizione, non sei abbastanza intelligente da eseguirne il debug. "

Brian Kernighan, lo stesso autore la bibbia del linguaggio di programmazione C. Perché vale ancora la pena imparare la programmazione C.C non è una lingua morta. In effetti, la rivista IEEE Spectrum l'ha classificata come la migliore lingua n. 2 nel 2017. Ecco cinque motivi per cui. Leggi di più , è famoso per questa legge perspicace. Il punto cruciale è questo: scrivere bene codice, scrivi leggibile codice, scrivi semplice codice, qualsiasi cosa purché non lo sia intelligente codice.

Cercare di flettere i muscoli di programmazione con la complessità della torre d'avorio è esattamente l'opposto di ciò che significa scrivere codice pulito e migliore 10 suggerimenti per scrivere codice più pulito e miglioreScrivere codice pulito sembra più facile di quanto non sia in realtà, ma i vantaggi ne valgono la pena. Ecco come puoi iniziare a scrivere codice più pulito oggi. Leggi di più . Più difficile sarà capire il tuo codice, più sarà difficile eseguire il debug quando si romperà inevitabilmente.

E come Robert C. Martin spiega, non si tratta nemmeno di debug:

“In effetti, il rapporto tra il tempo trascorso a leggere e la scrittura è ben oltre 10 a 1. Leggiamo costantemente il vecchio codice come parte dello sforzo di scrivere nuovo codice... [Pertanto,] facilitando la lettura semplifica la scrittura. "

7. Rubber Duck Debugging

Questo non è tanto un principio in quanto è una tecnica, ma è così utile e strano che ci sarebbe negato lasciarlo fuori.

Prima raccontato Il programmatore pragmatico, debugging di paperelle di gomma è quando esegui il debug del software rotto spiegando il tuo codice a un oggetto inanimato (ad esempio un'anatra di gomma) una riga alla volta. Funziona perché l'atto di spiegazione innesca diverse parti del tuo cervello e hai maggiori probabilità di individuare incoerenze e capire dove hai sbagliato.

Per questo motivo, un'anatra di gomma può essere un regalo sorprendentemente elegante per i programmatori I migliori regali Geek per programmatori: 20 idee per programmatori e nerdAlla ricerca di un regalo per un programmatore? Ecco i migliori regali geek, che vanno dalle tastiere meccaniche alle scrivanie in piedi e altro ancora. Leggi di più , che tu lo acquisti per te stesso o per un tuo compagno di programmazione.

8. La regola del novanta-novanta

"Il primo 90 percento del codice rappresenta il primo 90 percento dei tempi di sviluppo. Il restante 10 percento del codice rappresenta l'altro 90 percento del tempo di sviluppo. "

Questo piccolo proverbio sfacciato di Tom Cargill è al centro del perché la programmazione può essere così frustrante: non importa quanto pensi di essere vicino alla fine, sei molto più lontano anche delle tue migliori stime. Quando pensi di aver finito, sei solo a metà strada.

Va di pari passo con la legge di Hofstadter:

"Ci vuole sempre più tempo del previsto, anche quando si tiene conto della legge di Hofstadter".

9. Legge del Parkinson

"Il lavoro si espande in modo da riempire il tempo disponibile per il suo completamento."

Questo principio, coniato da Cyril Northcote Parkinson, è un principio più ampio che si applica assolutamente alla programmazione e va mano nella mano con la Regola del novantanovanesimo di cui sopra: per quanto tempo si debba finire un progetto, è esattamente quanto durerà prendere. Nello sviluppo del software, "finire presto" è praticamente un mito.

La legge di Parkinson è il motivo per cui le scadenze corrette sono cruciali se si desidera completare e spedire il software. Ecco perché spesso raccomandano i moderni programmatori professionisti principi di gestione del progetto agili Come utilizzare i principi di gestione dei progetti Agile per organizzare la tua vitaAgile, meglio noto come metodo di gestione del progetto, è un ottimo framework per gestire la tua vita personale. Ti mostreremo quali principi puoi prendere in prestito - download gratuito del foglio di lavoro incluso! Leggi di più e strumenti di gestione del progetto come Asana Trello vs. Asana: il miglior strumento gratuito di gestione dei progetti è ...Scegliere tra Trello e Asana è difficile. Qui confrontiamo i piani gratuiti e ti aiutiamo a decidere quale strumento di gestione del progetto è il migliore per il tuo team. Leggi di più .

10. Legge di Brook

"L'aggiunta di manodopera a un progetto software in ritardo lo rende più tardi."

La prossima volta che sei in ritardo su un progetto, il che è probabilmente poiché la maggior parte dei progetti di programmazione richiede più tempo di quanto assegnato, ricorda che l'aggiunta di programmatori non lo risolverà più velocemente.

In effetti, probabilmente ci vorrà più a lungo completare. Non solo devi velocizzare i nuovi programmatori, ma probabilmente si scontreranno con i programmatori esistenti. Dovranno essere documentate più cose, più burocrazia sarà necessaria per mantenere tutti sulla stessa pagina e più attrito verrà fuori dall'intera esperienza crunch-time.

Andare avanti come programmatore

Ora che conosci questi principi, in realtà sei più adatto a mondo reale di programmazione, non solo quello che hai incontrato a scuola, in un corso web o in un campo di addestramento. Questi principi derivano da anni e anni di esperienza e fallimenti.

Con questa nuova saggezza, ora puoi iniziare a carriera di programmazione molto richiesta 10 lavori di programmazione informatica che sono richiesti in questo momentoDal momento che l'atterraggio di un lavoro di programmazione può essere difficile nel panorama attuale, considera di concentrarti su una delle seguenti concentrazioni per migliorare le tue possibilità di successo. Leggi di più con aspettative più realistiche. Per questo, impara come massimizzare le opportunità di carriera di programmazione Come migliorare le opportunità di carriera di programmazioneSe speri di iniziare, riavviare o migliorare la tua carriera di programmazione, non è facile. Se sei al college, adesso è il momento. Ecco alcuni suggerimenti che possono portarti lontano. Leggi di più . E se decidi che la programmazione non fa per te, non preoccuparti: prendi in considerazione uno di questi invece lavori tecnologici non codificanti La programmazione non è per tutti: 9 lavori tecnici che puoi ottenere senza di essaNon scoraggiarti se vuoi far parte del campo tecnologico. Ci sono molti lavori per le persone senza capacità di programmazione! Leggi di più .

Quale di questi principi ti sembra più vero? Conosci altri strani principi di programmazione che ci siamo persi? Facci sapere nei commenti qui sotto!