Тема: Как оценить качество кода в цифирном выражении

Интересно, можно ли как-то разумно оценить качество кода в цифирном выражении. Не примите меня за идиота (хотя я бы принял по дефолту), но хочется определить какие-то параметры кода, которые позволили бы особо в него не лазя понимать, что в нём не всё ладно.

Цель простая: отдать готовый код размером примерно в 3 Мб и полторы тысячи файлов разработчикам-наймитам и тратить минимум времени на контроль качества того, что получается. Хочется иметь некоторую рутинизацию процесса контроля.

Что пока наклюнулось:

1. требование к форматированию кода PSR-0, -1, -2, -3;

2. ограничение на количество строк в методе 50-ю штуками;

3. контроль за средней длиной имён методов, членов, классов и переменных (без this);

4. контроль за средним размером класса в строках;

5. наличие PhpDoc-комментариев на каждый метод (параметры и возвращаемое значение: тип и наименование) и член (тип переменной);

6. предельный размер методов (в строках) в контроллерах;

6.1. подозрительное отношение в контроллерах к приватным и защищённым методам;

6.2. отсутствие публичных методов без роутинга;

7. контроль предельного размера класса команды (в строках);

8. наличие в контроллерах только переопределяемых методов;

9. сквозная автоматическая проверка кода на копипаст;

10. наличие в сущностях только коротких методов, за исключением addXxxx, конструктора и функций жизненного цикла;

11. наличие и срабатывание функциональных тестов на все роутинги;

12. наличие и срабатывание функциональных тестов на каждый внешний метод API;

13. наличие и срабатывание сквозного функционального теста на всю подсистему сбора и агрегации статистики.

Что происходит при таком раскладе:

1. у меня уверенно работает каждая страница сайта, апи и статистика;

2. я защитился от говнокода в контроллерах, сущностях и командах (90% руководителей разработки уже завидуют);

3. часть говнокода не рассосётся, а перекочует в модели и репозитории;

4. этот говнокод я пытаюсь задавить проверками на длины переменных и методов, на дублирование кода, на размер методов в строках и т.д.;

5. я понимаю, что последнее мне не очень удастся - использование паттернов слишком мозгоёмко, чтобы так просто наёмного человека выдавить на их использование.

Что посоветуете?

2

Re: Как оценить качество кода в цифирном выражении

Странник пишет:

ограничение на количество строк в методе 50-ю штуками;

Как звоночек — пойдет, как жесткое требование нет. Объем метода определяется сутью выполняемой им операции. Разбивать специально метод, выполняющий одну операцию, только потому, что он слишком длинный, глупо.

Странник пишет:

3. контроль за средней длиной имён методов, членов, классов и переменных (без this);

Длина — это конечно хорошо, но главная проблема названий в безграмотности и несоответствии сути. И вот с проверкой этого все очень, крайне сложно.

Странник пишет:

4. контроль за средним размером класса в строках;

Очень сомнительный пункт. default/smile Т.е. как "звоночек" пойдет, но как требование — нет.

Странник пишет:

5. наличие PhpDoc-комментариев на каждый метод (параметры и возвращаемое значение: тип и наименование) и член (тип переменной);

Еще бы актуальность. Проблема в том, что наличие неактуального PhpDoc'a гораздо хуже, чем его полное отсутствие, поскольку вводит разработчика в заблуждение. По факту же, большинство копипастеров любят скопипастить метод вместе с доком, метод изменить, а док естественно оставить. И появляются потом монстры с 40 методами, называющимися "Get user name".

Странник пишет:

7. контроль предельного размера класса команды (в строках);

Тоже непонятно зачем. default/smile Ну т.е. можно конечно специально рефакторить объемные наборы команд и выносить часть функциональности в отдельные подключаемые классы, но не обязательно. Хотя класс в 10к строк я бы конечно разбил, чтобы не тратить время на поиск в нем.

Что касается тестов... Я придерживаюсь стратегии, когда тестами покрывается только бизнес-логика. Писать тесты на контроллеры мне лично лениво. Хотя в целом, тесты на контроллеры дадут уверенность в работоспособности "конечной точки", так что вариант вполне годный.

В общем, способы автоматически определить качество кода мне неизвестны. Какую-то часть треша можно отсеять проверками из списка выше и проверкой на антипаттерны/статистику (аля количество создаваемых переменных в методе или частоту использования if/else). Херовую алгоритмику, безграмотность и прочие проблемы кода можно выявить только через ручное код-ревью.

P.S. Еще я бы активно использовал профайлинг, но в похапе с ним все сложно. Для взрослых языков существуют хорошие анализаторы кода, выявляющие большинство грубых и не очень ошибок, в том числе алгоритмических.

Re: Как оценить качество кода в цифирном выражении

По остальному я ещё буду думать, по некоторым пунктам напишу:

relo_san пишет:

Что касается тестов... Я придерживаюсь стратегии, когда тестами покрывается только бизнес-логика. Писать тесты на контроллеры мне лично лениво. Хотя в целом, тесты на контроллеры дадут уверенность в работоспособности "конечной точки", так что вариант вполне годный.

Не столько на контроллеры, сколько на итог - то есть на то, что видит юзер. То есть это уже после обработки твигом. Цель - знать, что всё работает, а не в какой точке поломалось. Тестами лично я покрываю только сложные участки логики плюс описанное выше. Покрытие всего остального удваивает стоимость кода.

