Цитирую:
Давно это было. Наехал на меня начальник: мол, вы что-то делаете-делаете, а ни хрена не видно. Ну, я в сердцах слил статистику из репозитория, построил графики и всякие аппроксимации методом наименьших квадратов и малость охренел сам. Вот настоящая научная работа на академическом уровне. Если бы я был академиком, я бы сделал все, чтобы продолжить эти исследования.
Написание проекта можно рассматривать как переходный процесс из состояния 0 (ничего нет) в состояние 1 (проект готов). Из курса ТАУ я ещё помнил дифуры второго порядка для затухающих колебаний, но увидеть такой график, разглядывая динамику количества строк в проекте, не ожидал. Шутки ради по той же схеме проанализировал коммиты всех подчинённых — картина та же, хоть и менее явная. Потом поднял статистику фиксации багов и нашёл аналог длины свободного пробега молекулы в газе.
В общем, так.
1. Достаточно большой софтверный проект как макросистема описывается с достаточной точностью дифуром второго порядка (затухающие колебания в вязкой среде), то есть двумя числами. Каждый программист может быть описан теми же двумя числами. Примерный смысл на бытовом уровне: как быстро человек пишет код и как быстро он правит баги.
2. Коэффициент затухания («вязкость», сопротивление изменениям) у всего софтверного проекта больше, чем у любой его подсистемы или у отдельного программиста. Период колебаний у программера практически всегда равен двум суткам: залил — все потестили — залил фикс. Как минимум 20% строк первоначального коммита будут поправлены — тоже интересная константа.
3. Совместно работающие программисты подчиняются правилу сложения источников белого шума: суммарная эффективность равна корню из их числа.
4. Время фикса бага пренебрежимо мало по сравнению со временем его жизни. Чтобы нарваться на баг, надо тестить. Никакие другие методы, увы, не помогут. Время жизни бага растёт экспоненциально в зависимости от количества пофикшенных.
Вот так. Рассчитав всего два числа, я могу сказать, когда мы закончим отлаживать проект, оценить эффективность любого программера и прикинуть количество багов в проекте, исходя из частоты подачи рекламаций. Но, что самое печальное, это константы. Я не могу повлиять на них точно так же, как не могу изменить ускорение свободного падения.
Супер
November 5 2011, 17:41:29 UTC 7 years ago
November 5 2011, 19:28:15 UTC 7 years ago
November 6 2011, 06:27:32 UTC 7 years ago
Это исследование несомненно гениальное, но совсем не мое.
Я просто наткнулся в Сети и посчитал долгом опубликовать по всем доступным мне каналам.