Refactorizarea pe care noi nu o facem

Nu cu mult timp în urmă am descris procesul refactorizării unui proiect care a venit la departament, am râs și am strigat împreună, dar nu am putut învăța moralul de acolo. Și în această poveste nu suntem "albi și pufos" ...

Povestea a început să fie trită - proiectul este îndoit, clientul caută o nouă echipă de dezvoltare și ne găsește. Suntem cu toții în afara de noi înșine, pe un cal alb pe care îl conducem în proiect și nu este nimic teribil, doar un simplu cod PHP, adică clasele nu sunt prezente, funcțiile sunt de asemenea practice (un singur fișier funcții.php, iar în acesta dbconnect (), userlogin () da funcțional-șablon, și ceva în trifoi). Privim - și problema este că în sarcină - până la 10 000 de utilizatori online și în acest moment nu puteți merge la site. Ei bine, sarcina este clară, suntem pune în proiectul de dezvoltator care este familiarizat cu optimizarea, bine, el a început să lucreze. Și da, după două săptămâni de lucru (și poate mai mult, nu-mi amintesc mai mult), site-ul a venit la viață, indicii ușor, un pic de caching, o mai bună optimizare a interogărilor SQL și încărcarea pe server a fost adormit.

După ceva timp, vom înlocui dezvoltator în proiect, noua persoană mai mult la preferințele sunt caracteristicile și Chengy clientului, iar eficiența noastră din nou merge în sus, clientul este mulțumit, noi luăm în considerare banii. Totul este bun și nimic nu prefigurează ceea ce sa întâmplat.

În proiect, din ce în ce mai puține lucruri, sarcina revine la nivelul banalității și luăm decizia de a pune un luptător "verde" în ea pentru a testa, iar clientul a dat-o bine. Începerea a fost netedă, iar apoi problemele au început, apoi au ieșit din termenul limită, pe care ei înșiși l-au stipulat, apoi serverul a fost umplut cu un cod destul de nefuncțional. Și ca rezultat - "Vă mulțumim că ați ajutat, că m-ați ajutat cu adevărat, dar voi face fără dvs."

Începem analiza zborurilor, hotărâm că noul venit pe care l-am pus în mod necorespunzător în proiect, dar până când am urcat în studiul codului la urechi, și acum voi descrie ceea ce nu am văzut acolo.

templating

Sistemul șablon simplu de sintaxa nativă a fost creată (care este mai degrabă un plus), dar în șabloanele sunt îndeplinite în mod constant pentru a accesa baza de date, și atunci când modificați structura a avut perelapachivat nu numai paginile de cod, dar, de asemenea, toate șabloanele. Astfel, a fost necesar să împărțim logica din vedere o dată pentru totdeauna.

Dacă vorbim despre șablonul funcțional, iată un exemplu elementar:

Restul rămâne în conștiința dezvoltatorului, de fapt chiar și în același Smarty puteți să vă deplasați logica cu dorința potrivită.

Procesul de dezvoltare a fost, de asemenea, dificil datorită faptului că a existat o mulțime de copie-pastă în cadrul proiectului și a făcut schimbări imediat și peste tot a fost problematică (căutarea și înlocuirea dosarului nu este greu). Și a fost necesar să selectați entitățile și metodele de lucru cu ele pentru a reduce la o clasă (sau cel puțin un fișier). Așadar, am putea reduce repetarea codului (și repetarea erorilor).

controlere

Pur și simplu a cere acest punct, așa că am adăugat, și a vrut să spun acest lucru - dacă aveți un proiect la rădăcina unui cuplu de zeci de fișiere, atunci nu deranjez, și rescrie-le pe toate pentru a fi transformat controlere tata și un singur punct de intrare, deoarece acestea fișierele cu sarcina la îndemână sunt destul de ușor de gestionat. Ca o concluzie - nu ar trebui să urmăriți codul ideal. astfel de investiții nu pot fi plătite.

