Dacă sunteți în dezvoltarea de software, noi tehnici, limbi și concepte pop-up tot timpul. Cu toții simțim acele îndoieli sâcâitoare din când în când: „pot să țin pasul cu schimbările și să rămân competitiv?”Luați un moment și rezumați o replică din filmul meu preferat, Casablanca: „lucrurile fundamentale se aplică, pe măsură ce trece timpul.”
la fiecare câteva săptămâni, revizităm unele dintre postările preferate ale cititorului nostru din întreaga istorie a site-ului. Acest tutorial a fost publicat pentru prima dată în aprilie, 2012.
ceea ce este adevărat pentru dragoste, este adevărat pentru cod.
ceea ce este adevărat pentru dragoste, este adevărat pentru cod. Lucrurile fundamentale se vor aplica întotdeauna. Dacă aveți o înțelegere a ideilor care stau la baza dezvoltării de software, vă veți adapta rapid la noile tehnici. În acest tutorial, vom discuta trei principii de bază și le vom amesteca cu multe altele. Acestea oferă un mod puternic de gestionare a complexității software-ului. Voi împărtăși câteva dintre opiniile și gândurile mele personale, care, sperăm, se vor dovedi utile atunci când vine vorba de aplicarea lor la cod și proiecte din lumea reală.
principiu – nu te repeta
o strategie de bază pentru reducerea complexității la unități gestionabile este împărțirea unui sistem în bucăți.
acest principiu este atât de important de înțeles, încât nu îl voi scrie de două ori! Este denumit în mod obișnuit prin acronim, uscat, și a apărut în cartea programatorul Pragmatic, de Andy Hunt și Dave Thomas, dar conceptul, în sine, a fost cunoscut de mult timp. Se referă la cele mai mici părți ale software-ului dvs.
când construiți un proiect software mare, de obicei veți fi copleșiți de complexitatea generală. Oamenii nu sunt buni la gestionarea complexității; sunt buni la găsirea de soluții creative pentru probleme cu un domeniu specific. O strategie de bază pentru reducerea complexității la unitățile gestionabile este împărțirea unui sistem în părți mai utile. La început, poate doriți să vă împărțiți sistemul în componente, unde fiecare componentă reprezintă propriul subsistem care conține tot ce este necesar pentru a realiza o anumită funcționalitate.
de exemplu, dacă construiți un sistem de gestionare a conținutului, partea care este responsabilă pentru gestionarea utilizatorilor va fi o componentă. Această componentă poate fi împărțită în subcomponente suplimentare, cum ar fi gestionarea rolurilor și poate comunica cu alte componente, cum ar fi componenta de securitate.
pe măsură ce împărțiți sistemele în componente și, mai departe, componentele în subcomponente, veți ajunge la un nivel în care complexitatea este redusă la o singură responsabilitate. Aceste responsabilități pot fi implementate într-o clasă (presupunem că construim o aplicație orientată pe obiecte). Clasele
conțin metode și proprietăți. Metodele implementează algoritmi. Algoritmii și-în funcție de cât de obsesivi vrem să obținem – subpunctele
algoritmilor calculează sau conțin cele mai mici piese care vă construiesc logica de afaceri.
Principiul uscat afirmă că aceste mici cunoștințe pot apărea doar o singură dată în întregul sistem.
trebuie să aibă o singură reprezentare în cadrul acesteia.
fiecare bucată de cunoaștere trebuie să aibă o reprezentare unică, lipsită de ambiguitate, autoritară în cadrul unui sistem.
notați diferența dintre piesa de cunoștințe și reprezentarea acesteia. Dacă implementăm conexiunea bazei de date în CMS-ul nostru, vom avea un fragment de cod care va inițializa driverul bazei de date, va trece acreditările și va salva o referință la conexiune într-o variabilă. Fragmentul de cod face parte din cunoaștere, este vorba despre modul în care se realizează ceva. Variabila cu referire la conexiune este reprezentarea acelei cunoștințe – și aceasta poate fi utilizată de alte părți. Dacă acreditările bazei de date se schimbă, va trebui să schimbăm fragmentul – nu reprezentarea acestuia.într-o aplicație perfectă, fiecare mică bucată de logică de afaceri își încapsulează cunoștințele într-o reprezentare, și anume o variabilă sau o proprietate de clasă.
această variabilă în sine este încapsulată într-o clasă care poate fi descrisă ca o reprezentare a unei responsabilități. Clasa este încapsulată într-o componentă care poate fi descrisă ca o reprezentare a funcționalității.
Acest lucru poate fi continuat până când ajungem la nivelul superior al proiectului nostru software – adică un teanc de reprezentări cu o complexitate crescândă. Acest mod de a privi complexitatea software-ului se numește arhitectură modulară, iar DRY este o parte importantă a acestuia.
realizarea uscăciunii
uscarea este o filozofie care împachetează logica în reprezentări.
există multe modalități de a obține uscarea. Hunt și Thomas au sugerat (printre altele) generatoare de coduri și transformarea datelor. Dar, în esență, uscat este o filozofie care împachetează logica în reprezentări.
deoarece fiecare parte a aplicației dvs. poate fi văzută ca reprezentare, fiecare parte expune fragmente specifice ale logicii dvs. de bază: Gestionarea utilizatorilor expune accesul la utilizatorii înregistrați ai CMS, clasa de utilizatori reprezintă un singur utilizator și expune proprietățile sale (cum ar fi numele de utilizator). Acesta preia proprietățile, prin reprezentarea bazei de date.
arhitectura uscată și modulară necesită o planificare bună. Pentru a obține o ierarhie reprezentativă de jos în sus, împărțiți aplicația într-o ierarhie de părți mai mici separate logic și lăsați-le să comunice între ele. Dacă trebuie să gestionați proiecte mai mari, organizarea lor în componente și utilizarea uscată în componente este o idee bună. Încercați să aplicați următoarele reguli:
- faceți o ierarhie vizuală a aplicației software și mapați componentele principale la aceasta. Proiectele complexe pot necesita o hartă dedicată pentru fiecare componentă.
- dacă ajungeți la un nivel de responsabilități conectate, poate doriți să treceți la diagrame UML (sau similare).
- înainte de a scrie o bucată de cod, denumiți ierarhia sa în proiectul dvs. software. Definiți ceea ce reprezintă și asigurați-vă că îi cunoașteți rolul în componenta înconjurătoare.
- definiți ce ar trebui să expună reprezentarea altor părți (cum ar fi funcțiile pentru a executa SQL într-un driver de bază de date) și ce ar trebui să ascundă (cum ar fi acreditările bazei de date).
- asigurați-vă că reprezentările nu se bazează pe reprezentări ale unui alt nivel de complexitate (cum ar fi o componentă care se bazează pe o clasă dintr-o altă componentă).
driverul bazei de date este un exemplu simplificat, deoarece există mult mai multe straturi implicate în lumea reală (cum ar fi un strat specific de abstractizare a bazei de date) și puteți face mult mai multe pentru a încapsula logica – în special scufundarea în modele de design. Dar chiar dacă tocmai ați început cu codificarea, trebuie să țineți cont de un lucru:
când vă aflați scriind un cod similar sau egal cu ceva ce ați scris înainte, luați-vă un moment să vă gândiți la ceea ce faceți și nu vă repetați.
în lumea reală, aplicațiile care sunt 100% uscate sunt greu, dacă nu imposibil, de realizat. Cu toate acestea, aplicațiile care nu sunt uscate într – un grad inacceptabil – și, prin urmare, greu de întreținut-sunt destul de frecvente. Prin urmare, nu este surprinzător să aflați că mai mult de 50% din toate proiectele software eșuează – dacă aruncați o privire asupra codului.
mulți oameni tind să creadă că codul rău este produs de programatori răi. Din experiența mea, aceasta este foarte mult o excepție. De cele mai multe ori, codul rău este produs de managerii de cont răi și o configurare greșită generală a gestionării proceselor în companii.
codul rău este rar produs de programatorii răi.
un exemplu
uscarea se realizează printr-o bună planificare.
de exemplu, spuneți că sunteți angajat ca consultant tehnic de către o companie care are probleme cu calitatea și întreținerea codului. Examinați sursa și vedeți hacks și duplicarea codului – codul nu este uscat. Acesta este un simptom al calității proaste a codului, nu este motivul. Dacă aruncați o privire la sistemul de control al versiunii – aka Istoricul codului – este posibil să găsiți hacks care au fost introduse uneori în apropierea termenelor și a reperelor. Faceți-vă timp pentru a revizui ce modificări sunt făcute și probabil că vă veți confrunta cu o schimbare a cerințelor.
după cum sa menționat mai sus, uscarea se realizează printr-o bună planificare. Modificările forțate la un termen dur obligă dezvoltatorii să implementeze soluții murdare. Odată ce codul este compromis, principiul uscării este probabil să fie sacrificat complet la modificări ulterioare.
există un motiv pentru care cele mai de succes corporații din domeniul IT au fost fondate de oameni cu o înțelegere tehnică foarte bună – sau chiar de coderi înșiși: Bill Gates, Mark Zuckerberg, Steve Wozniak, Steve Jobs, Larry Page, Sergey Brin și Larry Ellison știu (sau știau) ce eforturi sunt necesare pentru a implementa ceva. Dimpotrivă, multe companii tind să pună cerințele pentru inginerie în mâinile managerilor de cont, iar partea conceptuală în mâinile consultanților de afaceri…oameni care nu au implementat niciodată nimic.
prin urmare, multe concepte tehnice funcționează numai în Powerpoint, Photoshop și pe afișaje cu ecran lat de 27″. Este posibil ca aceasta să fi fost o abordare de succes în zilele site – urilor web, mai mult sau mai puțin statice, dar nu este în zilele noastre-cu aplicații interactive pe mai multe dispozitive. Deoarece coderii sunt ultimii din linie, ei sunt cei care trebuie să aplice corecții rapide asupra erorilor din concept. Dacă acest lucru este însoțit de un manager de cont, care nu poate rezista unui client căruia îi place să facă schimbări de ultim moment, planurile sunt aruncate la gunoi și se implementează ceva rapid și murdar. Codul devine unDRY.
acest exemplu este un pic extrem (cu toate acestea, am asistat la astfel de scenarii), dar demonstrează că DRY este un concept teoretic, care este contestat de diferite părți din lumea reală. Dacă lucrați într-o companie care vă obligă să lucrați în acest mod, puteți sugera unele modificări ale procesului (cum ar fi introducerea expertizei tehnice într-o etapă anterioară a proiectelor tehnice).
Dacă aveți o abordare hands-off, continuați să citiți! Principiul nu vei avea nevoie de ea va veni la salvare.
principiu-păstrați-l simplu prost
cea mai simplă explicație tinde să fie cea corectă.
la sfârșitul secolului al 19 – lea, fizicienii s-au străduit să explice cum interacționează gravitația, magnetismul și optica, atunci când vine vorba de distanțe mari-cum ar fi distanțele din sistemul nostru solar. Prin urmare, a fost postulat un mediu numit eter. S-a spus că lumina călătorește prin acest mediu și că este responsabilă pentru efecte care nu pot fi explicate altfel. De-a lungul anilor, teoria a fost extinsă cu ipoteze care au ajustat postulatul eterului la rezultatele experimentelor. Unele ipoteze au fost arbitrare, unele au introdus alte probleme, iar întreaga teorie a fost destul de complexă.
Un angajat al Oficiului elvețian De brevete, Albert Einstein, a sugerat să scape de întreaga teorie a eterului atunci când a introdus o idee simplă, dar revoluționară: toată ciudățenia în calculul cu distanțe mari ar dispărea dacă am accepta că timpul nu este o constantă; este relativ. Acest incredibil de out-of-the-box de gândire pentru a ajunge la cea mai simplă explicație cu cele mai puține ipoteze pentru a selecta între scenarii concurente este menționată ca Razor Ockhams lui.
există concepte similare în multe domenii. În dezvoltarea de software (și altele), ne referim la ea ca sărut. Există multe variante pentru acest acronim, dar toate înseamnă că ar trebui să te străduiești pentru cel mai simplu mod de a face ceva.
HTTP
Protocolul de transfer hipertext este considerat pe scară largă a fi un exemplu perfect pentru o soluție simplă: conceput pentru a transfera documente bazate pe hipertext, este coloana vertebrală a aplicațiilor extrem de interactive și desktop-esque în zilele noastre. Poate că trebuie să găsim soluții pentru limitări în protocol și poate că trebuie să-l înlocuim într-o zi. Cu toate acestea, status quo-ul este: bazat pe câteva metode de solicitare (cum ar fi GET și POST), coduri de stare și argumente de text simplu, HTTP S-a dovedit a fi flexibil și robust. De aceea, HTTP a fost împins în mod repetat la limite de către dezvoltatorii web – și este încă în picioare.
luăm această abordare de la sine înțeles, dar istoria dezvoltării și standardizării software este plină de soluții prea complexe și pe jumătate coapte. Există chiar și un cuvânt dedicat făcut-up pentru ea: bloatware. Software-ul ca acesta este, de asemenea, descris ca fiind DOD, mort la sosire. Am o teorie care este foarte asemănătoare cu teoria mea de cod unDRY, atunci când vine vorba de bloatware … Cu toate acestea, succesul internetului poate fi descris ca un succes al soluțiilor simple, dar eficiente.
deci, ce este necesar pentru a ajunge la cea mai simplă soluție posibilă? Totul se reduce la mentenabilitate și inteligibilitate în dezvoltarea de software. Prin urmare, KISS începe în timpul fazei de inginerie cerințe. Când vă gândiți cum să transformați cerințele unui client în componente implementabile, încercați să identificați următoarele părți:
- funcționalitate care are un raport inadecvat între beneficiu și eforturi.
- funcționalitate care este foarte dependentă de alte funcționalități.
- funcționalitate care este probabil să crească în complexitate.
există mulți oameni implicați în procesul conceptual, care nu au expertiza tehnică pentru a face o analiză fiabilă cost-beneficiu
am lucrat odată la un proiect, în care clientul dorea să importe foi de calcul Excel în software-ul său de gestionare a echipajului. Acesta a fost un meci clar. Excel este un software proprietar cu un format de document complex. Formatul este complex, deoarece este bogat în CARACTERISTICI: Puteți adăuga grafice și alte lucruri-caracteristici care nu au fost necesare de către client. El a fost pur și simplu interesat de numere. Astfel, implementarea importului Excel ar necesita implementarea multor funcționalități inutile. În plus, există mai multe versiuni de versiuni Excel, iar Microsoft declanșează o altă versiune în fiecare an. Acest lucru ar fi fost greu de întreținut și vine cu costuri suplimentare în viitor.
am ajuns să implementăm un import cu valoare separată prin virgulă. Acest lucru a fost făcut cu câteva linii de cod. Cheltuielile generale ale datelor au fost foarte mici (comparați o foaie Excel cu echivalentul CSV), iar soluția a fost întreținută și rezistentă la viitor. Excel era gata să exporte CSV oricum (precum și alte programe pe care clientul ar putea dori să le utilizeze în viitor). Deoarece soluția a fost la prețuri reduse, de asemenea, a fost o bună aplicare a principiului KISS.
pentru a rezuma: încercați să vă gândiți în afara casetei dacă o sarcină vă pare complicată. Dacă cineva vă explică cerințele sale și vă gândiți că va fi greu și complex de implementat, aveți dreptate în aproape orice circumstanțe. În timp ce unele lucruri sunt doar atât – greu de implementat – soluțiile prea complicate sunt destul de obișnuite. Acest lucru se întâmplă deoarece există multe persoane implicate în procesul conceptual, care nu au expertiza tehnică pentru a face o analiză fiabilă cost-beneficiu. Prin urmare, ei nu văd problema. Verificați de două ori cerințele dacă sunt într-adevăr dezbrăcate până la esența de care are nevoie clientul. Faceți-vă timp pentru a discuta punctele critice și explicați de ce alte soluții ar putea fi mai potrivite.
principiu – tu „nu va avea nevoie de ea
codificare este despre construirea lucruri.
când Google+ a fost lansat, Mark Zuckerberg – fondatorul Facebook – a fost unul dintre primii care și-a creat un cont în rețeaua socială care urmărea să-și dea jos propriul cont. El a adăugat doar o linie la secțiunea Despre mine: „construiesc lucruri.”. Sincer cred că aceasta este o propoziție strălucitoare, deoarece descrie esența pură a codificării în câteva cuvinte simple. De ce ai decis să devii coder? Entuziasm pentru soluții tehnice? Frumusețea eficienței? Oricare ar fi răspunsul dvs., este posibil să nu fie ” construirea celor 1.000.001th site corporativ cu funcționalitate standard”. Cu toate acestea, majoritatea dintre noi facem bani în acest fel. Indiferent unde lucrați, probabil că vă veți confrunta cu sarcini plictisitoare și repetitive din când în când.
80% din timpul petrecut pe un proiect software este investit în 20% din funcționalitate.
principiul nu vei avea nevoie de el (YAGNI) se ocupă de aceste sarcini. Practic se traduce prin: Dacă nu este în concept, nu este în cod. De exemplu, este o practică obișnuită abstractizarea accesului la baza de date într-un strat care gestionează diferențele dintre diferiți drivere, cum ar fi MySQL, PostgreSQL și Oracle. Dacă lucrați pe un site web corporativ care este găzduit pe o stivă LAMP, pe o gazdă partajată, cât de probabil este că vor schimba baza de date? Amintiți-vă că conceptul a fost scris cu buget în minte.
dacă nu există buget pentru abstractizarea bazei de date, nu există abstractizare a bazei de date. Dacă evenimentul puțin probabil al unei modificări a bazei de date are loc, este un lucru firesc să percepeți taxa pentru solicitarea de modificare.
este posibil să fi observat diferența dintre nu veți avea nevoie de ea și arhitecturile modulare cu acționare uscată: aceasta din urmă reduce complexitatea prin împărțirea unui proiect în componente gestionabile, în timp ce prima reduce complexitatea prin reducerea numărului de componente. YAGNI este similar cu principiul sărutului, deoarece se străduiește pentru o soluție simplă. Cu toate acestea, KISS se străduiește pentru o soluție simplă încercând să pună în aplicare ceva cât mai ușor posibil; YAGNI se străduiește pentru simplitate prin faptul că nu o implementează deloc!
Theodore Sturgeon, un autor american de sci – fi, a declarat legea: „nouăzeci la sută din tot este rahat”. Aceasta este o abordare foarte radicală și nu prea utilă în proiectele din lumea reală. Dar rețineți că” prostiile ” pot consuma foarte mult timp. O regulă bună este: aproximativ 80% din timpul petrecut pe un proiect software este investit în 20% din funcționalitate. Gândiți-vă la propriile proiecte! De fiecare dată când o fac, sunt surprins de acuratețea regulii 80:20.
Dacă sunteți într-o companie care este cunoscută pentru termene strânse și concepte imprecise, aceasta este o strategie puternică. Nu veți fi recompensat pentru implementarea unui strat de abstractizare a bazei de date. Șansele sunt că șeful tău nu știe ce este chiar un strat de abstractizare a bazei de date.
deși acest concept poate părea simplu, poate fi greu să difere părțile necesare de cele inutile. De exemplu, dacă vă simțiți confortabil cu o bibliotecă sau un cadru care utilizează abstractizarea bazei de date, nu veți economisi mult timp în eliminarea acesteia. Conceptul cheie este un alt mod de a privi software-ul: suntem instruiți pentru a scrie software-ul viitor-dovada și poate fi întreținut. Aceasta înseamnă că suntem instruiți să gândim înainte. Ce schimbări pot apărea în viitor? Acest lucru este esențial pentru proiecte mai mari, dar deasupra capului pentru cele mai mici. Nu te gândi la viitor! Dacă un mic site corporativ face schimbări fundamentale, este posibil să fie nevoit să înceapă de la zero. Aceasta nu este o problemă semnificativă în comparație cu bugetul general.
planificarea unui proiect
când vă pregătiți lista de sarcini pentru un proiect, luați în considerare următoarele gânduri:
- obțineți o complexitate mai mică prin reducerea nivelului de abstractizare.
- funcționalitate separată de caracteristici.
- își asumă cerințe non-funcționale moderate.
- identificați sarcinile consumatoare de timp și scăpați de ele.
Să mergem un pic în detaliu! Am oferit deja un exemplu pentru primul element din listă: nu înfășurați un driver de bază de date în jurul unui strat de abstractizare a bazei de date. Fiți suspicioși cu privire la tot ceea ce adaugă complexitate stivei dvs. de software. Observați că abstractizarea este adesea furnizată de biblioteci terțe. De exemplu-în funcție de limbajul dvs. de programare -, un strat de persistență, cum ar fi Hibernate (Java), Doctrine (PHP) sau Active Record (Ruby) vine cu abstractizarea bazei de date și maparea relațională a obiectelor. Fiecare bibliotecă adaugă complexitate. Trebuie menținută. Actualizări, patch-uri și remedieri de securitate trebuie să fie aplicate.
implementăm caracteristici în fiecare zi, deoarece anticipăm că acestea vor fi utile. Prin urmare, gândim înainte și implementăm prea mult. De exemplu, mulți clienți doresc să aibă un site web mobil. Mobil este un termen de înțelegere largă; nu este o decizie de proiectare. Este un caz de utilizare! Oamenii care folosesc un site mobil sunt, bine, mobil. Asta înseamnă că ar putea dori să acceseze alte informații sau funcționalități decât un utilizator care vizitează site-ul pus înapoi la desktop-ul său. Gândiți-vă la un site de cinema: utilizatorii din autobuz vor dori probabil să acceseze ora de pornire a filmelor viitoare, nu remorca de 50 MB.
conceptele proaste pot fi adesea identificate prin lipsa cerințelor nefuncționale.
cu un buget adecvat, veți efectua o analiză dedicată a cerințelor pentru mobil. Fără această analiză, veți furniza pur și simplu aceleași informații ca pe site-ul desktop. Acest lucru va fi bine pentru multe circumstanțe! Deoarece browserele mobile sunt foarte inteligente în ajustarea site-urilor desktop la afișarea lor, o abordare radicală YAGNI ar putea fi să nu scrieți deloc un site mobil!
cerințele nefuncționale nu descriu comportamentul unui software, ci descriu proprietăți suplimentare care pot fi utilizate pentru a evalua calitatea software-ului. Deoarece descrierea calității software-ului presupune cunoștințe despre software, conceptele proaste pot fi adesea identificate prin lipsa cerințelor nefuncționale. Mentenabilitatea, nivelul documentației și ușurința integrării sunt exemple pentru cerințele nefuncționale. Cerințele nefuncționale ar trebui să fie măsurabile. Prin urmare, „pagina ar trebui să se încarce rapid.”este prea inconcret”, pagina ar trebui să se încarce în maxim două secunde în timpul unui test de performanță Mediu.”este foarte concret și măsurabil. Dacă doriți să aplicați principiul YAGNI, asumați cerințe non-funcționale moderate dacă nu sunt menționate în concept (sau dacă sunt menționate, dar neconcrete). Dacă scrieți singur cerințele nefuncționale, fiți realist: o mică corporație cu 20-50 de vizite pe zi nu necesită trei zile de ajustare a performanței – deoarece pagina ar trebui să se încarce suficient de repede, deoarece serverul nu este ocupat. Dacă corporația poate crește numărul de vizite zilnice, un server mai bun sau un pachet de găzduire nu ar trebui să fie prea scump.
nu în ultimul rând, amintiți-vă regula 80:20!
nu în ultimul rând, amintiți-vă regula 80:20! Trebuie să identificăm părțile consumatoare de timp. Dacă o parte este absolut necesară, trebuie să o implementați. Întrebarea ar trebui să fie: cum o veți implementa? Trebuie să fie cel mai recent cadru cu o comunitate mică? Trebuie să treceți la versiunea recent lansată a unei biblioteci dacă documentația nu este actualizată? Ar trebui să utilizați noul CMS, când nu sunt disponibile Toate extensiile? Cât de multă cercetare va fi necesară pentru a face acest lucru? „Așa am făcut-o întotdeauna.”nu este o abordare interesantă, dar va face treaba fără surprize.
este important să înțelegeți că toate acestea nu înseamnă că puteți începe să scrieți cod murdar cu hacks pe parcurs! Scrii o aplicație ușor, nu unul murdar! Cu toate acestea, nu veți avea nevoie de ea este o abordare practică. În cazul în care ar provoca mai multe linii de cod pentru a reduce câteva linii de duplicate de cod, eu personal cred că s-ar putea referi eforturile la buget și unele unDRYness este ok. Este o aplicație mică. Prin urmare, complexitatea de întreținere adăugată este acceptabilă. Suntem în lumea reală.
Să revenim la gândul inițial: ne place să construim lucruri. Când Beethoven a scris variațiile Diabelli, a fost o lucrare contractuală. Nu cred că a făcut compromisuri în privința bugetului. El a fugit mile suplimentare, pentru că el nu a vrut să scrie muzica medie; el a vrut să scrie o compoziție perfectă.
cu siguranță nu insinuez că suntem cu toții genii și că strălucirea noastră ar trebui să strălucească prin fiecare linie de cod, dar îmi place să mă gândesc la arhitectura software ca la compoziții. Sunt un dezvoltator pasionat, pentru că vreau să construiesc compoziții perfecte și vreau să fiu mândru de lucrurile pe care le construiesc.
Dacă doriți să fie un dezvoltator cu experiență și de afaceri-proofed, trebuie să stăpânească nu o să nevoie de ea principiu. Dacă vrei să-ți păstrezi pasiunea, trebuie să lupți împotriva ei din când în când.
rezumat
principiile Software sunt un mod de a privi software-ul. Pentru mine, un principiu bun ar trebui să se bazeze pe un concept simplu, dar ar trebui să evolueze la o construcție complexă de idei atunci când se confruntă cu alte tehnici și filozofii. Care sunt principiile tale software preferate?