Lo strumento di programmazione più sottovalutato [chiuso]

Un'anatra di gomma. Sì, davvero.

link

Rubber duck debugging, rubber ducking, and the rubber duckie test are informal terms used in software engineering to refer to a method of debugging code. The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

To use this process, a programmer explains code to an inanimate object, such as a rubber duck, with the expectation that upon reaching a piece of incorrect code and trying to explain it, the programmer will notice the error. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent...

Penna e taccuino.

1. Funziona senza elettricità.
2. Portable.
3. Doodle su / in quando è annoiato nelle riunioni
4. Memorizza informazioni utili.
5. Se è trascritto, le persone attribuiscono più importanza ad esso.
6. Gli altri possono leggerlo e imparare.

Strumenti di diffusione sembrano essere poco usati quando si confrontano output di log o dati in file di testo flat. O forse è solo una nicchia? Mi sembra che sia molto utile e utile per il debug per confrontare enormi registri di esecuzioni di programmi e individuare uno o due dettagli che sono cambiati.

Gli strumenti di profilazione delle prestazioni sono anche molto buoni da avere, specialmente quando si colpisce un punto critico del bottelneck, ma sembra che poche persone abbiano familiarità con loro (e ammetto di essermi laureato in questa categoria) .

I buoni strumenti XML sono fondamentali: se lavori con file XML più di una dozzina di righe o schemi multipli. A volte è necessario qualcosa di più della semplice sintassi di base che evidenzia gli altri editor. Anche quando si lavora con XML, l'apprendimento dell'XSL può essere molto utile. Molte volte vedo cosa si può fare in una semplice trasformazione XSL fatta in molte righe nel codice dell'applicazione. Per chiarire: io non suggerisco che XML stesso è uno "strumento di programmazione sottovalutato"; Sto suggerendo che il valore di buoni editor XML è sottostimato, da quello che ho visto.

Espressioni regolari

Sono così utili. Aiutano durante la ricerca attraverso i file di registro, l'analisi del testo, ecc. Sono estremamente utili.

Trovo strano quante persone conosco che non le usano mai perché c'è un po 'di una curva di apprendimento ad esse associata. Un sacco di volte vedo le persone fare le cose nel modo più duro (Nota: prima delle espressioni regolari ho fatto le cose nel modo più duro) quando una semplice espressione regolare poteva farlo rapidamente.

I tuoi compagni di squadra. Quando sei fuori da un'idea hot-shot e dimentichi di incorporare la tua squadra, non sentirai mai le loro preoccupazioni o idee per il motivo per cui non funzionerà o perché potrebbe essere ancora meglio.

Dico questo, perché è facile pensare che la programmazione sia una cosa antisociale che le persone fanno alle spalle con le loro idee brillanti. Le persone che pensano che questo sottostimi il valore delle squadre e dei loro compagni di squadra nell'aiutare a far affondare / nuotare idee / progetti.

Google. Ci sono pochissimi problemi che non sono già stati risolti e documentati. Una query Google ben sintonizzata può far risparmiare a tutti un sacco di tempo.

Lo strumento più sottovalutato per la ricerca di "colli di bottiglia" è Ctrl + C o il pulsante "Pausa", in un debugger.

Controlla l'ultimo paragrafo di questo post e questo post e questo post , per i principianti.

