Контроль качества кода в перспективе развития проекта

[SECL]

Основной критерий качества разработки это сокращение времени на поддержку и добавление новых фич с разрастанием кодовой базы.

[hudson]

Вопрос был сформулирован прежде всего «как?». «Сокращение времени на поддержку и добавление фич» это не «как», а «что», даже не критерий, а субъективная оценка.

Критерием (метрикой) оно (сокращение) может стать, если указать как и какие параметры измеряются, как часто и как их интерпритировать.

Собственно поддержу вопрос — как?

[SECL]

Да, вы совершенно правы, это субъективная оценка. Мы в свое время поверили специалистам из SIG, которые опирались, с их слов, на соответствующий объем статистических данных. И, по нашему субъективному мнению, их расчеты оказались верны. Любой стандарт — это правила и ограничения, призванные унифицировать какие-либо положительные тенденции. Вышеописанные принципы находят свое подтверждение и обоснование в трудах многих уважаемых авторов.
Я уверен, что вы вполне можете предложить свои подходы, описать их в подобной статье со своими критериями. Тогда мы с большим интересом обсудим результаты.

[hudson]

Мы первые спросили :-)

[SECL]

Вы подняли очень важную и интересную тему из области статистики программных продуктов. На мой взгляд, вопросы грамотного учета и сбора статистических данных в рамках работы с кодом — исключительно необходимый и, часто, недооцененный фактор. Особенно это касается молодых и не очень больших компаний, где оценка даже менеджерской информации может вызывать затруднения. Решение может заключаться в целенаправленной унификации сбора данных по различным параметрам работы коллектива. И даже педантичная оценка последствий внедрения новой методики в рамках не очень большого коллектива не даст репрезентативной выборки, элемент субъективности будет оставаться. Я бы с удовольствием почитал о таких исследованиях. Вот, что я имею ввиду.

[Fesor]

даже не критерий, а субъективная оценка.

Объективно оценить это можно только за счет динамики скорости разработки. Если первый месяц команда пилила задачи в среднем за N времени, то если все хорошо через пол года они будут пилить все примерно с той же скоростью.

[Dolbe]

Нами был реализован контроль следующих базовых принципов:

• Длина функций не должна превышать 15 строк кода;
• Цикломатическая сложность функции не должна быть более 5;
• Функции не должны принимать более 4 входных аргументов;
• Класс не должен содержать более 15 методов;

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

А проверяли ли вы свои критерии оценки простоты и читаемости кода на какой-нибудь независимой контрольной группе программистов?
Я говорю о том, что Вам ваш новый код может казаться более простым и читаемым только потому, что Вы верите в то, что соблюдение этих правил упрощает код и улучшает его читаемость. В таком случае это все не будет иметь смысла.

P.S. Прошу ни в коем случае не считать мой вопрос камнем в огород авторов статьи.

[SECL]

Нет, такой цели мы не ставили. Нам вполне достаточно было мнения наших специалистов, у нас довольно большая команда, несколько десятков человек. На данный момент я не вижу в этом какой-либо необходимости, или коммерческой выгоды. Это наша внутренняя разработка, которой мы просто поделились со всеми.

Конечно, услышать мнение других экспертов всегда хорошо. Вот выложили на Хабр, обсуждаем, смотрим на реакцию людей) Может кто-то что-то подскажет, что мы не досмотрели или предложит вариант улучшения.

[zolt85]

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

Поделитесь опытом, как это контролировать в команде из десятка программистов в стадии активной разработки продукта?

И еще такой вопрос, как убедить команду, что это верный подход?

[SECL]

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

[SECL]

Постоянное объяснение пользы от внедрения может в некоторых случаях сопровождаться бонусными решениями, а в некоторых определенными штрафными санкциями.

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

[SECL]

Все же, в каждом случае необходим индивидуальный подход.