Оригинал здесь: http://ithappens.ru/story/7693

#7693: Затухающие колебания вязкого кода
4 ноября 2011, 11:00
рейтинг: 1257

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

Написание проекта можно рассматривать как переходный процесс из состояния 0 (ничего нет) в состояние 1 (проект готов). Из курса ТАУ я ещё помнил дифуры второго порядка для затухающих колебаний, но увидеть такой график, разглядывая динамику количества строк в проекте, не ожидал. Шутки ради по той же схеме проанализировал коммиты всех подчинённых — картина та же, хоть и менее явная. Потом поднял статистику фиксации багов и нашёл аналог длины свободного пробега молекулы в газе.

В общем, так.

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

2. Коэффициент затухания («вязкость», сопротивление изменениям) у всего софтверного проекта больше, чем у любой его подсистемы или у отдельного программиста. Период колебаний у программера практически всегда равен двум суткам: залил — все потестили — залил фикс. Как минимум 20% строк первоначального коммита будут поправлены — тоже интересная константа.

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

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

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

неучтена переменная "волшебный п.здюль" которая на самом деле приводит к поправкам сроков почти до х2

#7688: Софтина второй свежести

3 ноября 2011, 12:45

рейтинг: 508

Вот вечно ругают программеров: дескать, руки кривые, не знают ни черта…

Крупная контора, свои админы, свои разрабы. После очередного эпик-фейла самописного софта админами, как всегда, выдвигаются претензии к качеству программной поделки. Начальник разработчиков отвечает на голубом глазу:

— Качество софта обеспечивают не разработчики (это глубочайшее заблуждение), а процесс его производства. Уровень качества продукта — это одно из требований к нему, которое влияет на его стоимость, и не более того.

(2) это должно быть смешным?

(0) а можно для тупых гуманитариев объяснить что эта байда означает?(((

(3) это не смешно, это грустная правда жизни(((

(3) а что, ветка в  разделе "юмор"..?

(6) а о чем это тогда вообще?

зы: всегда думал что айти-хеппенс это типа отпочковавшиеся айтишники от башорга думающие что башорг теперь нетот и из за школоты на башорге перестало быть место для айтишных шуточек-приколов...

(0) так где графики и эти два числа, тем более - это константы. Тем более - что константы и "когда мы закончим отлаживать проект, оценить эффективность любого программера и прикинуть количество багов в проекте".
Так конкретный законченный вывод где??

даа... почитал ресурс.. ну киздец.. какое же унылое г.вно...

(9) вот ты пришел и принес еще кучку его.. откуда же там алмазы возьмуться..?

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

(11) тут я поддерживаю... сам стараюсь "выносить" код в голове... если чувствую что "не готово" - писать стараюсь не садится.. ибо хня получается как правило... у мну вообще первое правило - если работа не идет.. туго.. со скрипом.. (вазелин не предлагать!) - первый признак т ого. что не все дотумкано как надо.. зато когда дотумкано - все упирается тупо во время и тщательное написание кода (наскольо это возможно)

(11) Эх еще бы заказчиков бы нормальных.
"Ааа караул, нам срочно еще вчера нужен отчет которые должен выводить вот эту фигню". Быстро на коленках делаешь, что просят. Потом начинается, ой еще тут добавь тут убавь и вообще мы подумали и нам еще это нужно (далее идет такое хочу, что думаешь что проще или с нуля все нарисовать, или костыли приделать)

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

(13) ну.. тут только опыт спасает.. или поднятие за каждую "ой тут еще.." - цены работы в арифметической прогрессии... заодно выясняется готовность/масштабы клиента...

(13) Это ты вкарце описал agile vs waterfall.
Помоему agile уже победил. Просто закладывай время на плановый рефакторинг

(1) также не учтены еще 2 переменные, морковка спереди, и морковка сзади

Злопчинский вынес на обсуждение какую-то фигню (цэ)