×

Метрики кода, или Как определить внутреннее качество продукта

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

И это не только то, чему мы учим, это еще и то, что принято у нас в компании при работе над проектами заказчиков — мы стараемся делать их так, чтобы внутреннее качество продукта (как написан код) не уступало внешнему (как отрабатывает функционал).

Многие зачастую уделяют внимание только второму — главное функционал, чтобы заказчик принял и заплатил. А после нас — хоть трава не расти — какая разница, кто и как будет поддерживать, или пытаться изменить этот код — пусть мучаются, мы же в свое время мучились с чужими макаронами.

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

Итак, внутреннее качество нам обеспечивает:

  • Понятность (что помогает легко выполнять bug fixing, быстрее и легче включаться в работу новым членам команды, легко поддерживать код)
  • Уменьшение работы в перспективе (количество ошибок снижается, количество времени на разбор кода сокращается, облегчается поддержка кода)
  • Адаптируемость (мы работаем по Agile, а это предполагает, что требования заказчиков меняются часто, и реагировать на изменения нужно быстро)

Как же это внутреннее качество контролировать? Подходов есть несколько. Мы применяем все.

1. Проводить code review

Причем review у нас проводят не тех лиды, а все члены команды. Здесь мы убиваем двух зайцев одним махом: проверяется качество кода, и знание кода распределяется между членами команды.

На что мы проверяем код во время code review? На соответствие стандартам, отсутствие антипаттернов (как в коде, так и в построении схемы БД), следование практик ООП/ООД, качество документации.

На проведение code review мы отдельно закладываем время, у нас есть специальный статус для задач (Open->In Progress->Ready for Code Review->In Review-> Ready for Testing...). Так что не сделать не выйдет.

2. Использовать сторонние инструменты контроля качества кода

Мы используем Sonar и для Java, и для .NET проектов. На что мы инспектируем код с помощью Sonar?

Покрытие кода юнит тестами (Code coverage). Да-да, мы пишем юнит тесты:

  • Line Coverage — сколько строк кода выполнено и протестировано. Наша метрика, которую мы соблюдаем — 80%.
  • Branch coverage — каждое ли условное выражение (true/false) было выполнено и протестировано. Аналогично — 80%. Более важный, чем line coverage, т.к. показывается реальную степень тестируемости бизнес-логики.

Комментарии (Comments):

  • Документируемость API — следим, чтобы код содержал пояснения. Особенно важно для распределенных Agile проектов. Метрика — 80% публичных методов должны быть задокументированы.
  • Следим, чтобы не было закомментированного кода — 0 строк.

Отсутствие связности внутри методов (LCOM4) — чем эта метрика больше, тем риск падения системы выше при изменении функционала. Особенно из-за тех мест, которые дают увеличение этой метрики (Sonar выдает усредненную).

Индикатор спутанности пакетов (Package tangle index) — количество циклический зависимостей между пакетами и общим числом зависимостей должно стремиться к 0.

Процент дублирования кода (Duplications) — отсутствие копипаста кода — должно стремиться к 0%

Цикломатическая сложность (Сomplexity) кода определяет сложность структуры кода: чем меньше вложенных операторов ветвления и циклов, тем лучше:

  • На метод мы придерживаемся метрики — до 7. Больше — рефакторим.
  • На класс — до 15.
  • На файл — мы отключаем.

Также мы внимательны к замечаниям (violations), которые выдает Sonar — мы исправляем блокеры, критикалы и мажоры.
Sonar — настраиваемый инструмент, и есть еще множество метрик, которые можно собирать и анализировать. Иногда мы к ним прибегаем, но зачастую останавливаемся на вышеперечисленных стандартных.

Что влияет на возможность отслеживать внутренне качество?

  • Грамотный CI. Не будет его — не будет возможности собирать метрики.
  • Выстроенные процессы. Во время спринта разработчики отслеживают метрики на своих машинах, проводят code review В конце спринта, на ретроспективе, метрики — один из обязательных предметов обсуждения, если что-то осталось не так — закладываем задачу на коррекцию на след спринт.

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn



Найкращі коментарі пропустити

К коментаторам
Перестаньте говорить с заказчиками о юнит тестах. Марна трата часу.
Молча делайте и закладывайте во все истимейты. 50% задача 50% юнит\другие тесты. Все

Проще чем топор. Время на рефакторинг рассовываем по всем эстимейшенеам. И код покрыт и заказчик не обосрамшись от непонятных слов живет.

106 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Старое и хорошо известное бизнес-зло: бюрократия

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

Изменения и бюрократия — вечные враги, несовместимые соперники. Хороший код — всегда избыточен. Всегда содержит хвосты перемен. Всегда имеет явные места, которые хотелось бы улучшить. Почти всегда имеет «ложные ветки» — проверки, которые никогда не сработают, возможности, которые никогда не будут реализованы. Почему так: избыточность даёт власть над этим самым «никогда», делая перемены не просто возможными, а желаемыми. Автор кода будет желать новых заказов, дабы иметь возможность поднять качество старого кода. Бюрократ — будет страшиться изменений, и всячески бояться новых хотелок. В особенности мелких.

Никто и никогда не решится ЗАКАЗАТЬ крупные желательные перемены. Но мелкие — всегда (и на всё возрастающие суммы). Изредка — на необдуманные крупные. Это, сэляви, психология. И пока люди принимаю решения, программирование — не точная наука, а гуманитарная.

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

Брократия = смерть. Не поддавайтесь.