Così tante volte vedo / sento gente che dice "Il programma è troppo lento! Cosa posso fare?" Ho provato un profiler (se l'hanno fatto), ma non capisco cosa dice. ? Aiuto!" Bene, le ipotesi sono solo questo. Quello che ho sempre fatto, e anche altri lo hanno fatto, è andare avanti, interromperlo ed esaminare lo stack delle chiamate. Se il problema è veramente brutto, bingo , è proprio di fronte a te. Se il problema è solo lieve, lo fai più volte. Tutto ciò che appare su più di un campione, che puoi evitare, è un collo di bottiglia che puoi correggere.

Sì, questo è downvote-bait, ma funziona.

What type of programming tool do you think is the most underestimated one? Motivate your answer.

Il compilatore.

La maggior parte delle persone non prende tempo per capire cosa fa il compilatore di scelta. Sentono solo che rende il codice un programma eseguibile e questo è il massimo. Nella maggior parte dei moderni, ci sono diverse configurazioni che puoi inserire in esso, facendo in modo che faccia ciò che ti serve. Ecco un esempio, scommetto che metà degli sviluppatori del tuo ufficio non hanno idea di come impostare l'avviso come livello di errore (supponendo che ne abbia effettivamente uno). Quali opzioni devi fare per emettere i simboli di debug? Quali ottimizzazioni (o quale livello di) vuoi che faccia. L'elenco continua.

Il tuo cervello. Altri strumenti non avrebbero molto significato senza di esso.

Buon vecchio:

print

A volte è utile un debugger o un profiler o un diagramma di flusso UML. E a volte ti fanno impazzire. Mi ritrovo sempre a ricorrere alle istruzioni di stampa (o traccia o NSLog o what-have-you) solo per assicurarmi che il mio codice stia facendo quello che penso stia facendo quando penso che lo stia facendo.

Semplici vecchi script ... indipendentemente da quanti linguaggi di nuova generazione sviluppiamo, facciamo ancora molto affidamento sugli script, inoltre la maggior parte delle attività quotidiane possono essere raggiunte scrivendo poche righe di script.

Penna e lavagna.

Non puoi battere il low tech quando cerchi di spiegare qualcosa.

ack . È come grep -r , ma è progettato per la ricerca del codice sorgente.

Perl e altri linguaggi di scripting. Ottimo per le attività che sono un po 'troppo complicate per gli strumenti della GUI come Agent Ransack.

Tasti di scelta rapida che consentono un refactoring rapido, frequente e sicuro. Imparare come estrarre (o inline ecc) le variabili, i metodi, le costanti o le classi alla pressione di alcune chiavi ha cambiato radicalmente il modo di codificare. Rifletterai solo frequentemente (cioè abbastanza) quando il costo è minimo, quindi rendere queste scorciatoie una seconda natura è essenziale per scrivere e mantenere un buon codice per quanto mi riguarda.

Quindi, in generale, usa buoni strumenti (IDE / editor) e impara come ottenere il massimo dalle funzionalità che forniscono.

Il test dell'unità e TDD vengono dopo, per mantenere il tuo codice testabile e prevenire la paura di refactoring.

Usa questi e ti sposterai facilmente verso la scrittura di un codice manutenibile corretto conforme al principio di DRY e che è auto-documentante.

Test delle unità offre i seguenti vantaggi:

• Gli sviluppatori diventano i primi clienti del codice. Più velocemente viene catturato un bug, meno costoso è riparare. I bug possono essere intercettati prima di una compilazione, installazione o distribuzione .
• Test cambia la tua prospettiva sul codice. Il design è chiaro? Gestisce casi d'angolo?
• L'effetto Hawthorne migliorerà la qualità, semplicemente annunciando che un team pubblica metriche di qualità / test.
• Anche se i test non vengono controllati nel controllo del codice sorgente, possono essere un ottimo modo per esplorare e imparare nuovi terreni.
• Un'alta probabilità di un numero inferiore di bug!

Generatori di codice

I generatori di codice possono creare una grande quantità di codice efficiente e privo di bug da una semplice definizione. Gli ORM tipi di utilizzo sono i più ovvi per la creazione di classi di accesso ai dati, ma ci sono molti altri potenziali usi.

Il supporto alla generazione di codice sembra essere ancora agli albori dal punto di vista del programmatore e del framework, ma credo che sia qualcosa che vedremo sempre di più. In .NET puoi iniziare a dilettarti con CodeDOM roba.

Uso pesantemente AgentRansack . È un enorme aiuto cercare rapidamente tra migliaia di file. Mi ha salvato così tanto tempo, ma non conosco molti programmatori che lo conoscono o lo usano.

Metodi formali.

link

link

È difficile esagerare la loro importanza. Ogni loop e ogni istruzione if inizia come un'idea che richiede una sorta di "prova". La maggior parte dei programmatori fa questa prova per la maggior parte del tempo nelle loro teste. Chiedete cosa fa la dichiarazione if e possono articolare - in modo corretto e logico - quali sono le scelte e perché le scelte sono complete, coerenti ed esclusive.

Ma alcuni sembrano solo indovinare a caso. Hanno bisogno di più aiuto e i metodi formali potrebbero essere il tipo di aiuto di cui hanno bisogno.

È solo algebra (e calcolo) per il codice. Niente di troppo complesso o sofisticato.

Modelli di design fisici come lasciare la sedia per una corsa veloce alla luce del sole e aria fresca per mantenere il cervello al massimo della bellezza.

Bene, è Half Life 2 (inserisci qui il tuo gioco preferito). Se ho un problema che non riesco a risolvere, mi chiudo e inizio a giocare con il mio gioco preferito e all'improvviso mi viene in mente la soluzione. Quindi, ad essere onesti, non è un gioco o qualcosa del genere ma fare qualcos'altro . Vedo spesso persone sedute su un problema per ore senza risolverlo e tutto ciò che dovrebbero fare è mettere il cervello offline per un breve periodo.

Overflow dello stack - aiuto rapido di esperti quando sei bloccato

question and answer site for professional and enthusiast programmers. It's built and run by you as part of the Stack Exchange network of Q&A sites. With your help, we're working together to build a library of detailed answers to every question about programming...

Penso che sia Blocco note / TextPad / semplici programmi di modifica del testo. Ognuno ha un momento in cui ha bisogno di una soluzione rapida che non richiede l'apertura di un IDE e richiede solo una rapida modifica. E tutti i computer hanno una sorta di semplice programma di modifica del testo.

Assert e buona funzione alwaysAssert() . Questi sono più importanti dei test unitari, perché i test unitari possono trovare bug solo nei casi specifici che si pensava di testare. Se lo stesso programmatore scrive il codice e i test, probabilmente mancheranno gli stessi casi limite in entrambi. Inoltre, a volte il collaudo di unità è poco pratico perché l'ambiente in cui funziona il componente e / oi dati su cui opera è troppo complicato per trovare un caso di prova inventato.

La bellezza delle affermazioni sta nella loro capacità di documentare le ipotesi e testarle su input non-forzati . Se qualcuno di questi presupposti è sbagliato, il tuo codice non funziona a voce alta invece di "funzionare", ma produce risultati leggermente errati. Inoltre fallisce più vicino alla radice del problema di quanto sarebbe senza le affermazioni. In pratica, se dichiari esplicitamente sufficienti ipotesi su un pezzo di codice e tutte queste ipotesi sono corrette, il codice è in genere corretto.

Un problema comune è che possono essere disattivati. IMHO ogni lingua o libreria standard dovrebbe avere una funzione alwaysAssert() o equivalente approssimativo che fa la stessa cosa di assert ma non può essere disattivata. Questo può essere usato per controllare ipotesi in aree critiche di codice non performanti, dove i benefici derivanti dalla disattivazione degli asserti sono trascurabili.

Il tasto F1. - Utile per programmi che non conosci e per i programmi su cui stai lavorando. (Supponendo che sia un'applicazione di grandi dimensioni.)

Potente filtrare i problemi in cui gli utenti segnalavano bug in base alla loro interpretazione di come il software dovrebbe funzionare. Certo, potrebbe essere che il design stesso fosse difettoso. Ma questa è un'altra storia.

Varie utilità principali UNIX, ma principalmente find e occasionalmente grep o ed . La capacità di trovare le cose in nidi profondi di file è inestimabile, in particolare quando si eredita improvvisamente un codebase e si deve risolvere il problema. Anche se detto codice è ben documentato, probabilmente dovrai cacciare e una strong comprensione di find lo uccide.

Curiosità

Chiamalo "l'enigma della programmazione". Che cos'è uno strumento rispetto alla persona che lo esercita? Il desiderio di sapere come e perché qualcosa fa o non funziona espande la propria conoscenza più di qualsiasi strumento specifico e questo è vero oltre alla programmazione.

Ctrl + C    
Ctrl + V

Ha salvato innumerevoli ore in tutto il mondo!

Tail

Tail può essere usato per monitorare il file di output del log del programma in tempo reale. È stato di grande aiuto nello sviluppo di sistemi che non forniscono altri mezzi per leggere il registro.

Programmi di esempio sono;

• coda per Unix.
• coda per Mac.
• BareTail per Windows.

Ho riunito un generatore di grafici per le chiamate Perl una volta. È stato estremamente utile, ma è caduto duro sul codice non procedurale o sulle routine out-of-file.