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\u00e0 (o scrivere qualsiasi cosa, in realt\u00e0) per migliorare il loro flusso di lavoro, sei destinato a ricevere feedback, giusto?<\/p>\n
Non fraintendermi. lo accolgo con favore. Penso che aiuti a migliorare la scrittura in futuro (cio\u00e8, chiedo, cosa posso fare meglio).<\/p>\n
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:<\/p>\n
\nil tuo titolo "codice di alta qualit\u00e0" mi ha fatto pompare per alcune cose hardcore, ma amico ~ 99% narrativa vs ~ 1% codice ?? cade morto sulla sua tastiera<\/p>\n<\/blockquote>\n
E lo capisco. C’\u00e8 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.<\/p>\n
Quindi ho pensato che per altri che hanno gli stessi pensieri, potrebbe valere la pena spiegare perch\u00e9 adotto l’approccio che faccio.<\/p>\n
Capire prima di codificare<\/h2>\n
Per essere chiari, niente qui ha lo scopo di individuare qualcuno o qualcosa fuori. Semmai, \u00e8 il mio generalista sull’argomento e perch\u00e9 penso di parlare, scrivere e condividere post su codice di alta qualit\u00e0<\/p>\n
1 Un ossimoro<\/h3>\n
La nostra attuale cultura della programmazione sembra promuovere e perpetuare l’idea di codificare prima e [forse] comprendere poi. Questo mi sembra arretrato.<\/p>\n
Non mi piace la codifica copia e incolla perch\u00e9 il termine \u00e8 un po’ un ossimoro. Non puoi scrivere codice e copiarlo e incollarlo. O \u00e8 l’uno o l’altro.<\/p>\n
Penso che Toby l’abbia menzionato meglio:<\/p>\n
\nil codice di alta qualit\u00e0 non pu\u00f2 essere copiato e incollato da Internet.<\/p>\n<\/blockquote>\n
Penso che sia importante assicurarsi di poter scrivere il codice da soli. E per farlo, dobbiamo avere un po’ di comprensione.<\/p>\n
2 Invito alla comprensione<\/h3>\n
Infine, si chiama codice per un motivo. Nella mia mente, l’ultima cosa di cui dobbiamo preoccuparci \u00e8 il codice stesso.<\/p>\n
Gli strumenti possono aiutare, ovviamente, ma se non capisci gli errori, non puoi migliorare.<\/p>\n
Cio\u00e8, \u00e8 importante capire cosa stiamo cercando di fare e un modo di alta qualit\u00e0 o robusto per fare qualcosa. Pertanto, comprendere i concetti alla base di ci\u00f2 che stiamo facendo \u00e8 pi\u00f9 importante del codice effettivo.<\/p>\n
Perch\u00e9 se non capisci il concetto, non capirai il codice.<\/p>\n
Altri motivi?<\/h2>\n
Al di sopra della mia testa? No, ma questo non significa che non ce ne siano di pi\u00f9.<\/p>\n
Ma se questi sono i tre che mi vengono in mente pi\u00f9 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.<\/p>\n