standarde corporative sau mama anarhie

Rezumat :. companii (și de multe ori de comanda), la un moment dat încearcă să lucreze în acorduri și standardele lor privind structura și proiectarea codului Multe / documente ale procesului de dezvoltare, utilizarea de instrumente, etc. In majoritatea cazurilor nu au nevoie de ea. Dar dacă vrei, cum?

Standarde și acorduri (ASIC) pot fi împărțite astfel:

SYS scrierea de cod

CoCo privind proiectarea și livrarea

SYS UI design (aplicații UI și documente)

Unii ar putea crede că CoCo este proporțională cu mărimea companiei, spun ei, decât este mare, mai mult „birocrația“. Pentru a spulbera acest mit, iată câteva exemple de locuri de muncă mele:

15K aplicatii). Există documente SYS UI și aplicații de pe cadrele posibile și biblioteci, precum și de curs ar trebui să arate binar.

Mesto2 (cifre similare:

15K aplicatii). Nu COCO decât pe documentele de înmatriculare.

Mesto3 (> 1K om

20 de cereri). Acolo SYS: documentația de birou, instrumente și procesul de asamblare, procesul de artefacte de verificare a versiunilor de baze de date aplicație care stochează codul versiunilor, configurare, aplicatii, procese de eliberare.

Complica introducerea de noi oameni. pentru că standardele corporative difera una de alta, în diferite companii (echipe), omul nou care a venit la tine în proiect, va trebui să-și petreacă eforturile în a se alătura procesului. Va trebui să-i explice cum se face asta, apoi verificați. Ei bine, pentru a simplifica procedura, desigur, aveți nevoie pentru a descrie CoCo dumneavoastră.

Diferite echipe se potrivesc stil diferit. Dezvoltarea multora - procesul de creație, și mediatorii de metodologii moderne (Agile) susțin că procesul trebuie să fie adaptate la nevoile lor specifice, fără a complica cu nici o nevoie reală. Prin urmare, creând un standard corporative, care ar trebui să se supună tuturor, vă va înrăutăți probabil eficacitatea echipelor și / sau persoane fizice specifice, acest proces ei pur și simplu nu vor fi potrivite.

Ai nevoie pentru a menține standarde. Aceasta este o mare, și că este de asemenea important - o bucată de muncă obositoare. Sunt oameni care nu înțeleg pe deplin documentul, sau poate găsi bug-uri, incompatibilitatea cu anumite situații. Și totuși - într-un an, s-ar putea obține o opinie diferită, standardele vor trebui să actualizeze, și apoi re-implementat.

Standardele variază în funcție de oameni. Acum, aceste CoCo să dezvolte și totul se întâmplă ca de obicei, dar tu du-te pe site-ul dvs. va veni la altcineva cu o opinie diferită de a ta. Întreaga confuzie este probabil să înceapă din nou. A fost în valoare de ea?

Se face mai ușor să se rotească oameni. De obicei, este un argument prea rău (deși cred că apare cel mai des). În primul rând, oamenii de multe ori nu doresc să se rotească pentru a schimba situația, pentru a încerca noi abordări, care a fost plictisitor. Și aici ești cu unificarea lor. În al doilea rând, din nou, diferite modele și cerințe pot fi, de asemenea, diferite. Dacă, de exemplu, utilizate cadre unifitsiruete și tehnologie, puteți complica foarte mult eficienta de dezvoltare, de exemplu, vor exista probleme cu performanta sau arhitectura, oamenii vor trebui să introducă o pereche de cârje de dragul unificării.

Interfața între echipe. Dezvoltarea poate suporta mai multe comenzi, de exemplu, mediile gestionează echipa DevOps separate sau aplicația dvs. testează o echipă separată de asigurare a calității, sau eliberarea produsului orice oameni la stânga sau pe cineva pentru tine ajustează CI, sau ... Pentru aceste comenzi, nu poți fi numai ei pot schimba, deoarece 10yu proiecte. Și dacă fiecare dintre aceste proiecte - este unic, comenzi astfel de servicii vor suferi și să lucreze ineficient. Ie Ar fi rezonabil, dacă o astfel de echipă pentru a scrie un document, care va fi urmat de toate celelalte. Ca un exemplu, echipa CI poate cere ca toate lucrat doar cu Maven.

Că produsele au fost similare pentru clienți. Uneori, da, există o cerință că produsele au fost similare în ceea ce privește interfața de utilizare, astfel încât utilizatorii să înțeleagă că acest lucru este unul și același furnizor sau de una și aceeași resursă.

Reducerea numărului de sprijin în viitor. În cazul în care echipe diferite dețin un singur instrument (Nexus, JIRA, CI, etc.), astfel încât se poate întâmpla ca acestea sunt toate diferite și-l înființat la un moment dat se va prăbuși. Pentru acest lucru nu sa întâmplat, sau fiecare echipă trebuie să aibă propriile lor instrumente, sau ar trebui să se gândească la acordurile generale.

