Migliore risposta
Domanda interessante. Per me il termine “artigianato” implica qualcosa sul modo in cui è scritto il codice effettivo, piuttosto che sulla progettazione del sistema di livello superiore. Direi che un codice ben congegnato fa quanto segue:
- Segue standard esterni
- Segue standard interni
- Utilizza buoni modelli
- È leggibile
Segue standard esterni. Se il tuo gruppo ha standard di codifica, seguili. Se non lo fai ” Mi piacciono gli standard, seguiteli comunque.
Segue gli standard interni. Ciò significa che il codice dovrebbe essere coerente internamente. I metodi che fanno cose simili dovrebbero essere disposti nello stesso modo. Se un metodo segue lo schema:
if (success) {
doSomething();
} else {
handleError();
}
non hanno un altro metodo che inizi:
if (!success)
{
handleError();
Utilizza buoni modelli. Con questo intendo modelli di codifica piuttosto che Design Pattern. Il tuo codice dovrebbe usare idiomi appropriati per il linguaggio. (Usa scoped\_ptrs per la gestione della memoria in C ++, per esempio.) Dovrebbe evitare evidenti inefficienze, come lincremento di iteratori C ++ oggetti che non vengono utilizzati in ogni percorso di codice.
È leggibile. Altri ingegneri leggeranno il tuo codice e tu lo rileggerai tra un anno. Il codice dovrebbe essere il più facile da capire possibile. Tutti gli elementi sopra menzionati riguardano principalmente la leggibilità e la riduzione al minimo di elementi imprevisti nel codice. I tuoi lettori dovrebbero preoccuparsi della logica del tuo codice, non di cercare di capire perché è stato utilizzato un costrutto non standard. Se esiste un costrutto non standard, i tuoi lettori dovrebbero sapere che è lì per un motivo, non perché hai commesso un errore. (Pensa al tuo codice come a un mobile. La superficie dovrebbe essere liscia e non dovresti prendere una scheggia se ci passi sopra la mano. Qualsiasi irregolarità dovrebbe esserci per una ragione.)
La leggibilità è migliorata anche da metodi ragionevoli e nomi di variabili e da commenti appropriati. Non esagerare con i commenti. Se è ovvio, non preoccuparti di spiegarlo. Ma disponi di una sorta di panoramica in modo che il lettore conosca il contesto. (Può essere ovvio che il codice sta trasformando linput X in output Y, ma aiuta se il lettore ha unidea del motivo per cui è necessario.)
Risposta
I gestori sono come bambini piccoli. Vogliono quello che vogliono e lo vogliono ORA ! Ma a differenza dei bambini piccoli, i manager hanno ricordato a metà gli articoli Harvard Business Review che citano (senza fornire riferimenti) per giustificare le loro richieste. Hanno imparato una serie di argomenti che lasciano perplessi alcuni sviluppatori.
Dicono: “Non possiamo permetterci di farlo bene. Dobbiamo scaricarlo nel marketplace ORA ! “. Non è vero, sai. Se mettono rapidamente in produzione il loro codice per gli spaghetti, hanno la possibilità di far incazzare i loro clienti di lancio ora, ma il codice non può essere scalato. Significa solo che la loro attività arranca per un po prima di crollare.
Dicono: “Rilasciamo una versione beta ai nostri clienti di lancio”. Quello che vogliono dire è che vogliono che tu rilasci un codice perfetto e piacevole per il cliente prima di quanto faresti altrimenti, solo perché hanno accettato di chiamarlo un programma di beta test. È un pensiero magico, come credere in Babbo Natale.
Dicono: “Prometto che riscriveremo il codice più tardi se rilasci il tuo codice scadente e incompleto NOW ! ” Non suona come “Pulirò la mia stanza più tardi papà, se posso guardare la TV e mangiare snack zuccherati ORA ?” Il problema è che dopo non arriva mai. Ogni giorno il manager può scegliere se aggiungere nuove funzionalità o pulire la stanza disordinata che è la loro base di codice. Indovina a quale danno la priorità. E indovina un po , la stanza diventa sempre più disordinata, quindi ci vorrà sempre più tempo per ripulire. È anche più difficile lavorare (per creare nuove funzionalità) a causa di tutto il caos.
Alla fine dicono: “Abbiamo investito troppo in questa base di codice. Ci vorrà troppo tempo per riscrivere. Abbiamo bisogno delle funzionalità ORA ! ” Solo ogni funzionalità richiede il doppio o il triplo del tempo per la codifica, a causa del disordine che gli sviluppatori di software chiamano debito tecnico.
I buoni sviluppatori, come i genitori pazienti e amorevoli, devono fermare la follia. Devono insistere fermamente: “Mi dispiace amore, ma il tuo articolo HBR dice:” Entrate prima è meglio, a parità di altre condizioni . “Devi leggerlo con più attenzione.Tutte le altre cose non sono uguali se si accumula un debito tecnico. Che ne dici se diamo la priorità alle funzionalità e forse ci sarà qualcosa da vendere prima. “
Devi essere un adulto e fargli capire che non esiste Babbo Natale e no codice perfetto e gradito al cliente fino a quando tutti i bug non vengono rimossi e tutte le funzionalità non vengono implementate.
Devi dire loro: “Non possiamo permetterci non per utilizzare buone pratiche. Viviamo, o moriamo, ma dobbiamo fare certe cose per vivere, come scrivere test e documentazione. Non è unopzione. “
Devi sorridere e dire:” Non riscriveremo mai questo codice. So che hai buone intenzioni, ma quando si tratta di correggere il codice o aggiungere nuove funzionalità, so cosa dirai. È quello che sempre dici “.
Essendo un genitore fermo, aiuti il tuo manager a crescere fino a diventare il tipo di leader aziendale che tu vorrebbe lavorare per.