код инспекция

Код инспекция - това е добре. Ние използваме тази техника в техните проекти не е толкова отдавна - около три месеца - но положителните резултати са очевидни. Ние вече говорихме Хабре за изпълнението на проверки в процеса на развитие. За работния процес по време на инспекции. Ние говорихме за това как можете да оптимизирате процеса на проверка с инструмент Код сътрудник. Днес ние искаме да се обобщи и да представи резултатите, които ние, постигнати по време на инспекцията. Да вървим.

В действителност, много предимства, така че ние трябва да споменем само няколко големи в тази тема.

Тя беше установена обща кодиране стил. Разбира се, дори и преди изпълнението на проверката е имало някаква идея на екипа ни за това какво е добро и какво е лошо, когато всички се опитваха да следват. Въпреки това, поради цялостния стил на инспекцията накрая бе усъвършенствано и всъщност "държи в главата си" за всеки предприемач.

Парк велосипеди възстановява по-бавно. По-рядко има ситуации "Аз дойдох с блестящо решение", както и все по-често ние използваме доказани решения от библиотеки на трети страни. Имаше един интересен ефект на "колективното знание", когато един член на екипа е наясно с отделна библиотека нещо, което другите не знаят, и предлага оптимално използване на най-добрите си качества.

Подобрена общата собственост код. Има още живо диалог по различните аспекти на проекта: защо се прави по този начин, а не в друг? Може би трябваше да направя по този начин? В резултат на това разбиране за това как различните части на системата да работи, той е равномерно разпределена сред разработчиците, вместо да се концентрира някой такъв.

За да се засили обменът на опит и знания. Сега ние често използват при разработването на успешни методи и колегите практика реализира в други части на системата. Такъв опит, по наше мнение, могат да се предават само чрез четене на код на други хора: друг начин просто не съществува. Така или метод ще трябва да "оцелеят" най-много, само тогава тя може да направи "своя" господар. За такъв "гмуркане" няма нищо по-добро от един добър пример за код на някой друг от познатия домейн: тя е много по-ефективен от абстрактни геометрични фигури като примери, кръг, и кутия.

Базата код е станало по "придружен". Ето и списък с подобрения:

вълшебните константи са блокирани инспектори;
намалява код дублиране (сух);
алгоритми са опростена (КИС);
клас документация и публични методи подобриха значително (инспектори почти всяка обществена класа и метода, трябва да добавят документация);

Единственият недостатък на въвеждането на инспекция код - удължаване на времето на развитие. В началния етап от време изпълнение се увеличава с 50-100% (понякога и повече понякога), но в крайна сметка в една обща хранилище далеч по-малко лошо качество код, по-малко "шлака".

В момента, след първоначалното отстраняване на грешки на всички процеси, допълнителни разходи, време е намалял с около 20-50%. Основната вълна, свързана с плиска отбор на общ стил кодиране; много време са били изразходвани за приемането на общи практики и техники. За опитни екипи, по наше мнение, нормалното увеличаване на средното време за развитие - 10%.

Този термин е често срещана в английската литература и е в действителност, на бележка инспектор - контролен лист за улесняване на процеса на проверка.

Контролен лист по-добре да се създаде за всеки проект и за всеки отбор, тъй като тя може да варира значително в зависимост от платформата, библиотеки, архитектурни решения. В същото време, със списък се развива и започва да се срещнат по-пълно на настоящите цели на проекта.

Обобщавайки опита, придобит от проверка, ние започнахме да се разбере как да се направи списък. Ето списъка ни в момента.

Контролен лист - бележка инспектор Положителни Technoligies

1. точността на изпълнението на предметната област.

Функционалност се изпълнява в пълен размер.
Спазването на спецификации.
Fidelity предварително определен константи.
Валидността на предположенията и конвенции.
Вярно обработка на последователност.

3. съществуването и пълнотата на тест покритие.

Всички публични класове и методи са тествани.
Тестван на граничните условия.
Достатъчност тест "производителност положителни клонове.
тест за достатъчност "негативна клон" изпълнение.

4. Необходимо е да се добави към своята касичка добри практики от код на други хора.

5. Коректност многонишков код.

Достъп до споделени данни се синхронизират.
Не мъртвите зони.
За синхронизация език RAII.
Правилно се справят с връщането на средства за манипулатор грешка.
Не изтичане на ресурси.

6. код дръжки грешки правилно.

7. Не очевидни странични ефекти в други части на системата.

8. Коректност на езикови конструкции.

Нанесете на правилното мислене на по-използван език и рамката.
Използването на правилните библиотеки.
Липсата на новоизобретените "велосипеди".
Non-дублиране на код.

9. Всички променливи се инициализират с точните стойности.

Може би нашият списък ще ви помогне да направите правилния за вашия проект.
Трябва да се отбележи също така още един много важен момент. За проекти, които не разполагат с единица тестове, проверка - е, общо взето, единственият ефективен метод за предотвратяване на дефекти в кода. Поне нищо друго идва на ум. Ето защо, ако вашият проект не е единица тестове, първо трябва да се приложи на проверката и едва след това - практиката на писане единица тестове.

Така че, защо са толкова ефективни проверки? Често, дизайна или кода от строителя в някакъв момент "очи zamylivaetsya", умът е здраво свързана с конкретно решение дизайн или определена част от кода. Проверка е един лесен начин да се позова на колективната интелигентност, която има по-голяма гъвкавост и свобода - ". Две глави са по-добре" на принципа на

Благодаря ви за вниманието! Желаем ви приятни проверки :)