Există expertiză. Să avem un instrument care un nivel foarte bun de oameni posedă N. Și este posibil să se utilizeze o InstrumentB alternativă ieri vahtersha a spus despre ea. Este clar că orice instrument nu este perfect, dar având în vedere condițiile de utilizare InstrumentB - prin urmare, crește riscul. Da, vrem o schimbare. Da, adevărul înțelege comparația. Desigur că are sens să experimenteze dacă acest lucru contribuie la situația, dintr-o dată InstrumentB ar fi mult mai convenabil. Dar este important să nu exagerați, un nou instrument / cadru pentru proiectul - suficient pentru a nu uita de hemoroizi dulci. În spatele acestui fapt, dacă aveți expertiza în cadrul companiei, este logic dacă toate echipele vor utiliza capacitățile instrumentului.

Din moment ce v-ați decis să standardizeze pe ceva în biroul său, iată câteva sfaturi.

Posibilitatea să nu urmeze standardul nu ar trebui să fie. Pentru acest mare în cazul în care sunt automatizate toate controalele. Vrei să se angajeze mesaj începe cu ID-ul problemă? Asigurați-un cârlig care verifică formatul și respinge commit în cazul în care nu îndeplinește standardele. Codul ar trebui să urmeze convențiile? Reglați testul, care va aduce în jos ansamblul în cazul în care normele nu sunt respectate. În cazul în care există un standard doar cu numele / în document, acesta va fi întotdeauna cineva care nu-l va urma. Acest lucru creează riscul ca oamenii vor petrece timpul în judecată și explicații, și nu-l doresc deja a treia oară. La un moment dat, începe să înscrie toate.

Separat, aș dori să menționez aici timpul petrecut de logare. Este, de asemenea, un fel de acord, standardul în legătură cu procesul în cazul în care managerul de proiect, de exemplu, cere ca fiecare să sărbătorească cât de mult timp a fost cheltuit și pe ce. De ce este o idee proastă poate fi citit aici.

În acest caz, criteriul va fi după cum urmează: în cazul în care echipa va fi de a adera la regulile stabilite după inițiatorul a plecat în vacanță, astfel încât standardul nu a fost pus în aplicare cu succes și aceste reguli nu se pretează la punerea în aplicare a prezentului și încercați să nu chiar merita.

Modalitati de a automatiza de testare:

Maven Enforcer Plugin

Extras. verifica pe server CI

Ar trebui să fie posibil pentru a ocoli restricțiile. Acest lucru este contrar la articolul anterior, dar uneori, în unele situații critice, încă util să aibă o soluție. Aici știu că nu este neapărat toate :)

Feedback de automatizare ar trebui să fie informativ. Ie În cazul în care o regulă este rupt și autentificarea eșuează, un mesaj de eroare ar trebui să conțină o explicație, propunere (cum să se stabilească situația), eventual, o referință pentru a adăuga. resurse și, în cel mai rău caz, pentru a contacta persoanele care pot sfătui.

Pentru dezvoltarea și menținerea unor standarde necesită oameni dedicați. Asta este, dacă într-adevăr doriți să le urmeze. Pentru că aici lucrează foarte mult, este foarte posibil ca astfel de oameni ar trebui să fie o echipă întreagă. Dacă urmați standardele nu este critică. A se vedea elementul următor.

Orientarea - standarde mai favorabile. Orientarea diferă de standardele fără caracter obligatoriu. Puteți descrie unele pentru proiecte / cerințe de proces, dar numai în calitate de consilii, spun ei, ar fi mai bine și mai ușor pentru toată lumea să le urmeze este de dorit, dar nu este necesar. De exemplu, introduceți Atlassian, care au orientarea UI. Cele mai multe, este demn de remarcat au urmat, luând în considerare chiar că în urma acestor reguli, nici unul controale.

Utilizați instrumentele oficiale de practică. Mai ușor de a scrie documentele lor, și de a folosi descrise deja acordul privind site-ul instrumentului în sine. Astfel de acorduri, dezvoltatorii vor putea folosi în alte proiecte și în alte companii. Aceasta este o modalitate buna de a standardiza peste tot.

Pro-uri în acest caz este faptul că zamarachivatsya privind introducerea acestor reguli va trebui să fie mult mai mici. Iar ideea mulți îi vor urma, cel puțin într-o anumită măsură, fără lovituri.

Concluzii. ca și în cazul în care unii nu au vrut să unifice toate - să-l facă până la capăt, nu toată lumea poate. Prin urmare, orientarea, sau sunt în curs de dezvoltare, sau să fie pregătiți să dedice unificarea toată munca lui, sau pregătiți-vă pentru care să respecte standardele si acordurile ar fi un grup mic de oameni.