Хочу поделиться реальным примером неэффективности. Для молодых разработчиков и/или тех, кто никогда не работал в больших конторах, он может показаться нереалистичным, но это правда.
Задача: расширить функциональность существующей системы. Система – огромна и стара. Несколько ХХ млн строчек кода, много харда, несколько десятков лет жизни.
Суть расширения: система может обрабатывать материалы типа А и B. Надо добавить тип С.
Естественно, это сложная задача, требующая анализа и оценок: а сколько это всё будет стоит в человеко-годах? Оценки нужны, чтобы понять: а есть ли экономическая целесообразность?
У нас есть много групп разработчиков со своими руководителями и архитекторами. И всё они должны предоставить свои оценки.
Пользуясь инструментарием, мы можем легко найти места в системе, где написан вот такой код:
typedef enum {
OBJECT_A,
OBJECT_B
} object_types;
switch(object){
case OBJECT_A: printf("This is object A");
case OBJECT_B: printf("This is object B");
default: raise_error("Unknown object!!!"); break;
Во многих случаях этот switch просто рапортует, никакой функциональности, завязанной на тип объекта нет.
Т.е. в этом конкретном случае, чтобы решить задачу добавления С, нам нужно только расширить enum и добавить одну строку:
case OBJECT_С: printf(«This is object С»);
А теперь внимание, вопрос: сколько нужно времени, чтобы сделать это изменение?
- Если вы разработчик своего домашнего проекта – несколько секунд?
- Если вы разработчик в полу-формальной группе: чуть больше… checkout/ревью/checkin/тест – час-два?
- Если вы разработчик в большой конторе: даже до того как вы сможете начать checkout, вам надо будет подготовить кое-какие документы, которые обосновывают необходимость изменения и доказывают, что тесты будут проведены и результаты — ОК.
И эти документы должны получить гриф «проверено/утверждено» (другие люди должны тратить время). Из-за этого даже такое крохотное изменение не может занять меньше 1-го дня. Физически не может. Также внутри больших контор, которые заняты бизнесом почти нет ресурсов для «общих улучшений», поэтому есть «джентльменские соглашения», что команды могу добавлять ~20% к функциональным изменениям.
Когда контора только начинает жить, то для effort estimates используют человеко-часы. По мере дряхления — человеко-дни. Позже — человеко-недели. Становятся неизвестными детали, и люди просто включают в работу «время на разобраться, а о чем вообще речь идет?!»
Вернемся к нашему примеру: В общем, после разговора с архитектором группы, в которой должно быть сделано это изменение – мы сошлись на 0.5 недели. 2.5 дня, чтобы добавить одну строку (и завершить всю сопутствующую бухгалтерию/администрацию).
Уже здесь становится понятно, насколько всё плохо внутри больших монстров.
Но это не всё, после того как к делу подключился PL, он не вникая в детали скромно отрапортовал «наверх» — 10 недель. И самое ужасное, что люди выше — не спорят.
10 недель — вот правильный ответ на вопрос топика :(
Интересно: кто знает какие-то хорошие материалы по KPI? Должно же что-то уже быть наработано по количеству кода и времени на его имплементацию?
Комментарии (17)
saaivs
04.05.2015 13:57+5А разве есть что-то в этом удивительное? :)
Дано:
Несколько ХХ млн строчек кода, много харда, несколько 10ков лет жизни.
Изменения, такого рода могут быть очень опасны в живой системе, особенно завязанной на живые деньги. Особенно на чужие.
Кто и что когда-то делал из ныне живущих, так понимаю, досконально не знает никто и что будет после изменения достоверно сказать, со всей полнотой ответственности, тоже желающих, полагаю, не так много.
Если программа будет просто выбрасывать исключение — это будет просто прекрасно.
В данном конкретном случае, кто даст гарантию, что чьи-то умелые руки когда-то не поленились обойтись IF-ом вместо SWITCH-а (руководствуясь логикой: ну а чё, если не OBJECT_A то OBJECT_B тогда по-любому). И о том, что-то пошло не так мы рискуем узнать только тогда, когда нам кто-то выкатит судебный иск по компенсации ущерба, нанесенного неправильной работой программы. Если программа выкидывает исключения — это не беда, вот если она работает неправильно — вот это уже катастрофа.
Одна из особенностей таких монструозных систем — это обилие различных групп(часто международных), которые ее на протяжении всего срока жизни развивали. И один из механизмов защиты от кривых рук(в том числе своих собственных) чтоб не порушить другие части системы при разработке нового функционала — это метод copy-paste кода. Делается это по той же самой причине, что озвучена выше. А потом, когда уже уже пропадает понимание полной картины остается только один принцип — «Не навреди». Делайте что угодно, но только не порушьте то что есть. На этом этапе мы тогда забываем про все принципы программирования вместе взятые и изобретаются костыли невиданной красоты и хитроумности.
И живет этот чемодан без ручки до тех пор пока «либо ишак не подохнет, либо падишах». Ну а потом, если задача все еще актуальна, она решается с нуля заново и все повторяется снова.
И в этом нет ничего плохого. Просто естественный цикл жизни некоторого класса корпоративных продуктов.
Так, что никакой корреляции между количеством кода и временем его появления в релизе я бы не искал.
Alexnn Автор
04.05.2015 14:07т.е. нет способов бороться с прогрессирующей дряхлостью компании? И от развала большую контору никто не удержит? не придумано способов?
Ведь видны симптомы сейчас: отсутствие знаний (очень много новых людей) -> монструозные оценки работы-> осваивание всех средств (и наём ещё больше новых людей)->никаких lessons learned
именно поэтому я пытаюсь найти метрики, чтобы можно было показать людям выше: это ненормально. нельзя соглашаться с оценкой 100К, платить, и получать назад пару строк кода.saaivs
04.05.2015 14:29Способы, наверное, есть. Но универсального решения, с определенного этапа, я думаю, что не существует.
То что я описал в своем комментарии — это тоже реальный пример из одной транснациональной финансовой корпорации на примере реально существующего продукта. Симптоматика, как видите, схожая.
Проблема в том, что из-за естественной текучки и устаревания технологий ценность даже простых изменений со временем возрастает. Это, примерно, как сейчас ремонтировать ламповый телевизор, собранный каким-нибудь «кулибиным».
это ненормально. нельзя соглашаться с оценкой 100К, платить, и получать назад пару строк кода.
К сожалению, или к счастью, но жизнь такова, что это абсолютно нормально.
Как говорится, «мал золотник, да дорог» :) Тут скорее важно понимание того, почему одна строка кода за 100К это много, или мало. Если аргументацию удастся представить в долларовом эквиваленте, тогда есть шанс, что к ней прислушаются.
Единственное, что можно сделать — это как-то оптимизировать те этапы процесса разработки, на которые вы в состоянии повлиять, а на то что повлиять не можете(даже если вас воротит от этого) — просто примите как данность. Это ведь просто работа.Alexnn Автор
04.05.2015 14:55да это, действительно, только работа :) Но очень нравится контора и не хочется уходить.
но вот с притчей — не согласен! В том что происходит сейчас: оценки растут не от большого знания, а от большого незнания. начиная от новичков за клавиатурой, пытающихся понять все эти копи-пэйстет куски, окруженные тысячами IF до множество разнокалиберных менеджеров — везде огромные оверхеды из-за отсутствия знания. огромные маржины просто из-за страха неизвестного.
как бороться с незнанием?
не отпускать старых работников?
не нанимать новых?
я пытаюсь преследовать: автоматизировать и визуализировать аспект «а что мы вообще делаем? и понимаем ли сколько денег тратится?»saaivs
04.05.2015 15:51+1Ну уходить, действительно, не нужно. Тем более если нравится.
На самом деле противоречия с притчей и в вашем случае нет. Там просто речь о том, что у человека уже было нужное знание, а в вашем случае это знание приходится получать в процессе. Но суть в том, что ценность его и в том и в другом случае существенная.
С незнанием можно бороться только обучением. А минимизация текучки — это очень комплексный вопрос, начиная от первого интервью с HR и заканчивая кофе-машинами на кухне. Но вы, судя по всему, и так уже все делаете правильно.
qw1
04.05.2015 15:06+1т.е. нет способов бороться с прогрессирующей дряхлостью компании?
Так проблема в продукте, не в компании. В той же компании можно начать новый продукт и до первого релиза делать хоть 100 изменений в день.Alexnn Автор
04.05.2015 15:09нельзя… программный стек — несколько 10ков мил строчек кода. Переписать с нуля за приемлимый срок — физически нельзя
Более того надо поддерживать выпущенный хардвер. клиенты постоянно просят новый функуционал.
Mitch
06.05.2015 00:31Рефакторинг.
Накодить паралельно с нуля продукт, решающий эти же задачи.
А как вы делаете новый функционал если 10 недель на строчку?
Или клиенты просят, а вы не делаете.
Alexnn Автор
05.05.2015 09:23www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 — тут нашел о строках кода! :)
даже в привью на амазоне можно глянуть на стр 62
mdaemon
05.05.2015 11:16ну собственно так и есть, нашли мы недавно ошибку в компиляторе С++/CLI, из за чего одна из конструкций просто не работает…
Что нам ответили в MS — поймите сделать это работающим стоит несколько сотен тысяч, а так как это второй случай когда обращаются по этой проблеме…
И реально там шла переписка, большинство из ответственных просто не в курсе о существовании подобного, и реально включают кучу времени что бы просто разобраться о чем идет речь.
Хотя по сути изменение реально похожее на пример выше, в пределах нескольких строк кода, всего лишь правильно генерировать код на имеющийся атрибут, т.е. привести компилятор к тому что бы он работал как задумано.
S_A
В смысле, вы строками кода измеряете программные продукты и те риски для больших организаций, которые они понесут в случае если программист ошибется? KPI сами по себе никому не нужны, хоть в вакууме, хоть в продакшене. А любая система KPI скажет, что да, 10 недель это понятный срок, при означенных исходных.
www.construx.com/Resources/Construx_Estimate_Download — ради интереса скачайте, вбейте «дано» задачи в софтину от (самого) Макконнела. Посмотрите результат…
Alexnn Автор
Мне кажется, что должна быть корреляция между количеством добавленных/измененных строк кода и количеством времени необходимого для этого.
+ так же я наблюдаю отход от деталей по мере дряхления конторы. всё больше начинаются какие-то пространные разговоры о потенциальных рисках. Всё меньше и меньше людей открывает код. Оценки только растут и из-за этого рушатся бизнес кейсы, проэкты умирают не начавшись, а могли бы приносить прибыль.
я вот думаю: как с этим бороться?
AdvanTiSS
Это не побороть единолично(конечно если вы не директор конторы)…
Вот вам мой анти-паттерн дряхлой конторы, где ведение документации и апрув внесения изменений, это далеко не самое узкое место:
— огромная система которая включает биллинг, систему рассылки, контроля задач для рабочих, внутренний портал, и многое другое, — всего около 50 приложений. Писалось начиная с 2000-х, кучкой различных контор. Часть реализована на Java+Oracle, а другая часть на .NET+MS SQL. Эти части связаны как посредством вебсервисов так и OLE DB. В итоге баги в Java части влекут за собой баги в .NET части. Также используются 3rd party вебсервисы.
— полу-сотня баз данных на паре десятков SQL серверов и запущенных на них с SQL агентов, которые выполняют до полутысячи job-ов, и никто не знает, где что используется и кому это надо.
— система контроля версий морально устаревшая и использовалась сугубо для хранения (барабанная дробь...) zip ????
попытки внедрить хотя бы SVN закончились тем, что изменения продолжают деплоиться без коммита, в результате часть кода в SVN уже утратила актуальность. Зато в теперь SVN стали появляться бинарники))).
— отрывочная документация к частям махины кусками разбросана на файл-сервере. Юнит-тестов нет, тест-кейсов тоже нет. Хранителей знаний о системе практически не осталось из-за текучки кадров.
Как с этим бороться, я тоже не представляю.
bay73