Прегледи на кодове
Необходими ли са прегледи на кодове? Не преглеждаме ли вече кода едновременно с разработването? Ако вече използвам рефакторинг като обичайна практика, какъв е смисълът да проверявам кода отново?
Има много въпроси, които могат да възникнат в екип от разработчици във връзка с рецензии на кодове. Но дори по-лошо от въпросите са притесненията или опасенията („ако моят код бъде преработен, работата ми ще бъде разрушена!“). На първо място, ще започнем с определяне на това, което е преглед на кода (преглед на кода).
Определение на прегледа на кода
Нека започнем от сценарий, в който работим в гъвкава рамка, и в рамките на различните опции, нека изберем Scrum. Целта на тази публикация не е да се задълбочавам в работата на тези методологии. Въпреки че е възможно в бъдеще да говоря повече за тях, Интернет е пълен с информация за тях; Специално препоръчвам блога на Хавиер Гарзас.
Необходимо е да се създаде първоначална рамка за намиране на начина, по който подхождаме към разработката на софтуера. В Scrum „единицата за разработка“ е историята на потребителя, а единицата време е спринтът.
Нека си представим тогава, че екип от 4 разработчици трябва да раздели развитието на няколко потребителски истории през спринт. Нека си представим, че на самостоятелен разработчик (да го наречем Луис) е назначена потребителска история X (например „Създаване на слой за устойчивост на данните“).
Прегледът на кода е процесът, чрез който останалата част от екипа преглежда заедно изпълнението на Луис за тази потребителска история, като предлага идеи за това как да се подобри, може би да го рефакторира, откривайки възможни грешки, архитектурни грешки, липса на покритие на теста за определени случаи и множество други неща, които могат да възникнат.
Нежелание ...
Нека бъдем директни: „сложните“ профили изобилстват в нашата професия. Без да навлизат в твърде много подробности, някои разработчици не са отворени за критика, още по-малко да модифицират код, който са попълнили и на теория работи. Ако някой от читателите принадлежи към тази група, бих им задал следните въпроси:
- Лесно ли е да разберете кода си за някой друг, освен вас?
- Бихте ли били в състояние да разберете този код след няколко години?
- Взели ли сте предвид ВСИЧКИ фактори, които влияят или могат да повлияят на системата при разработването на вашия код?
- Ако сте открили явна грешка в кода на някой друг, не смятате ли, че отговорността ви като професионалист е да я поправите? В този случай не е ли по-добре да откриете такива грешки възможно най-скоро?
Колективност на кодовете. Кодът не е мой
Всъщност, когато работим по бизнес проект, ние програмираме код, който ще продължи да се разработва, подобрява и поддържа от добра шепа разработчици и в бъдеще. Мисля, че в такава област няма смисъл да се говори за индивидуална собственост на кода, а напротив.
Колективното притежаване на кода насърчава пъргавия екип да поеме отговорност за работата на абсолютно цялата доставена система. Нищо, което да сочи с пръст виновниците, когато нещо не работи, или да предполага, че „не бях“ или „не бях там“. Бих казал, че нещо подобно е очевидно ... но изобщо не е така.
Опитът ме научи, че прегледите на кодове са най-ефективният начин за постигане на този идеал.
Процеса
Процесът на преглед на кода започва, когато разработчикът ще качи или вече е качил в централното хранилище (предполагаме, че използваме Git или подобен инструмент за контрол на версиите) всички промени, свързани с внедряването на историята на зададените потребител.