È capire prima di codificare
Ogni volta che miri a scrivere un blog su una serie di cose diverse che cercano di aiutare le persone a scrivere codice di qualità (o scrivere qualsiasi cosa, in realtà) per migliorare il loro flusso di lavoro, sei destinato a ricevere feedback, giusto?
Non fraintendermi. lo accolgo con favore. Penso che aiuti a migliorare la scrittura in futuro (cioè, chiedo, cosa posso fare meglio).
E a rischio di sembrare come se stessi "chiamando qualcuno" (cosa che non sono), voglio condividere un tweet [non attribuito] che ho ricevuto la scorsa settimana:
il tuo titolo "codice di alta qualità" mi ha fatto pompare per alcune cose hardcore, ma amico ~ 99% narrativa vs ~ 1% codice ?? cade morto sulla sua tastiera
E lo capisco. C’è pochissimo codice in un post che mira a parlare di codice. Ma ci sono ragioni per questo, e deriva da alcuni anni di lettura di articoli, scrittura di articoli, lettura di codice e scrittura di codice.
Quindi ho pensato che per altri che hanno gli stessi pensieri, potrebbe valere la pena spiegare perché adotto l’approccio che faccio.
Capire prima di codificare
Per essere chiari, niente qui ha lo scopo di individuare qualcuno o qualcosa fuori. Semmai, è il mio generalista sull’argomento e perché penso di parlare, scrivere e condividere post su codice di alta qualità
1 Un ossimoro
La nostra attuale cultura della programmazione sembra promuovere e perpetuare l’idea di codificare prima e [forse] comprendere poi. Questo mi sembra arretrato.
Non mi piace la codifica copia e incolla perché il termine è un po’ un ossimoro. Non puoi scrivere codice e copiarlo e incollarlo. O è l’uno o l’altro.
Penso che Toby l’abbia menzionato meglio:
il codice di alta qualità non può essere copiato e incollato da Internet.
Penso che sia importante assicurarsi di poter scrivere il codice da soli. E per farlo, dobbiamo avere un po’ di comprensione.
2 Invito alla comprensione
Infine, si chiama codice per un motivo. Nella mia mente, l’ultima cosa di cui dobbiamo preoccuparci è il codice stesso.
Gli strumenti possono aiutare, ovviamente, ma se non capisci gli errori, non puoi migliorare.
Cioè, è importante capire cosa stiamo cercando di fare e un modo di alta qualità o robusto per fare qualcosa. Pertanto, comprendere i concetti alla base di ciò che stiamo facendo è più importante del codice effettivo.
Perché se non capisci il concetto, non capirai il codice.
Altri motivi?
Al di sopra della mia testa? No, ma questo non significa che non ce ne siano di più.
Ma se questi sono i tre che mi vengono in mente più facilmente, allora trovo che di solito siano i migliori motivi per un determinato approccio. Questo non significa che l’approccio sia giusto, ma almeno sono giustificati.