relo_san пишет:

Херовую алгоритмику, безграмотность и прочие проблемы кода можно выявить только через ручное код-ревью.

Не верю я в код ревью. Не зря оно не прижилось в России. В США есть неявная предпосылка для успешности этой рутины - там есть внутренняя конкуренция сотрудников друг с другом. В России (Украине, Беларуси) внутренняя конкуренция подавляется самими же работниками и они быстро начинают покрывать промахи друг друга. Возможно поэтому я не натыкался на хорошие опыты использования ревью кода. Архитектор, зараза, тоже традиционно будет покрывать промахи своей команды. То есть вменяемый регулярный код ревью может делать только руководитель конторы, а мне лениво тратить на это уйму времени.

relo_san пишет:

P.S. Еще я бы активно использовал профайлинг, но в похапе с ним все сложно.

Кстати да, если поставить пинбу, то продакшн-сервера покажут, где накосячили по производительности. Как-то я забыл про неё.

4

Re: Как оценить качество кода в цифирном выражении

Странник пишет:

В России (Украине, Беларуси) внутренняя конкуренция подавляется самими же работниками и они быстро начинают покрывать промахи друг друга. Возможно поэтому я не натыкался на хорошие опыты использования ревью кода. Архитектор, зараза, тоже традиционно будет покрывать промахи своей команды.

Тот, кто делает ревью кода, во-первых, должен иметь достаточную квалификацию, и (самое главное) во-вторых, должен нести ответственность за качество кода, который он проверил. Если архитектор покрывает промахи своей команды, он своими руками подписывает себе профнепригодность. Потому что первая же независимая выборочная проверка ранее проверенного им кода поставит вопрос о целесообразности занимания им своей должности и получения зарплаты. А периодически выборочно проверять 5% кода силами независимых аудиторов и получать от них аргументированные отчеты не должно быть проблемой.

P.S. Я в свое время реализовывал идею подписывания классов. После проверки класса ревьюирующий добавляет два тега в его PhpDoc — общая оценка и кем проверено, и результат загоняет в систему версионного контроля. Отвертеться потом очень сложно.

5

Re: Как оценить качество кода в цифирном выражении

Странник пишет: пишет:

В России (Украине, Беларуси) внутренняя конкуренция подавляется самими же работниками и они быстро начинают покрывать промахи друг друга. Возможно поэтому я не натыкался на хорошие опыты использования ревью кода. Архитектор, зараза, тоже традиционно будет покрывать промахи своей команды.

А якщо наприклад  код не проходить перевірку, і він поганий, то розробник несе якусь фінансову чи іншу відповідальність? Я думав завжди що ревю коду, в інтересах не тільки проекту, а й самого розробника, бо він може навчитись таким чином писати адекватний код,  який же програміст хоче писати поганий код default/smile

6

Re: Как оценить качество кода в цифирном выражении

Лiнивий та безвiдповiдальний default/wink А таких, нажаль, дуже багато...

7

Re: Как оценить качество кода в цифирном выражении

denys281 пишет:

який же програміст хоче писати поганий код

Слишком наивно. default/smile Тот программист, который действительно хочет писать хороший код, таки выучивается и пишет его. Но большей части программистов насрать, какой код они пишут. Их волнует, чтобы было как можно меньше проблем на работе и зарплата без задержек в конце месяца. А качество кода для них определяется одним фактором: работает или не работает. Таких большинство, и это нужно учитывать.

Без четко оговоренной ответственности за некачественные проверки кода или намеренное скрытие проблем толку от код-ревью действительно не будет. Ну или должна идти речь об очень строгой корпоративной культуре, но построить оную — значительно более трудоемкая задача.

Re: Как оценить качество кода в цифирном выражении

denys281 пишет: пишет:

який же програміст хоче писати поганий код

Так они уверены, что пишут хороший. Но вообще-то среднемосковских хороший программист между сиюминутной скоростью написания кода и среднемесячной выбирает сиюмитнутную (копипасты вместо выделения в отдельные функции и +10% времени на это). Это не потому что он такой плохой - это потому что за годы программирования он выяснил, что именно это одобряет начальство: скорость сиюминутной работы в ущерб качеству кода.

В случае Симфони спасает сложность фреймворка - можно дать нанимаемому задание написать какой-нибудь калькулятор с сохранением всех промежуточных вычислений или документооборот простой заявки (а лучше двух) с полем мультивыбора и посмотреть, что и как человек наваял. Ни диплома, ни рекомендаций, ни резюме, ни пола, ни расы, ни возраста - ничего не нужно. Напиши и покажи класс.

relo_san пишет:

Без четко оговоренной ответственности за некачественные проверки кода или намеренное скрытие проблем толку от код-ревью действительно не будет.

Угу. Буду думать. Хотелось избежать сплошной проверки кода, но, похоже, дешевле всё-таки её организовать, чем положиться на автоматику.

relo_san пишет:

Ну или должна идти речь об очень строгой корпоративной культуре, но построить оную — значительно более трудоемкая задача.

Приспособятся и продолжат как всегда. Я уверен, что приспособятся даже к +10% к зарплате за наибольшее количество найденных ошибок в чужом коде и -10% за качество кода у человека с самым большим количеством ошибок. Но начать, похоже, лучше с этого, потом менять систему воздействий на новую. И так по мере приспособления.