Lucrul cu DB

Așa cum am descris mai sus, interogări SQL s-au întâlnit în proiect oriunde și peste tot și chiar și procesul de screening al datelor de intrare în ele era diferit. Aduceți același stil. creați o bază de date normală pentru baza de date sau cel puțin înlocuiți utilizarea extensiei mysql cu ceva mai modern.

Ar fi posibil să scriem o pușcă simplă pentru un vrader de DOP în 20 de minute, desigur că nu va fi universal, dar va facilita munca de refactorizare:

ușor de conectat folosind un singur punct de intrare
Puteți adăuga rapid cache pentru toate interogările

cache

Este demn de menționat caching înăsprit, dar numai în cazul în care sunt specificate de către client, și-ar dori să vadă cache-ul a fost peste tot în cazul în care are sens, și nu pe baza încheierii „ca aici,“ adică, era necesar ca fiecare fișier să se uite, jurnal de analiză, iar timpul de tamponare poate fi potyunit în reyltayme, dar schimbarea de fus orar, trebuie să ne puternic împiedicată, și nimeni nu a vrut să de dragul casei pentru a monitoriza server, sau cel puțin ceri proprii administratori ( și oferim astfel de servicii;).

Lucrează pe bug-uri

Aici totul este ușor, dacă deschideți un fișier PHP, iar IDE solicită să țipați despre erori în cod, apoi să luați cinci minute și să le reparați:

Și totuși - fără întârziere, activați afișarea erorilor și amintiți - notificarea "deprimată" fură timpul:

testarea

- Unitatea de testare? Despre ce vorbim, avem un zapar aici, trebuie să ne dăm drumul la livrare!
Ei bine, bine ...

Optimizarea clienților

Din acest paragraf nu va atinge nici unul dintre dezvoltatorii implicați în proiect, și este foarte trist. Desigur, pagina principală a proiectului și nu prea grele - doar 300KB, dar contul ei de 15 fișiere JS 18 imagini în CSS (sprite salva server), precum și în valoare de freca cârlige vechi pentru browsere (IE5.5 și IE6), pentru a facilita aspectul, deoarece 8,7kb nu este atât de mic (prea multe mese).

De fapt, site-ul pentru evaluarea YSlow obține o estimare a lui C (70), pe care consider că este inacceptabil, pentru comparație, blogul meu cu o grămadă de imagini - A (90). Cum de a îmbunătăți aceste lecturi foarte bine spune site-ul webo.in. și cred că ar trebui să dea un loc în marcaje.

Nu "al nostru"

Aș dori, de asemenea, să vă spun că foarte des programatorii nu vă faceți griji și nu trăiesc proiect, iar acest lucru este un impact foarte negativ asupra relației cu clientul și dezvoltarea proiectului. Proiectul ar trebui să fie ceva inseparabilă de tine, dacă site-ul este îndoit sub influxul de utilizatori -, de asemenea, nu ar trebui să fie pe cont propriu, este creația ta suferă, și el are nevoie de ajutorul tau. Tu, ca un expert trebuie să informeze clientul modul de dezvoltare a proiectului, deoarece este cunoscut despre tot know-how-ul în web-dezvoltare, și nu trebuie să se aștepte că propunerea de a îmbunătăți el va face primul pas ar trebui să fie exact tu ce si chiar acum. Nu este necesar în proiect de a trăi o zi, trebuie să privim în viitor și, eventual, costul proiectului refactoring pentru a începe ieri.

Dacă totul se desfășoară fără probleme în proiectul dvs., atunci aruncați o privire mai atentă, poate într-o astfel de formă dulce se află cancerul indiferenței dumneavoastră față de viața proiectului.

Dacă sunteți deja pe foc începe refactoring, am un pic mai mult, chiar distrage atenția - dreptul restructurează în valoare de a „vinde“ clientul care iubește și știe cum să numere banii cu el este de a vorbi în acest fel. Mult noroc pentru tine.