Сразу прошу прощения, буду писать очень ненаучно, пару недель назад в свой блог (fullzero.info/blog#341) добавил пару мыслей (или просто зафиксировал бред), вот скопипасчу тут:

Интересно, доживу-ли я до того дня, когда миф 100% test coverage будет развенчан. «Покроем ВСЕ unit-тестами, и будет нам счастье!» Я молчу. Я, конечно, сам любитель фантазировать, но когда фантазии выдаются как панацея, и мифы выдаются за реальность...

У качества всегда один источник — заказчик! Если группа людей (или лидер), готовых платить деньги за ПО, хотят качества, они его добиваются. Как они это делают? Долбят девелопера, как еще.
Качество можно повысить, по моему мнению, только выделив группу приемки на стороне заказчика, не ситуативно, а на постоянной основе И эта же группа осуществляет последний уровень поддержки этого ПО! Вот такая схема работала, когда мы делали СПОВ, не знаю работает-ли она сейчас. Я до сих пор помню тех трех женщин на стороне ПФУ. Вот когда у программиста, по-крайней мере у лидера разработчиков, руки трусятся, и в жар бросает, и ты готов сквозь землю провалится, когда получаешь список замечаний по новым фичам. Поехал в ПФУ, не отправил по почте, нет, а, именно, поехал, посидел, посмотрел, как люди начинают его тестировать. Персональная встреча с группой приемки пару раз в месяц очень помогает задуматься о качестве ПО ;)

Лучшего я ничего не встречал!

Может быть, какой-то фанатик, типа меня, и воодушевляется качеством разрабатываемого продукта. Кстати, не путайте два совершенно разных понятия «Качество кода» и «Качество конечного продукта»! Второе автоматом не выплывает из первого! Так вот, даже, если девелопер воодушевляется качеством, именно, продукта, то 99% заказчиков не понимают, что за качество, как и за свободу, нужно бороться! Заказчик думает, точнее, ему и в голову не приходит, что его (качества) может не быть в том, за что он заплатил :) Только во второй, третий раз, когда деньги выкинуты на ветер заказчик начинает понимать, что его тупо разводят. Вот тогда, и только тогда, в голове заказчика появляется термин Качество.

Так что именно заказчик при первых попытках втягивания в разработку убивает качество продукта, да еще, и делает из разработчика пофигиста. Даже, если тимлидер (техлидер) будет умолять, пугать своих ребят, чтобы последние уделяли внимание качеству... это все не действует. Команда разработчиков — ребята умные (почти всегда), чувствуют почти мгновенно, что заказчик их не прессует, что заказчик еще для себя не открыл пресловутый термин «Качество», поэтому... так в 99% проектов.

Сейчас все будут орать, что я забыл про команды QA. «А QA зачем тогда?!» А что такое QA, действительно? Группы QA — это делегированные со стороны заказчика группа приемки, якобы. НО, QA не занимается поддержкой пользователей, QA себя чувствуют частью разработчиков, но никак ни частью заказчика. Если кто-то встретит QA member’а, кто стал частью стороны заказчика... позовите меня, хоть посмотрю на такое диво ;) «Ворон, ворону глаз не выклюет».

Самый обалденный способ повысить качество, это заказчику везти свою собственную разработку, in-house. Но за такие крамольные мысли, не то, что слова, со мной перестанут здороваться даже хорошие друзья из IT. Не говоря уже, о работодателях будущих ;) Помню я как один «крутейший» девелопер ушел из Атласа (теперь он супер архитектор, кстати. слово «супер» я не знаю ставить в кавычки или нет) и подался в UMC, через пару недель он бедненький прибежал назад со словами «не выносимо работать» :) О чем это говорит? О невменяемости заказчика? Нееет! О том, что при in-house разработке заказчик уж найдет способы, как из девелопера выжать качество продукта, не буду расспространяться о методах ;)

«из девелопера выжать качество продукта» — вот уж действительно смог взглянуть на тему с необычной стороны.
«Выжимать» качество приходится только из совсем ленивых джунов — халтурщиков. Которые пришли в ИТ зашибать большие бабки протирая штаны. Таких можно держать на проекте только от полной безнадеги или как «балласт» для раздувания попо-мест.

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

Если кто-то встретит QA member’а, кто стал частью стороны заказчика... позовите меня, хоть посмотрю на такое диво ;)
Расскажу я тебе сказочку об одном аналитике одного украинского Банка. И был у этого аналитика добрый начальник — делай что хочешь, но чтобы программа выполняла что хочет Клиент. А аналитик был ленивый — дёргаться по 200-300 раз над одной и той же ошибкой его заманало. И начал он писать ТЗ на улучшение программы. Один раз написал — поставили ему доработку с туевой кучей ошибок. Нашёл он 10 штук — сказал — больше не тестирую — исправляйте. Через месяц — новая версия доработки — половина туевой кучи ошибок. Аналитик опять 10 багов нашёл — отправил на доработку. И так полгода. Или больше. А потом вылизанную прогу поставили — начальник аналитику монеток насыпал к з/п. И только потом разрабам заплатили.
Но аналитик всё равно ленивый — ему и 20-30 раз дёргаться не хочется. Написал он следующее ТЗ... По итогу разработчики уже сами старались следить за качеством. Ибо нет качества — нет денюжек :)
Печалька только ждала аналитика — исправил он все баги в программе и стал не нужным своему начальнику :)
//как говорится — история основана на реальных фактах... :)
Добавлю немного троллинга.
Описанные метрики являются более-менее классическими, которые поддерживает сонар.

Но при этом — я буду говорить на основании своего опыта применения — являются реалистичными только для новых проектов.

Если приходит легаси проект, то придерживаться этих метрик (при начальном покрытии тестами, дай боже, 20 процентов), будет сложно.
Гораздо более адекватнее считать покрытия по модифицированному коду человеком (но этого публичный сонар делать не умеет)

С другой стороны, я бы посмотрел, как автор мотивировал бы команду на УИ проекте с размером под 500 KLOC писать юнит тесты на УИ.

Так же, поддержание метрики покрытия в распределенном проекте без наличия средств привязки к индивидуальным результатам по человеку\согласий с командами на другой стороне (и с их менеджментом) — не реалистично

Комментируемость 80% для публичных методов — по моему ощушению, имеет смысл только для published API (типа тех, которые в JDK)

Иначе — скорее оверкилл.

