Kur punoni në një ekip, zakonisht nuk keni nevojë të shpjegoni pse të gjithë duhet t'i përmbahen një stili të kodimit, deri te vendimet nëse duhet të vendosni një hapësirë ​​shtesë përpara kllapave dhe të përdorni thonjëza të dyfishta ose të vetme. Gjithçka është e qartë dhe e qartë. Por sapo ju duhet të vazhdoni një projekt pas një zhvilluesi tjetër apo edhe një ekipi të tërë, këtu fillon një makth.

Duke e bërë renë gri më gri, le të supozojmë se një projekt që ishte nën juridiksionin tuaj është shkruar nga disa ekipe në periudha të ndryshme. Në fillim ishte një ekip, kur ata shkuan, ekipi i dytë vendosi t'i bënte gjërat në mënyrën e vet, e kështu me radhë. Dhe pastaj projekti ju ka kaluar juve.

Gjëja më e keqe për këtë lloj projektesh është pasiguria. Puna në një projekt të tillë është si të komunikosh me personalitete të shumta të Billy Milligan: çdo herë është një mister i madh i asaj që të pret në rreshtin tjetër të rrëfimit. Çdo zhvillues i radhës që pengohet mbi gjithë këtë tmerr në kodin burimor përpiqet të zbatojë një veçori të re në një stil tjetër që i duket atij një zgjidhje më e mirë. Dhe kjo vetëm sa e rëndon situatën, sepse para tij projekti ishte shkruar në stile N dhe tani e tutje do të përfshijë N+1 stile të ndryshme. Dhe nuk ka rëndësi se sa të gabuar janë zhvilluesit e mëparshëm dhe sa i drejtë është ai aktuali.

Këtu janë disa rregulla për të punuar me projekte të tilla të trashëguara:

1. Një kërkesë e veçantë tërheqëse mund të përmbajë ose ndryshime logjike pa përditësuar stilin e kodit ose ndryshime të stilit në të gjithë projektin menjëherë pa shtuar veçori të reja. Për shembull, nëse nuk ju pëlqen përdorimi i përzier i kuotave të vetme dhe të dyfishta, bëni një kërkesë të veçantë tërheqjeje në të cilën standardizoni vetëm përdorimin e kuotave gjatë gjithë projektit. Por kur zbatoni detyrën aktuale të projektit, siç është shtimi i funksionalitetit, përdorni stilin e miratuar në projekt në kohën e shkrimit të kodit, pavarësisht nëse ju pëlqen apo jo.

2. Mos u mundoni të rifaktoroni kodin për të cilin nuk keni ende teste. Arsyeja duhet të jetë e qartë.

3. Shtimi i testeve dhe rifaktorimi i kodit duhet të vendoset në kërkesa të ndryshme tërheqëse. Sekuenca e veprimeve është që së pari të siguroheni që kodi të funksionojë siç pritej, dhe më pas të kontrolloni që rifaktorimi nuk ka prishur asgjë në këtë sjellje. Kjo nuk është e njëjta gjë si shkrimi i testeve dhe ndryshimi i sjelljes së aplikacionit në të njëjtën kërkesë tërheqëse.

4. Nëse ndjeni një nevojë të madhe për të rifaktoruar kodin gjatë rregullimit të një defekti, atëherë duhet të ndiqni sërish artikullin e tretë të kësaj liste. Së pari, shkruani teste, pastaj - rifaktorim, dhe vetëm pas kësaj - rregullime. Ose, së pari - teste, pastaj - rregullime, pas tyre - përsëri teste, dhe më në fund, rifaktorim. Dhe sigurisht, rifaktorimi duhet të shkojë në një kërkesë tërheqjeje të veçantë, dhe një nga këto sekuenca duhet të ndiqet.

5. Përdorni formatimin automatik të stilit të kodit. Si rregull, të gjitha stilet janë të personalizueshme dhe është e mundur të diktoni grupin tuaj të rregullave me skedarin e konfigurimit pikërisht brenda projektit për të gjithë pjesëmarrësit e ekipit. Kjo duhet të bëhet, natyrisht, jo më herët se sa të rifaktoni mjaftueshëm të gjitha pjesët e kodit dhe një formatim i tillë automatik nuk do të ndryshojë skedarët ekzistues.

6. Përpara se të bëni një kërkesë tërheqjeje me +100000 dhe -100000 ndryshime rifaktorimi në rreshtat e kodit, ku korrigjoni të gjitha të njëjtat lloj citatesh, shkoni rreth kolegëve tuaj dhe sigurohuni që nuk do t'i prishni jetën dikujt me një përditësim të tillë. Ndoshta disa prej tyre kanë punë aktuale të papërfunduar dhe do t'ju duhet të zgjidhin konflikte të shumta pas bashkimit tuaj. Do ta keni shumë më të lehtë t'i zgjidhni këto konflikte në vend të tyre.

7. Veproni gradualisht. Mos u përpiqni të korrigjoni gjithçka dhe kudo menjëherë. Filloni pak dhe, le të themi, bëjeni zakon të bëni një hap të vogël drejt standardizimit të kodit së bashku me kafenë e mëngjesit. Nuk do të marrë shumë kohë dhe kërkesat ditore për tërheqje të vogla do ta bëjnë të mirën e tyre brenda dy javësh.

8. Ndani qëllimet tuaja me kolegët tuaj dhe sigurohuni që të jeni në të njëjtën faqe me ta. Nëse nuk duan t'ju ndihmojnë në këtë proces standardizimi, atëherë të paktën kërkoni që të mos ndërhyjnë dhe t'i pranojnë këto rregulla. Për shembull, nëse e njihni projektin tuaj në shembullin e mësipërm, thjesht dërgojini atyre një lidhje për këtë artikull dhe filloni ta bëni jetën tuaj pak më të mirë. Nëse nuk jeni dakord me disa nga deklaratat, mos ngurroni të ndani kundërargumentet me ne.

Botuar fillimisht në riter.co.

Çfarë të lexoni më pas:

  1. "Vlerësimi i saktë i kohës në zhvillimin e softuerit"
  2. "Gabimet më të zakonshme të ekipit të zhvillimit të softuerit"
  3. "Vështirësitë e planifikimit dhe vlerësimit të projektit"
  4. "Hyrja në programim: Gjërat që duhen shmangur"
  5. "Metodologjitë: Kur kemi nevojë për to?"