Оценка результата, часть I
Разработчики — люди трепетные и творческие. Мы не лесорубы! К нам кубометры не приложить, труд линейкой не измерить! А кто с линейкой подойдёт, тот от неё и погибнет, если не успеет захлебнуться в истериках и критике.
Тем более, история оценки гениальными находками не блещет.
Отталкивались от количества строк кода. Кто больше напишет, тот и крутой. Получилась фигня. Вместо кода программисты начали плодить строки (читал занятную историю о том, как на одном проекте много лет назад дошли до вырождения — на каждый чих был перевод строки). Впрочем, ходят упорные слухи, что в Индии до сих пор практикуется.
Отталкивались от количества сделанных задач (или “закрытых тикетов”). Обнаружили, что задача задаче рознь, требуется сложная система оценки “веса” задач, да ещё и справедливого распределения. В какой-то мере эта система действует, но фигово (перекапывать поле всё-таки надо, а junior’ов на все поля не хватает). Подходит для однотипной одноразовой разработки на конвейере.
Пытались использовать количество багов. От абсолютных метрик (кто влепил N багов, тот Киркоров) до покрытия (X багов на Y строк кода — вполне живая метрика качества кода, кстати говоря). Споткнулись о сумму трёх китов современной разработки.
Во-первых, средний уровень разработчика всё хуже и хуже (можно сказать, что индустрия за 15..20 лет дошла до мобилизации ополчения), потому багов разработчики генерируют больше, чем кода — не умеют иначе.
Во-вторых, системы всё сложнее, интеграции всё развесистее, кода всё больше. Если раньше можно было тешить себя иллюзией контроля 10К строк проекта, то сейчас разработчик бултыхается в сотнях тысяч (вместе с библиотеками). Так или иначе, но постоянно что-то взрывается и фиг докопаешься, чей же это баг, костыликом бы успеть подпереть.
В-третьих, писать качественно — оно долго. Бизнес хочет быстро, а качественно уже хочет не очень, пипл всё хавает. Потребителю надо сдать систему в 2017 году, а не в 2020 году? Ну и чудненько. Получит софт без документации (как кода, так и пользовательской), без покрытия тестами, без нагрузочного обстрела, без непробиваемой отказоустойчивой архитектуры, без вылизанных алгоритмов, без массы ништяков. Больше или меньше багов при таком подходе? Почему-то кажется, что больше.
Как итог, ни одна из очевидных количественных оценок не сработала.
Следствием бардак. Нет, правда. Я относительно недавно меланхолично листал changelog MongoDB. Известная, production ready база данных, давно вышедшая из альфы и беты, используется на каждом углу. В версии 2.6.11 список из 18 тикетов (2/3 из которых — баги и недоделки). Версия 2.6.10 жирнее — 32 тикета. 2.6.9 легче — 23 тикета. На три версии 73 тикета. Много? Не-а.
Вот скрин из их трекера по состоянию на написание этого текста:
М… как-то занятно думать о том, что во всём мире используется поделие с 2.5К+ major issues. Норм же, да? Норм. Карл.
Это всё к чему? Вводная, которая бегло показывает, на каком поле будет действовать тот, кто попытается ввести линейку в оценку работы разработчика. Все количественные оценки мимо кассы. Все оценки через баги туда же. Действовать надо иначе.
Но об этом в следующей записи.