Процесс ревью\юнит тесты\комментарии — является адекватным, но часто в реальных условиях имеет смысл выстроить хотя бы один — или тотальное ревью или юнит тесты.

Циклические зависимости — метрика на удивление популярная. Но при более чем 10-летнем опыте я могу припомнить только один проект, где их пришлось разрывать. Обычно эти вещи решаются на уровне билд системы, и организации подкомпонент jar\assemblies для поставок.

LCOM 4 — может быть, и полезна, но при достижении метрик по покрытию кода, большинство проблем решаются сами

Нарушения в сонаре нужно настраивать, и это скорее социальный процесс — чтобы команда приняла такой процесс

какой же это тролинг, нормальное мнение. Добавлю своего
Тотальные ревью имеют очень неслабые проблемы в случае не совсем правильной команды, сталкивался.
Циклические зависимости на osgi проекте например могуть быть очень неприятными...
Понаблюдать то как будет стартовать проект с текущих 20% или меньше процентов я имел удовольствие несколько раз.
Работа по достованию бегемота из болота.

Получилось с приемлимыми резельтатами ровно раз. Новый кусок был просто сильно независимым от остального + была отличная команда. Тогда я бурчал но сейчас понимаю как все круто получалось :)

Сергей, абсолютно справедливо подмечено.
Метрики нужно собирать с начала проекта. Для легаси проектов, а еще и больших, распределенных, настроить процесс можно, но добиться хороших показателей крайне тяжело. Черный пояс в мотивации команд тут необходим.
Однако, мы всегда пытаемся померять — узнать врага в лицо.
Не обязательно сразу брасаться покрывать 500 KLOC. В проекте у одного из наших менеджеров ребята выстроили график, как они хотят постепенно улучшить покрытие (за несколько месяцев). Повесили его на стену и старались придерживаться. Получился такой себе Burnup chart.
Насчет «Комментируемость 80% для публичных методов»:
Документируемость (наличие грамотного контракта публичного метода) спасает нас от падения системы в тех местах, где этот метод вызывается другими классами. Особенно это можно прочувствовать на очень больших проектах (подход Design by
Contract).

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

По поводу проектов в 500 KLOC пример взять не с пустого места — я на двух таких проектах в моем опыте работал\руководил.

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

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

Второе — с числовыми показателями нужен баланс и живые механизмы обратной связи, которые настроить достаточно сложно.
Покрытие 80 % может быть адекватным для java проекта, но для проекта на динамическом языке (python, руби) оно будет не достаточым
Опять таки, проблема с метриками в том, что собираються они автоматически, и суждение разработчиков, когда, например, покрытие является адекватным, а когда нет, без изучения деталей сделать сложно.

Я не соглашусь касательно документации и Design by Contract. Идея Design By Contact было как раз автоматическая проверка во время исполнения, выполняются ли предусловия (то есть, правильно ли метод вызывается клиентом) и постусловия (выполняет ли метод свои гарантии). Постусловия частично заменяются юнит тестами.
Но документация никак не заменит предусловий.

Еще один пункт касательно документации на методе.

Однажды пришлось работать на проекте, где покрытие юнит тестами было в районе 80% и заказчик был редкий педант — требовал, чтобы каждый публичный метод имел javadoc, который бы описывал, что делает метод, без того, чтобы ему читать код метода.

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

Но при этом наблюдался следующий парадокс:

когда на проект приходили новые разработчики (очень толковые, апологеты ХП и ТДД), то они никак не могли разобраться, как работает проект, несмотря на наличие юнит тестов и javadoc.

У нас команда, как работает проект, поняла только через 3 месяца работы, когда получила возможность пообщаться лицом к лицу с заказчиком на 2 дня.

При этом данная проблема абсолютно адекватно могла бы быть решена 1-2 диаграммами и страничкой разьяснений на wiki.

Поэтому я не большой поклонник javadoc на все публичные методы.

По моему опыту, гораздо более полезными на проектах оказываются контекстные диаграммы системы\диаграмы потоков данных\взаимодействия конкретных подсистем.

Для легаси проектов с тяжелыми техническими долгами их выплата и улучшение кода как правило не окупаются. Потому что ИТ технологии совершенствуются и постепенно переписать проект на новую архитектуру с помощью современных тулов и библиотек будет быстрее и дешевле, чем пытаться покрыть тестами и зарефачить старый код. Тут лучше стараться изолировать старое по принципу «работает непонятно как — лучше не трогать».
А вот сбор метрик и статистики, код ревью — очень полезны. Для того, что бы с цифрами в руках показать клиенту что код проекта «гнилой». И соответственно отразить это в рисках для «прикрытия зада». Что бы потом «тыкать клиента носом», когда неизбежно возникнут проблемы со сроками, багами в релизной версии, постоянной текучкой команды и т.д.

С точки зрения бизнеса плохой код в легаси — проекте это неплохой повод содрать с клиента побольше и возможно «продать» ему идею создания новой версии.

Зависит от языка, например, легаси РНР найдет как убить себя либо — умрет при апдейте версии ;) Поэтому фиче фриз + тыкать носом в метрики РО чтобы дали переписать на фреймворке или хоть в паттернах версию 2 т.е. согласен в основном, но изолировать старое — не получится.

К коментаторам
Перестаньте говорить с заказчиками о юнит тестах. Марна трата часу.
Молча делайте и закладывайте во все истимейты. 50% задача 50% юнит\другие тесты. Все

Проще чем топор. Время на рефакторинг рассовываем по всем эстимейшенеам. И код покрыт и заказчик не обосрамшись от непонятных слов живет.

нет это все равно за счет заказчика. Но он об этом не знает и спит крепче.

