Una dintre cele mai importante riscuri cu care se confruntă echipa de dezvoltare, este că dezvoltatorii sunt de lucru cu codul separat, independent unul de celălalt, rezultând într-un program complex nu funcționează conform așteptărilor în asamblarea codului acumulat. În funcție de când a fost descoperit incompatibilitatea proiectului, programul de depanare poate dura mai mult decât cu integrarea mai devreme, mai ales în cazul unor schimbări în interfața sau după punerea în aplicare a revizuiri serioase principalelor părți ale programului.
Dacă doriți să creați un program simplu de calculator care constă dintr-un singur fișier, trebuie doar să colectați și să conectați tot codul pe care l-ați scris acestui fișier. Pe cel mai comun proiect, care este echipa de dezvoltatori, există sute, chiar mii de dosare. Acest lucru "contribuie" la faptul că procesul de creare a unui program executabil devine mai complicat și consumator de timp: trebuie să "asamblați" programul din diferite componente.
Practica aplicată, de exemplu, în Microsoft și în alte companii implicate în dezvoltarea de software, este asamblarea zilnică a programului, care este completată de testarea fumului. În fiecare zi, după fiecare fișier este compilat (sbildovan construit), conectat (este legată), și integrate în programul executabil, programul în sine este expus la un set destul de simplu de teste, al cărui scop este de a vedea dacă în timpul programului „fumează“ lucru. Aceste teste se numesc fum (din fumul englez - fum). Cel mai adesea acest proces este destul de bine automatizat (sau ar trebui să fie).
Beneficii. Acest proces simplu oferă câteva avantaje semnificative.
Minimizarea riscului de integrare
Unul dintre cele mai importante riscuri cu care se confruntă echipa de dezvoltare este faptul că dezvoltatorii lucrează cu codul separat, independent unul de altul, ca urmare a faptului că programul complex nu funcționează așa cum se aștepta în asamblarea codului. În funcție de când a fost descoperit incompatibilitatea proiectului, programul de depanare poate dura mai mult decât cu integrarea mai devreme, mai ales în cazul unor schimbări în interfața sau după punerea în aplicare a revizuiri serioase principalelor părți ale programului.
În cazuri extreme, erorile de integrare pot duce la anularea proiectului.
Asamblarea zilnică și efectuarea testelor de fum face posibilă reducerea riscului de erori de integrare, reacția la acestea în timp și prevenirea acumulării acestora.
Reducerea riscului de produs software de proastă calitate
Calitatea scăzută a produsului depinde în mod direct de probleme și probleme de integrare. Funcționarea zilnică a setului minim de teste de fum nu dă erori și probleme care au prioritate față de proiect. Dacă ați adus proiectul într-o stare stabilă o dată, acesta va rămâne stabil în orice moment. Procedând astfel, nu veți permite niciodată o scădere a calității la nivelul la care apar erorile.
Ajutați în diagnosticarea erorilor
Dacă într-o zi produsul nu se întâlnește (adunat cu erori), apoi folosind ansamblul zilnic și executând un set de teste de fum este mult mai ușor de găsit cauza problemei. Un produs de lucru ieri și care nu funcționează astăzi este un indiciu clar că ceva a mers prost între cele două adunări.
Îmbunătățirea moralului
În cazul în care produsul funcționează, și în fiecare zi mai mult și mai mult capătă noi calități și funcții, moralul de dezvoltatori, în teorie, ar trebui să crească și nu contează ce ar trebui să facă acest produs. Dezvoltatorul este întotdeauna mulțumit să respecte "creierul" său de lucru, chiar dacă produsul afișează un dreptunghi pe ecran :)
Folosirea testelor zilnice și testelor de fum
Principiul de bază al acestui proces este ideea simplă de a construi și de a executa testele de fum DAILY.
Iată câteva detalii despre acest principiu.
Construcția zilnică a aplicației
În unele companii este obișnuit să colectați proiectul nu în fiecare zi, ci o dată pe săptămână. Acest sistem este eronat, deoarece în cazul "ruperii" în proiect în această săptămână, poate dura câteva săptămâni până la următoarea adunare de succes. În acest caz, compania pierde toate avantajele sistemului zilnic de asamblare a proiectelor.
Test de asamblare nereusit
În cazul unei întruniri zilnice a proiectului, se presupune că proiectul ar trebui să funcționeze. Cu toate acestea, dacă proiectul nu funcționează, reparația devine o sarcină cu prioritate 1.
Fiecare proiect are propriul său standard și un semn al ceea ce se numește "defalcare în timpul asamblării". Acest standard ar trebui să stabilească nivelul de calitate, care este suficient pentru a urmări defectele minore și pentru a nu trece cu vederea defectele care "blochează" proiectul.
O bună adunare este cea în care, cel puțin:
- toate fișierele, bibliotecile și alte componente sunt compilate cu succes;
- linkurile către toate fișierele, bibliotecile și alte componente sunt valide;
- nu conțin niciun sistem stabil, excluzând posibilitatea unei funcționări corecte a programului de aplicație, blocarea erorilor;
- toate testele de fum trec.
Teste zilnice de fum
Testele de fum trebuie efectuate pe întregul proiect de la început până la sfârșit. Ele nu ar trebui să fie exhaustive și exhaustive, ci să conțină o verificare a tuturor funcțiilor de bază. Testele de fum ar trebui să fie suficient de adânc, astfel încât, în cazul transmiterii de succes poate fi descrisă ca fiind stabilă și un proiect numesc astfel încât să poată fi supus unei încercări mai profundă.
Sensul de asamblare zilnică este pierdut fără testarea fumului. Acest proces protejează calitatea produsului și nu permite nici o problemă de integrare. Fără acest lucru, procesul zilnic de construire este o pierdere de timp, scopul căruia este de a verifica compilația.
Testarea fumului ar trebui să se dezvolte la nivel cu proiectul. La început, testele de fum vor verifica ceva simplu, de exemplu, proiectul poate produce un mesaj "Bună ziua, lumea!". Odată cu dezvoltarea sistemului, testele de fum devin mai profunde. Timpul petrecut pe primele teste de fum se calculeaza in cateva secunde, cu toate acestea, pe masura ce sistemul creste, cantitatea de timp necesara testarii fumului creste. La sfârșitul proiectului, testarea fumului poate dura ore întregi.
Definirea unui grup de asamblare
Adăugați revizuirea la ansamblu numai dacă are sens
De obicei, dezvoltatorii scriu codul în mod suficient suficient, astfel încât să puteți adăuga modificări semnificative sistemului în fiecare zi. Ei trebuie să lucreze pe cea mai mare parte a codului și să îl integreze în sistem la fiecare câteva zile.
Introduceți un sistem de sancțiuni pentru a întrerupe eliberarea următorului ansamblu (eliberarea nu este un ansamblu de lucru).
În cazul majorității proiectelor, există un sistem de sancțiuni pentru întreruperea eliberării unui alt ansamblu. La începutul proiectului ar trebui să fie clar că păstrarea proiectului de lucru este o sarcină de cea mai mare prioritate. Perturbarea eliberării unui alt ansamblu poate fi o excepție, dar nu ca o regulă. Insistați că dezvoltatorii părăsesc toate cazurile până când sistemul din nou nu funcționează. În cazul unei perturbări frecvente a ansamblului (eliberarea nu este un ansamblu de lucru), este dificil să reveniți la normal.
Amenzile minore subliniază gradul înalt de necesitate de monitorizare a calității construirii sistemului. La unele proiecte, dezvoltatorii, din cauza căruia ansamblul "cade", dau bomboane pentru eliberarea unui ansamblu nefuncțional. Pe ușa dulapului unui astfel de dezvoltator atârnă un semn corespunzător până când fixează ansamblul (cu condiția ca dezvoltatorii să aibă birouri separate :)). Vinovat pe alți dezvoltatori de proiecte trebuie să poarte coarne de capră artificiale sau de a face o anumită sumă de „fond moral“ (exemple sunt preluate din poveștile unor societăți reale).
Însă pentru unele proiecte sunt impuse sancțiuni mai grave. De exemplu, dezvoltatorii Microsoft, constând în proiecte cu prioritate înaltă (Windows NT, Windows 95, Excel), purtau pagini și, în caz de detectare, trebuiau să vină la lucru. Chiar dacă a fost detectată o defalcare sau o eroare la ora 3 am.
Strângeți sistemul și "fumați" chiar și sub presiune
Când crește presiunea din programul de lansare a proiectului, lucrul la o verificare zilnică a asamblării sistemului poate părea o pierdere de timp. Totuși, acest lucru nu este cazul. În situații de stres, dezvoltatorii fac adesea greșeli. Ei simt o astfel de presiune de necesitate de a lăsa implementări, care, în condiții obișnuite pur și simplu, nu sunt prezente. Ei își testează testele de unitate de cod mult mai puțin atent decât de obicei. În astfel de situații, codul tinde spre starea de entropie mult mai rapid decât în situații mai puțin stresante.
Oricare ar fi fost, asamblarea zilnică consolidează disciplina și menține tendința codificării spre starea de entropie sub control.
Cine beneficiază de acest proces? Unii dezvoltatori protestează împotriva adunărilor zilnice, justificând protestele lor din cauza impracticității acestei ocupații și a costurilor mari ale acesteia. Dar toate sistemele sofisticate de ultima oară au fost supuse ansamblurilor zilnice și testelor de fum. Până la lansarea sa, Microsoft Windows NT 3.0 conținea 5.6 milioane de rânduri în 40.000 de fișiere. Ansamblul complet a durat 19 ore și a fost efectuat pe mai multe calculatoare. În ciuda acestui fapt, dezvoltatorii au reușit să colecteze sistemul zilnic. Fiind o echipă profesionistă, echipa de dezvoltare a NT, succesul său se datorează în mare parte întâlnirii zilnice. Acei dezvoltatori care lucrează la proiecte mai puțin complexe și, prin urmare, nu profită de procesul de construire zilnică, ar trebui să se gândească la niște explicații rezonabile.
Trimiteți-le prietenilor: