Григорий Петров Как и защо да четем чужд код - AppTractor
Нека си спомним проблемите на развитието: портфейлът на Милър, липсата на фундаментално образование, липсата на разработени методи. Кодът, написан от разработчика, е отражение на неговите ментални модели, преминали през личния му опит в разработката. А опитът му е уникален, защото в университетите не се учи как се разработват програми. Те преподават математика, алгоритми, структури от данни. Алгоритъмът за подреждане ще е еднакъв за всички, както са учили в университета. Само тук в кода никой не пише сортиране. Те пишат малко по-различно, но това не се учи.
И това е само първият рейк. Има и втори. Тъй като кодът е отражение на умствения модел на разработчика, разработчикът в повечето случаи няма да хареса кода на някой друг! Когато чете кода на някой друг, умът ще се опита да го възприеме като свой, да го прекара през собствените си ментални модели. Но кодът не е книга. Естественият език позволява множество интерпретации на всяко изречение, така че повечето читатели, прекарали текста през призмата на своето възприятие, виждат всеки своя собствена картина. Всичко е различно с езика за програмиране: програмистът винаги ще види нечия друга картина, калъп от работата на някой друг ум. И няма да му хареса. Оттук и неприязънта на разработчиците да разбират кода на някой друг и инстинктивното желание да „пренапишат всичко от нулата“.
Разбира се, ситуациите са различни. За медицинския софтуер особено важните части от кода могат да бъдат прегледани ред по ред от няколко разработчици наведнъж - цената на грешка е твърде висока. Но в повечето случаи основната задача на прегледа на кода е да се избегне ситуация, в която опитен разработчик прекарва цялото си време в много внимателен преглед на кода на двама или трима младши и в края на деня гордо казва - „виж колко бъгове открих в теб!“. Намерих го, браво. Но колко струвашевреме и усилия? Заслужаваше ли си? Освен това не забравяйте за микромениджмънта – не можете да инсталирате мозъка си в главата на някой друг.
Автоматизацията на помощ
Удобно е да следвате просто правило: оставете автоматизацията да прегледа всичко, което може да бъде прегледано от автоматизацията. Остава човек да провери това, което автоматизацията не може да провери: как се чете кодът, доколко е разбираем, доколко архитектурата отговаря на идеите на ръководителя на екипа. Тогава и овцете ще са сити, и вълците ще са в безопасност, и пухкавата полярна лисица няма да тича толкова често.