Если писать с тестами занимает у вас в 2 раза дольше чем без тестов, то гнать вас надо в шею с места работы. Уже несколько раз в Киеве проводили Coding Dojo, где можно посоревноваться в скорости решения некоторых задач. Правил нет, главное чтобы задача была решена поскорее и не проседала по качеству (которое контролируется внешними тестами). И пока еще НИ РАЗУ не победил человек, который писал без тестов (мало этого, по TDD). Из своего опыта скажу, что благодаря TDD, я пишу гораздо быстрее и меньше кода, а большую часть за меня генерирует IDE по «красному» тесту. Следующий Coding Dojo пройдет 14 ноября, так что можете убедиться сами: xpdays.com.ua/coding-dojo.

Если для тебя тесты- это строго юнит тесты и TDD — у меня для тебя плохие новостити.
На этой планете выражение юнит\другие тесты вполне себе может нести например написание полномосштабных функциональных тестов на каком нибуть силениуме. И например неслабый интеграционнный пакетик и написание бенчмарка для оценки производительности.
Я довольно плотно занимался подсчетом как и сколько стоят проекту тесты, это не так просто и очевидно.
Например в специфичных случаях в итерации тесты могут сьесть и больше половины времени. Особенно на ранних стадиях и когда окружение не совсем тривиальное и нужно выдать на гора подобие тестового фреймвока для этого конкретного приложения. На позних стадия проекта затраты на тесты вообще могут упасть до совсем малозаметных.
То значение 50\50 это этакое очень эмперическое но почти всегда соблюдающееся значение которое я наблюдаю в очень немалом количестве команд. И значительных аномалий за мои 8 лет с TDD и XP не попадалось.
Что там у вас происходит на соревнованиях- это отдельное кино с одноразовым кодом и тестами, и это НЕ типичная работа на проекте.

Если для тебя тесты- это строго юнит тесты и TDD — у меня для тебя плохие новостити.

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

Я довольно плотно занимался подсчетом как и сколько стоят проекту тесты, это не так просто

Это очень печально, что вы столько времени убили даром. И после этого пришли к выводу, что это дорого и не стоит того.

Например в специфичных случаях в итерации тесты могут сьесть и больше половины времени.

Время от чего? От конечного времени на задачу или от времени на ее написание без тестов? Арифметика тут очень простая: без тестов я пишу задачу за 1 час, а с тестами за 45 минут. И то, что тесты заняли 25 минут (даже больше 50% никого волновать не должно).

То значение 50\50 это этакое очень эмперическое но почти всегда соблюдающееся значение которое я наблюдаю в очень немалом количестве команд. И значительных аномалий за мои 8 лет с TDD и XP не попадалось.

Интересно было бы послушать как и зачем вы его замеряли... :)

Вводная часть — ну я там вообще то редактировал свой ответ, так что там обороты должны быть немного по легче как я остыл. Увы вы застали более эмоциональный вариант
По сути:
делаете выводы за меня. Где я написал что тесты не нужны? Я как раз яросный апологет тестов.
Да я имел в виду проценты от ВСЕГО времени потрачего на задачу. Давайте про програмирование без тестов пока вообще пока забудем, я смотрю это приводит к путанице.
Рассказываю от куда бралось дурная идея мерять сколько ест тестирование.
Было пару заказчиков в разное время озадаченых финансовым вопросом в одном случае и близкими дедлайнами в другом. И их прошлый технический бекграунд очень теребило время затраченое на юнит тесты и прочую роскошь.
В общем то это две совсем разных истории с одинаковым концом.
Заказчики нашу позицию поняли и приняли. Из чего были сделан мной вывод.
Что бы исбежать не нужного толчения воды в ступе с заказчиком никогда рефакторинги и подобую активность в инвойсах и репортах о работе не отображать. На ней могут с горяча попробовать экономить.

К счастью некоторые компании просто ставят условие- как и сколько использовать юнит и ДРУГИЕ :) тесты.

В таком случае, мы просто не поняли друг друга. По вашему комментарию у меня сложилось ощущение, что вы предлагаете увеличивать оценки на 50% и явно включать написание тестов в счет заказчику. Туда же и рефакторинг. Из-за этого и возник мой комментарий. Но раз мы на одной стороне, то предлагаю мир. :)

да возникло некоторое недопонимание. Я так понял что только не очень квалифицированые люди тратят 50% на тесты- настоящим джигитам надо в разы меньше. И НЕСКОЛЬКО завелся от такой вопиющей несправедливости

Я бы даже сказал, что джигиты наоборот тратят больше времени на тесты, чтобы все понять в деталях, а потом написать чуть-чуть кода и все взлетело. :) Я ведь написал: «если писать с тестами занимает у вас в 2 раза дольше чем без тестов...».

Если писать с тестами занимает у вас в 2 раза дольше чем без тестов, то гнать вас надо в шею с места работы.
Это смотря что писать. Если хорошее качество не требуется (а многие клиенты его и не ждут от аутсорса — им бы подешевле) то за опытным формошлепом Вы не угонитесь. Даже без юнит тестов и рефакторинга. Потому что халтуру можно клепать очень быстро. Дизайнеры, шаблоны, куски готового кода из инета и других проектов — скопипасил, «сшил» и франкенштейн готов.
Качество кода и юнит тесты окупаются только на этапе отладки и багфикса. Но утверждать что сразу писать хороший код занимает столько же времени, сколько плохой просто странно. Разве что сравнивать синьора с хорошим кодом и джуна с плохим.

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

— Пишем меньше кода, потому нам надо просто сделать тест рабочим
— Не надо собирать и запускать проект, чтобы проверить, что «франкенштейн» жив

— Не допускаем порчи уже написанного кода, потому что контролируем его в тестах

Даже этих факторов хватает, чтобы делать быстрее чем без тестов.

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

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

Жаль, что вы выступаете на ДОУ почти инкогнито (у вас не указано никаких профилей внешних). А анонимом можно всем уверенно раздавать советы и поливать г..ном при необходимости. :)

Я имел ввиду, что вы переходите на личности и в моем комментарии, где увидели ЧСВ. А потом еще вспомнили «другие каналы»... Нехорошо как-то, по-детски.

