Cel mai bun răspuns
Întrebare interesantă. Pentru mine, termenul „măiestrie” implică ceva despre modul în care este scris codul real, mai degrabă decât despre proiectarea sistemului de nivel superior. Aș spune că codul bine elaborat face următoarele:
- Urmărește standardele externe
- Urmează standardele interne
- Folosește modele bune
- Este lizibil
Urmează standardele externe. Dacă grupul dvs. are standarde de codare, urmați-le. Dacă nu faceți acest lucru ” Îți plac standardele, urmează-le în continuare.
Urmează standardele interne. Aceasta înseamnă că codul ar trebui să fie consecvent intern. Metodele care fac lucruri similare ar trebui prezentate în același mod. Dacă o metodă urmează modelul:
if (success) {
doSomething();
} else {
handleError();
}
nu aveți o altă metodă care începe:
if (!success)
{
handleError();
Utilizează modele bune. Prin aceasta mă refer la modele de codificare mai degrabă decât la modele de proiectare. Codul dvs. ar trebui să utilizeze expresii adecvate limbii. (Utilizați scoped\_ptrs pentru gestionarea memoriei în C ++, de exemplu.) Ar trebui să evite ineficiențele evidente, cum ar fi iteratorii C ++ postincrementare sau crearea obiectele care nu sunt utilizate în fiecare cale de cod.
Este lizibil. Alți ingineri vă vor citi codul și veți reciti peste ani. Codul ar trebui să fie cât mai ușor de înțeles. Toate articolele menționate mai sus se referă în primul rând la lizibilitate și la minimizarea elementelor neașteptate din cod. Cititorii dvs. ar trebui să fie preocupați de logica codului dvs., nu de încercarea de a afla de ce a fost utilizată o construcție non-standard. Dacă există o construcție non-standard, cititorii dvs. ar trebui să știe că este acolo pentru un motiv, nu pentru că ai greșit. (Gândiți-vă la codul dvs. ca la o piesă de mobilier. Suprafața ar trebui să fie netedă și nu ar trebui să prindeți o așchie dacă treceți mâna peste ea. Orice neregulă ar trebui să existe acolo dintr-un motiv.)
Citibilitatea este, de asemenea, îmbunătățită prin metode sensibile și nume de variabile și prin comentarii adecvate. Nu treceți peste bord la comentarii. Dacă este evident, nu te deranja să-l explici. Dar aveți un fel de imagine de ansamblu, astfel încât cititorul să cunoască contextul. (Poate fi evident că codul transformă intrarea X în ieșirea Y, dar ajută dacă cititorul are o idee de ce este necesar acest lucru.)
Răspuns
Managerii sunt ca copii mici. Vor ceea ce vor și vor ACUM ! Dar, spre deosebire de copiii mici, managerii și-au amintit pe jumătate de articolele divizate de Harvard Business Review pentru a-și justifica cererile. Au învățat un set de argumente care împiedică unii dezvoltatori.
Ei spun: „Nu ne putem permite să ne permitem să o facem corect. Trebuie să-l obținem pe piață ACUM ! ”. Nu este adevărat, știi. Dacă își lansează codul de spaghete în producție, au șansa de a-și supăra clienții de lansare acum, dar codul nu se poate extinde. Înseamnă doar că afacerea lor se răstoarnă pentru o vreme înainte de a se prăbuși.
Ei spun: „Vom lansa o versiune beta pentru clienții noștri de lansare”. Ceea ce vor să spună este că vor să elibereze un cod perfect, plăcut clienților mai devreme decât ați face altfel, doar pentru că au fost de acord să-l numească un program de testare beta. Este o gândire magică, cum ar fi să crezi în Moș Crăciun.
Ei spun: „Îți promit că vom rescrie codul mai târziu dacă îți eliberezi codul tău, jumătate terminat div> ACUM ! ” Nu sună ca „Îmi voi curăța camera mai târziu tată, dacă pot să mă uit la televizor și să mănânc gustări cu zahăr ACUM ?” Problema este că mai târziu nu vine niciodată. În fiecare zi, managerul are posibilitatea de a adăuga fie funcții noi, fie de a curăța camera murdară care este baza codului lor. Ghici căruia îi dau prioritate. Și ghici ce, camera devine din ce în ce mai dezordonată, astfel încât să dureze din ce în ce mai mult pentru curățare. Este mai greu să lucrezi (pentru a crea funcții noi) și din cauza tuturor dezordinilor.
În cele din urmă, ei spun: „Am investit prea mult în această bază de cod. Va dura prea mult timp pentru a rescrie. Avem nevoie de funcții ACUM ! ” Numai fiecare caracteristică durează de două sau trei ori mai mult timp pentru codificare, din cauza camerei dezordonate pe care dezvoltatorii de software o numesc datorii tehnice.
Dezvoltatorii buni, precum părinții răbdători și iubitori, trebuie să oprească nebunia. Trebuie să insiste ferm: „Ne pare rău, iubire, dar articolul dvs. HBR spune:„ Venitul mai devreme este mai bun, toate celelalte lucruri fiind egale . Trebuie să-l citiți mai atent.Toate celelalte lucruri nu sunt egale dacă acumulezi datorii tehnice. Ce zici dacă prioritizăm funcțiile și poate că vei avea ceva de vândut mai devreme. ”
Trebuie să fii adult și să le spui că nu există așa ceva ca Moș Crăciun și nu un cod perfect, plăcut pentru clienți, până când toate erorile sunt eliminate și toate caracteristicile sunt implementate.
Trebuie să le spuneți: „Nu ne putem permite nu pentru a utiliza bune practici. Trăim sau murim, dar trebuie să facem anumite lucruri pentru a trăi, cum ar fi scrierea testelor și documentației. Nu este o opțiune. ”
Trebuie să zâmbești și să spui:„ Nu vom rescrie niciodată acest cod. Știu că vrei să spui bine, dar când vine vorba de remedierea codului sau de adăugarea de noi funcții, știu ce vei spune. spuneți întotdeauna. ”
Prin faptul că sunteți un părinte ferm, vă ajutați managerul să crească pentru a fi tipul de lider de afaceri pe care îl ar vrea să lucreze pentru.