Необходими ли са прегледи на кодове? Не преглеждаме ли вече кода едновременно с разработването? Ако вече използвам рефакторинг като обичайна практика, какъв е смисълът да проверявам кода отново?
Има много въпроси, които могат да възникнат в екип от разработчици във връзка с рецензии на кодове. Но дори по-лошо от въпросите са притесненията или опасенията („ако моят код бъде преработен, работата ми ще бъде разрушена!“). На първо място, ще започнем с определяне на това, което е преглед на кода (преглед на кода).
Определение на прегледа на кода
Нека започнем от сценарий, в който работим в гъвкава рамка, и в рамките на различните опции, нека изберем Scrum. Целта на тази публикация не е да се задълбочавам в работата на тези методологии. Въпреки че е възможно в бъдеще да говоря повече за тях, Интернет е пълен с информация за тях; Специално препоръчвам блога на Хавиер Гарзас.
Необходимо е да се създаде първоначална рамка за намиране на начина, по който подхождаме към разработката на софтуера. В Scrum „единицата за разработка“ е историята на потребителя, а единицата време е спринтът.
Нека си представим тогава, че екип от 4 разработчици трябва да раздели развитието на няколко потребителски истории през спринт. Нека си представим, че на самостоятелен разработчик (да го наречем Луис) е назначена потребителска история X (например „Създаване на слой за устойчивост на данните“).
Прегледът на кода е процесът, чрез който останалата част от екипа преглежда заедно изпълнението на Луис за тази потребителска история, като предлага идеи за това как да се подобри, може би да го рефакторира, откривайки възможни грешки, архитектурни грешки, липса на покритие на теста за определени случаи и множество други неща, които могат да възникнат.
Нежелание ...
Нека бъдем директни: „сложните“ профили изобилстват в нашата професия. Без да навлизат в твърде много подробности, някои разработчици не са отворени за критика, още по-малко да модифицират код, който са попълнили и на теория работи. Ако някой от читателите принадлежи към тази група, бих им задал следните въпроси:
- Лесно ли е да разберете кода си за някой друг, освен вас?
- Бихте ли били в състояние да разберете този код след няколко години?
- Взели ли сте предвид ВСИЧКИ фактори, които влияят или могат да повлияят на системата при разработването на вашия код?
- Ако сте открили явна грешка в кода на някой друг, не смятате ли, че отговорността ви като професионалист е да я поправите? В този случай не е ли по-добре да откриете такива грешки възможно най-скоро?
Колективност на кодовете. Кодът не е мой
Всъщност, когато работим по бизнес проект, ние програмираме код, който ще продължи да се разработва, подобрява и поддържа от добра шепа разработчици и в бъдеще. Мисля, че в такава област няма смисъл да се говори за индивидуална собственост на кода, а напротив.
Колективното притежаване на кода насърчава пъргавия екип да поеме отговорност за работата на абсолютно цялата доставена система. Нищо, което да сочи с пръст виновниците, когато нещо не работи, или да предполага, че „не бях“ или „не бях там“. Бих казал, че нещо подобно е очевидно ... но изобщо не е така.
Опитът ме научи, че прегледите на кодове са най-ефективният начин за постигане на този идеал.
Процеса
Процесът на преглед на кода започва, когато разработчикът ще качи или вече е качил в централното хранилище (предполагаме, че използваме Git или подобен инструмент за контрол на версиите) всички промени, свързани с внедряването на историята на зададените потребител.
Останалата част от екипа (в нашия пример останалите трима разработчици) или останалите поне 50% (в примера минимум 2) ще прегледат всички промени в кода, които ще бъдат добавени към системата, и чрез коментари В приятелска и неформална среда те ще предадат своите съмнения относно определени решения, предложения за подобрение и, разбира се, „палци нагоре“ по отношение на идеи, които могат да бъдат блестящи или особено успешни. Тези коментари трябва да бъдат съсредоточени върху обхващането на няколко от проблемите, които повдигнах в този пост, а ползите са няколко и очевидни:
- Открийте инструменти, API, начини за справяне с проблем ..., който не знаехме
- Получавам глобални познания за системата (не само за частите, които разработвам)
- Донесете външни гледни точки и повдигнете въпроси, които може да са били пренебрегнати от водещия разработчик
- Подобрете качеството и четливостта. Понякога работата на парче код, което може да е много очевидно за създателя му, не е толкова очевидно за другите
- Постигнете дългоочакваната "кодова общност"
Разбира се, не всички коментари от останалата част от екипа могат да бъдат точни и това зависи Целият екип постигнете консенсус относно действията, които трябва да се предприемат след приключване на прегледа. Като цяло винаги ще има промени, които да се прилагат. В настоящата ми компания приемаме за даденост, че след „Преглед на кода“ винаги ще има задача „Промени след преглед на кода“ и ние винаги добавяме оценка на тези задачи към общата история на потребителя. Всъщност никога не се затваряме (Свършен) потребителска история, докато не премине през преглед на кода.
Его трябва да остане паркирано, когато провеждате преглед на кода. Ние не участваме в състезание за намиране на най-умния програмист, ние искаме само нашият продукт да бъде с най-високо качество.
Резултатът
Наистина харесвам тази формула (открих я във видеоклип на Atlassian, който не успях да намеря отново):
- G: ниво на индивидуална вина на грешка, открита в производството
- R: брой хора, които са прегледали засегнатия код
Поради това правим извода, че ако даден код не е прегледан от никого, само един човек ще бъде отговорен за неизправност в производството. Докато ако целият екип прегледа кода, вината се разпределя върху целия екип. Не сме ли постигнали търсената „колективна собственост на кодекса“?
Инструменти
Преглед на кода може да се извърши чрез събиране на екипа в стая или чрез използване на инструмент, създаден за тази цел. На пазара има няколко, както с отворен код, така и за търговски, за извършване на прегледи на Code. В тази връзка са изброени няколко от тях. Аз лично съм работил с Crucible от Atlassian, който се интегрира добре с останалата част от Atlassian suite (JIRA за управление на задачи, Stash като хранилище на Git код и т.н.) и позволява стартиране на разговори от ред код, блок, добавяне на общо коментари и т.н.:
Моят личен опит
Смея да кажа, че съм много по-добър професионалист, тъй като съм част от екип, който постоянно използва прегледи на кодове. Не само за всичко, което се научава, когато вашият код е подложен на тест или когато трябва да прегледате кода на другите, което ви кара да развиете критичен и аналитичен дух, който не бихме използвали толкова ясно при други обстоятелства.
Има още един „неудобен“ фактор, който трябва да се каже, и той е, че знаейки предварително, че вашият код ще бъде ревизиран, ние програмираме по-добре:). Някои пороци или придобити практики, за които със сигурност знаем, че не са правилни, но които е малко мързеливо да се избягват, определено са в ъгъла, когато имаме преглед на кода на хоризонта.
Заключения
Точно вчера завърших проект, по който работя от 11 месеца (всъщност днес започвам почивката си:)), след като през това време завърших 75 прегледа на кода. Мисля, че това е най-висококачественият продукт, който съм доставял досега, и бих го запалил напълно. Сигурен съм, че останалите разработчици на проекти мислят по същия начин като мен. Без „Прегледи на кодове“ никога не бихме постигнали толкова високи стандарти, дори отдалечено.
Опитайте рецензии с кодове, никога няма да се върнете.