Чтобы переходить на личности, надо открыть свою личность, чего вы не сделали. Иначе непонятен контекст, из которого вы делаете свои заключения, выводы и обвинения... :)

Если писать с тестами занимает у вас в 2 раза дольше чем без тестов, то гнать вас надо в шею с места работы.

Чтение комментариев на ДОУ, лучший способ демотивировать себя и почувствовать себя г-ном.

Подход здравый и рабочий, за исключением случая, когда заказчик излишне дотошный и требует отчета за буквально каждый потраченный человеко-час. Понимаю, звучит как маразм, но такое реально бывает при T&M модели, особенно когда на той стороне эстимейты принимает кто-то с техническим бэкграундом, но привыкший писать код «по старинке».

да, такой случай уже откровенно по хуже. Тут придется крутится как белка в колесе доказывая что и как вы делаете. Софт скилы сдесь будут главным орудием.
Доказать что так как вы делате — делает проекту лучше. Часто требует времени. И нервов. А так же что бы ваша работа и правда делала проекту хорошо :)

Ваши слова да менеджерам в уши! Действительно самый лучший способ сделать по правильному это сразу сказать клиенту: мы работаем по такому-то процессу и халтуры не делаем. Клиент не должен лезть в методику разработки: мы взялись делать — значит сделаем хорошо.

И иметь смелость сказать твердое «НЕТ», когда клиент скажет что эстимейт сильно для него большой, но он согласиться на проект если урезать его на 30%. А ведь большинство менеджеров просто выкинут из эстимейта все качество что бы не потерять клиента. Мол сам отказался платить за качество — сам виноват. Будем делать халтуру (как обычно).

я вам скажу страшное — я знаю места где менеджеры так и делают. Как раз эту мудрость мне еще в далекой молодости донесли в одной маленкой но хорошей компании.

50% — перебор, я бы заложил 30%. Но в общем принцип безусловно правильный.

мне в целом понравилось.

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

разница между лекарством и ядом — в дозе.

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

Спасибо за отзыв. Насчет выкачивания — это применимо к T&M проектам, у нас в основном fixed price.

Если появляются сомнения в достоверности репортов Сонара, можно применять один из его плагинов, поддерживающий mutation testing, который изменит значение условий true на false, и, соответственно, покажет, какие тесты отработали, а какие нет.
Токая проверка занимает время. Можно несколько раз ее включать, не обязательно всегда. Убедиться, что тесты пишутся грамотно, или же сделать выводы и провести беседы с разработчиками (они-то рады писать хорошие тесты, так что сопротивления не должно быть).

Есть еще подход к написанию кода — BDD. Можно с этим поиграться :)

Играли. Возможно, расскажу в отдельной заметке...

Отличное резюме про Сонар! :) Это как «вы все г..но, а я Д’артаньян»... Если вам важно, чтобы ассерты были, то в свежих версиях Сонара появились проверки на таковые, которые вы можете включить. А вообще, в плане покрытия Сонар не должен проверять качество вашего процесса написания модульных тестов. Вместо этого он просто подсказывает вам, где места, которые вы могли банально забыть покрыть, если работали не по TDD. Поэтому я лично против отслеживания процентного покрытия — надо чтобы вся логика была точно покрыта, что проверяется Сонаром + ревью кода.

Но в Сонаре покрытие — это мелочь. Гораздо больше пользы от многочисленных метрик и проверок, которые вы не в силах сделать руками. Они позволяют вам не допускать глупых ошибок, контролировать дизайн и качество кода, находить и устранять дубликаты. Поэтому это просто незаменимый инструмент. Запустите на досуге на своем проекте и посмотрите, сколько всего «интересного» он вам найдет. :)

А 16-17 ноября в Киеве на конференции XP Days Ukraine будет выступать CTO проекта Sonar на тему того, как делать Continuous Inspection: xpdays.com.ua/program.

Sonar сам ничего не считает, для этого используется FindBugs, Checkstyle, Cobertura и т.д. Поэтому ваше замечание по поводу FindBugs как-то странно выглядит.

Я подозреваю что это вызвано скорее различным переводом терминов но высокая связность (high cohesion) это позитивная характеристика в отличии от высокой связанности (high coupling). В таком переводе эти термины существуют в русскоязычной википедии. Без обид — просто глаз рубануло )

Согласен: «связность» и «связанность» — в русском путаница выходит. Лучше переводить cohesion как «сцепление».
ru.wikipedia.org/...ограммирование

Или уже тогда говорить о «внутренней» и «внешней» связанности.

ага все круто, за мою 9 летнюю практику , один раз получилось убедить клиента, что нужны юнит тесты, да и то не довели дело до конца. Ну не получается убедить клиента, что он должен переплатить 20% стоимости продукта за красивый код. Ну а уже как выглядит документация я и подавно забыл. Ну а уж когда отвечаешь, что рефакторингом занимаешься — тут вообще буря эмоций, хоть его другим словом называй, непонятным для менеджеров.

Аналогичный опыт. Поэтому и любопытно. Или где-то есть «правильные» клиенты и проекты или просто очередная джинса в стиле «наша фирма веников не вяжет».

Каким должен быть хороший процесс разработки многие знают. Как заставить клиента платить за такой — вот вопрос?

Как заставить клиента платить за такой — вот вопрос?
Это — старая проблема :)
Насколько понимаю — никак :)

Методики повышения качества кода нужны для:
1. повышения устойчивости разработки, стабильности сдачи этапов приложения, в последние 20% времени разработки проекта.
2. проекта который вы же будете обслуживать. Выставляя ту же цену как и у других.

Просто говоря — мы теряем X0% оплаты, в сравнении с «быстро-обильно-пишущими», ради приобретения лояльного клиента.
А если клиент, проект разовый, «временный», то и не нужно. Разве что — «абы рука не сбилась»

Просто говоря — мы теряем X0% оплаты, в сравнении с «быстро-обильно-пишущими», ради приобретения лояльного клиента.

Это логичный шаг (хотя компании очень редко на него идут). Но выходит что:
1. За все методики повышения качества должна платить ИТ компания.
2. Эти активности должны быть скрыты от клиента что бы он не знал что ему что-то делают бесплатно (а то привыкнет).
3. Должны быть «невидимые» клиенту члены команды, что бы покрыть затраты по времени.

4. Должна быть уверенность (а лучше контракт), что клиент не «сбежит» к другому подрядчику. Тем более что хороший код легко передать.

1. За все методики повышения качества должна платить ИТ компания.

Конечно. Точно так же как и в пром производстве — за любые усовершенствования, повышение качества платит так же — компания.

2. Эти активности должны быть скрыты от клиента что бы он не знал что ему что-то делают бесплатно (а то привыкнет).

Когда как. Но в целом да — «себестоимость» должна быть скрыта от клиента.

3. Должны быть «невидимые» клиенту члены команды, что бы покрыть затраты по времени.

Возможно — да. Зависит от вида вовлеченности клиента в процесс разработки.

4. Должна быть уверенность (а лучше контракт), что клиент не «сбежит» к другому подрядчику. Тем более что хороший код легко передать.

Такой уверенности никакой контракт не может гарантировать :)

Этот пункт относится к — «бизнес-рискам». Работа менеджеров — их просчитывать и учитывать. Чтобы да, не вышло — «сделали задешево на отлично, а клиент сбег на сопровождение к другим»

Вообще, эти все вопросы — не программиские, а бизнесовые :)

Как заставить клиента платить за такой — вот вопрос?

С другой стороны, а надо ли? Предложили клиенту «красивый код» — он отказался, тогда пилим проект без красивого кода. В случае кипеша со стороны менеджмента о корявом, падающем коде — вполне адекватные отмазки в духе «Клиент отказался от тестирования и рефакторинга кода. Данные процессы есть неотъемлемая часть программирования, и, как следствие, хреновый код получается из-за их отсутствия, и не из-за того, что программисты плохо написали» :)

Есть понятие «технического долга». Можно ли перезанимать деньги что бы отдать предыдущие долги: можно, и многие так и делают (например правительство).

Какое может быть будущее (у проекта или страны) с таким подходом — то же понятно. А вот кого назначят виновным — это уже вопрос. Но наверняка не клиента — ведь он «всегда прав».

Есть понятие «технического долга».

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

Если другая — то и пес с ним, с долгом.

Но наверняка не клиента — ведь он «всегда прав».

Конечно. Прав тот кто — ПЛАТИТ деньги. Не нравится клиент — ну так пошли его, вместе с его деньгами, найди другого ;)

Есть понятие «технического долга»

Вы по контракту работаете, или вам пацаны мазу затёрли, вы подписались, а тут фраер-фуфлогон нарисовался, и теперь придётся лямку тянуть, чтобы фуфлыжником за братвой не прослыть?

Не стоит изобретать себе геморрой. «Технический долг» вы отдадите в тот момент, когда предложите клиенту (или манагерам — не суть важно) «красивый код» и объясните, зачем ему это нужно. Всё, ваш долг отдан, и что будет дальше — уже зависит не от вас. Надо быть более прагматичным в таких вещах.

Как-то Вы неправильно поняли про «долг». При чем здесь контракт или репутация?
«Технический долг» — вполне определенное ИТ-понятие, напрямую связанное с качеством кода (и не связанное с финансовыми или юридическими обязательствами).

en.wikipedia.org/.../Technical_debt

Ох уж эти неологизмы... Это называется «совесть» :)

З.Ы. Я правильно понял, но, видимо, в прошлой жизни был Петросяном.

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

ну, раз уж в стратегическую необходимость вылизывания кода клиент не верит, то сфигали верить, что очередная мегакритическая бага — от повсеместных циклических зависимостей, а не от «тупых разрабов»?

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

Суть в том, что красивый код потом можно гораздо быстрее (=> дешевле) модернезировать, но у меня, например, большая часть заказов одноразовая.

Суть в том, что красивый код потом можно гораздо быстрее (=> дешевле) модернезировать, но у меня, например, большая часть заказов одноразовая.

А не потому ли что потом этот код отдадут на сапорт в какой-нибудь бодишоп? Подумай о других девелоперах, которым это потом разгребать.

У меня есть заказ и есть сроки. Если будет время написать правильно и покрыть это тестами — я так сделаю. Если нет, то я буду использовать шаблонные компоненты, откажусь от нинжекта и юнит тестинга. Всё просто.

Сроки сроками, но есть еще и порог приемлемого качества. Если заказчика устраивает вариант «с багами, плохо поддерживаемое, но быстро и дешево» — тогда да, RAD в зубы и вперед :) И, да, не исключено, что на саппорт это потом попадет в бодишоп с дешёвыми рейтами.

Каким должен быть хороший процесс разработки многие знают. Как заставить клиента платить за такой — вот вопрос?

Объяснить клиенту, что за плохой процесс разработки он, в итоге, заплатит еще больше. Это работает, за исключением случаев, когда клиент осознанно согласен на г$%нокод и не очень стабильный продукт ради дешевизны и скорости выхода на рынок.

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

Тяжелый энтерпрайз охотно вкладывает деньги в качество.
Качество требует не только денег, но и времени. А в бизнесе зачастую лучше выпустить кривое, но раньше конкурентов. И это справедливо даже для самых «крутых» компаний.
Но бизнесмены не понимают что исправить код «потом» — это дороже, чем все переписать заново.

А в бизнесе зачастую лучше выпустить кривое, но раньше конкурентов

Если речь о коробочном продукте — то да.

Если о внутреннем, то бизнесу нужен инструмент — в срок.
И — работающий как положено.

И — следующее изменение — в срок.

Кривое обычно — со временем начинает срывать сроки

Срыв срока — потеря клиента. Другие ему лучше не сделают, если это утешает :)

Но бизнесмены не понимают что исправить код «потом» — это дороже, чем все переписать заново.

все они понимают :D

а иначе бы — откуда у них деньги? ;)

Программисты это — обслуга! это должен знать каждый программист в непродуктовой компании. Обслуга НЕ может качать права. Но — вполне может хитрить.

P.S.
Ну и — 5 разных видов программерского «товара».
В каждом — свои подходы к ведению бизнеса.
Я об «внутреннем ПО», которое называю еще «заказным», не «коробочным».

Как понимаю бОльшая часть программистов мира им и занимается :)

«Пять миров» Автор: Joel Spolsky

russian.joelonsoftware.com/...FiveWorlds.html

Только не в финансовом секторе при условии что у Клиента 10+ лет присутствия на рынке, репутация и обязательства перед собственными клиентами. Не говоря уже о тех, кому удалось создать отраслевые стандарты.
Предлагаю считать, что нам патологически везет с заказчиками и у нас именно тот «класс проектов» )

Что касается того, чего не понимают бизнесмены, то в этом смысле следует четко понимать что «долгожданное попозже» для клиента может и не наступить. При всех наших попытках предложить идеи по развитию продукта/услуги — клиент всегда лучше понимает на каком он свете и как ему лучше себя вести на рынке. Исправить код «потом» — можно из заработанной прибыли, реинвестируя. А качество — вопрос вложений «на сейчас». Да, деньги заказчик потратит и он понимает это. Но какие деньги? Те что есть сейчас или те что будут «потом»? Станьте на место клиента-бизнесмена и я думаю Вам сразу же захочется перенсти все финансовые затраты на будущее. ) Для этого придумали Fixed Price модель )

Предлагаю считать, что нам патологически везет с заказчиками и у нас именно тот «класс проектов» )

Значит мне просто патологически не везет с проектами. А в этой теме описали как раз противоположную ситуацию поэтому и интересно: что за проект такой если на нем так важно качество? Кому и почему это нужно?

Может быть это действительно важный внутренний проект, который заказчик делает «для себя». А может это ИТ контора, которая старается брать качеством, а не количеством.

что за проект такой если на нем так важно качество?

который делает — боооольшие деньги. и плохая работа которого — приводит к боооольшим потерям денег. Так что «пара копеек» за качество, — роли не играет.

кстати, вспомнил, у Фаулера ж во вступлении к «Архитектура корпоративных программных приложений» вобщем-то написано :)


Если программа обеспечивает получение тех или иных преимуществ (а такими должны быть все корпоративные приложения), задержка с ее внедрением в эксплуатацию означает прямые финансовые потери. Поэтому отнюдь не хотелось бы принимать решения, которые воспрепятствуют развитию системы в дальнейшем. Однако, если оснастить систему дополнительными службами с прицелом на будущее, но сделать это неправильно, новый уровень сложности как раз и может затруднить ее эволюцию, приостановить процесс внедрения и отсрочить получение преимуществ. Несмотря на «незначительность» каждого отдельного приложения такого класса, все они, рассматриваемые в совокупности, способны оказать серьезное положительное (или отрицательное) влияние на показатели деятельности «корпорации».

... а внутреннее качество кода как раз и относится к «сделать это — правильно»

вот-вот! клиенту насрать на то, что соединение с бд открывается в экшн-методе!

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

Так вы клиента не убедите :) Юнит-тесты — это инвестиция. Потратив на 20% больше на их написание, мы сэкономим в худшем случае столько же на отладке, а в лучшем — сэкономим даже больше, чем вложили. Погуглите на предмет defect removal efficiency, у юнит-тестов она, если не ошибаюсь, в среднем около 40%.

Фаулер, насколько я помню, призывает заниматься рефакторингом за свой счет, а не за счет клиента. Причем постоянно, а не «а теперь давайте выделим еще $20K на рефакторинг». Теоретически, в итоге должно быть выгодно, даже если криент об этом не в курсе.

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

У меня немного другой, правда на много скромнее, опыт.
Первое приложение и требуют юнит тесты (C#).
Force.com на уровне загрузки кода клиенту (простыми словами) проверяет покрытие кода на минимум 75%.
На текущем месте работы задача не принимается без юнит тестов и интеграционных тестов, а также документации к классам/методам (J2EE).

Так что, например, я уже к этому привык и в дальнейшем буду выставлять цену, в которою включу все это.

на фрилансе с этим туго ( не всегда но в основном) туда люди идут за тем, чтобы подешевле.Если посмотреть на тот же одеск — все обещают отличное качество и оглядываясь назад я понимаю, что я творил — но клиента это устраивало. Наверное это все зависит от сложности проекта.

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

Вы же не убеждаете заказчика, что выгоднее программировать двумя руками, а не одной. Ведь одной было бы дешевле? ;)

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

Видите ли, очень часто происходит примерно так. Команда делает эстимейт, предполагая написание качественного кода, все инженерные практики и т.п. Отсылает этот эстимейт клиенту и в ответ получает весьма эмоциональный ответ в духе: «Да вы что, офигели?! Мои собственные программисты дали эстимейт в два раза меньше!».

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

И упаси нас всех Господь повестись на такую позицию клиента, так как потом, при сдаче проекта, начинается самый веселый этап этой многоходовки: «Раз у вас есть баги, значит, вы продали мне плохих программистов! Будьте добры теперь фиксить эти баги бесплатно!»

Я могу вызвать бурю негодования среди читателей и писателей ДОУ, но на такой аргумент самым разумным ответом является: «извините, мы работаем по таким принципам. если не хотите, то поищите других подрядчиков...». И это спасет вас от проблем в будущем, как описано в предыдущем комментарии. А пытаться заработать деньги даже там, где это «неудобно» не стоит. Так можно скатиться до того, что при отсутствии работы разработчики будут ремонт делать в загородных коттеджах. :)

Вас бы на позицию топ-менеджера в нашу компанию. Кроме шуток — если бы начальство выбирали, я бы за Вас проголосовал за одни эти принципы:

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

пытаться заработать деньги даже там, где это «неудобно» не стоит

А то ведь у наших менеджеров есть заповедь «никогда не говори клиенту НЕТ».

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

Можно сказать что я именно этим сейчас и занимаюсь! И ладно бы «дыры латать» (фиксить баги, улучшать код) а то ведь «траву красить» (писать комментарии к методам типа ToString и фиксить отступы и переносы строк в коде).

Спасибо за доверие! :) Возможно, когда-нибудь я на такую позицию буду посматривать.

Но хочется отметить, что это еще и ваш выбор — вы же согласны «красить траву» и не уходите, хотя на рынке очень и очень жарко. Наша судьба в наших руках. ;)

вы же согласны «красить траву» и не уходите, хотя на рынке очень и очень жарко

Дело в том, что

у наших менеджеров есть заповедь «никогда не говори клиенту НЕТ»

ИМХО справедливо для подавляющего большинства компаний на местном рынке. А менять шило на мыло...

Ну что до отступов, правильные IDE могут спасти. Если что, могу что-то подсказать в NetBeans, по настройке автоформата — иногда здорово спасает при просмотре реформате кода от «аццких» коллег.

Бурю негодования такой ответ вызовет не у читателей ДОУ, а у топ-менеджмента :)

Так можно скатиться до того, что при отсутствии работы разработчики будут ремонт делать в загородных коттеджах. :)

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

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

Вы в рабстве? :))) По-моему на рынке полно работы, а для толковых разработчиков даже на выбор по степени интересности проектов. Так что интим, ремонт и прочие работы необязательны...

Вот поэтому в командировки не езжу принципиально. Даже если не погибнешь в авиакатастрофе, то быть гастарбайтером в чужой стране — удовольствия никакого. Все что действительно надо делать девелоперу — можно сделать удаленно. А «интим» клиенту пусть менеджер сам обеспечивает.

Вспомнил одного маляра. Ему предлагали хорошие деньги за срочность, а на качество мол плевать, потеки там и все такое, главное быстро задуть лаком. Так он им ответил: «У меня потеков не бывает, потому что я г@вна делать уже давно не умею, а за это время даже за ваши деньги я нормально сделать не смогу.» И отказался. :)

Красавчик! Причем, думаю без работы он не остался. :)

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

наверное начинаете не с того конца. Доктору нужно убеждать пациента что ему (доктору) нужно руки с мылом до и после осмотра помыть? Юнит-тесты это тоже из разряда гигиены ИМХО.

Вы пытаетесь убедить меня — не надо, я и так все понимаю. Часто заказчику важнее скорость, чем качество, если это не касается моментов связанных с деньгами. В тем более , мануальное тестирование у нас есть, да и то, очень часто заказчик говорит, что сам будет тестировать, дабы еще больше сократить расходы. Ну и как бы Вы же понимаете, что баги будут все равно и у клиента может возникнуть вопрос — я заплатил за тестирование\качество, а тут баги — как же так!
Вопрос в том, как снизить стоимость разработки, дабы конкурировать с теми, кто не делает тестирование. Еще очень интересно как использовать тестирование в условиях быстро меняющихся требований — но это уже совсем другая история

А DM как расшифровывается? Для тех кто в танке.

Delivery manager, если память меня не подводит.

Писать код качественно абсолютно не сложно. Через пару итераций те штуки, за которыми раньше разработчики следили, становятся естественными (вырабатывается внутренняя культура). Надо только правильно настроить процесс. Не утаю, что вначале это будет отнимать лишнее время. Но вскоре все окупится с торицей.

Можно подробнее про время. Трекаете ли вы отдельно время потраченное на девелопмент, юнит-тесты, код-ревью, комментирование, рефакторинг? Или это общее время на имплементацию задачи?

Если трекаете, то поделитесь статистикой — сколько куда уходит времени в среднем. Видит ли заказчик эту статистику или только общее время? Как решается вопрос сложных рефакторингов или правки юнит тестов если такие «непродуктивные» активности требуют несколько дней? Были ли прецеденты, когда заказчик отзывается платить за такие задачи или требует пожертвовать ими ради сроков?

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

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

имхо и мнение теоретика.

насколько я понял, цель этих практик — упрощение разработки в долгосрочной перспективе — а значит много больше одного релиза

эмм... долгий разговор. концептуально я думаю что речь должна идти о первой версии и именно для её наискорейшего и неаикачественнишего выпуска и должно применятся всё это оружие. вторая версия может вообще иметь другую архитектуру, набор модулей сущностей классов и т д
то есть понятно что все тащать до 104.7.12/8

но внутренне чувствую что это не совсем верно

Что это за магические цифры?

104.7.12/8

У нас были вариации на эту тему. Были и есть проекты, где отдельно заводилась задача на Code Review для всего кода к данной User Story (кстати, один из таких проектов был распределенным, с участием команды заказчика и как раз с ними мы приняли решение заводить отдельные задачи, другие команды этого проекта поддержали).
Есть, когда Сode Review включен в задачу. На планировании учитываем. Тогда делаем отдельный стутус, как я писала в статье.

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

Рефакторинг закладываем отдельной задачай. Предварительно пишем закзчику письмо. Плюсы и минусы (с точки зрения business value) проведения рефакторинга. Он может отказаться, если мы не показались убедительны.

Статистика. Когда это отдельная задача на Code Review — не больше 15% от общей оценки на имплементацию было достаточно.

Затраченное время на юнит тесты мы не меряем, т.к. без них не работаем.
Еще на стадии контрактов мы говорим о практиках, которые мы применяем...

Насчет прецедентов. У меня отказов — не было. Но жертвовать иногда приходилось. В след спринтах первым делом нагоняли этот технический долг.

Спасибо за подробные ответы. Приятно слышать про такой проект где все делается по-уму. Почаще бы про такие писали на ДОУ — имхо, лучшая реклама для компании.

Підписатись на коментарі