Убийца больших программных проектов
Каждый фикс порождает, с некоторой вероятностью - баг. Этот процесс вероятностный, но в среднем есть некий коэффициент порождения багов (регрессия). Другими словами, каждый фикс порождает, к примеру 0.1 баг. Это значит что 10 фиксов в среднем дают 1 баг. Вот этот "0.1" это и есть коэффициент порождения багов. Так вот этот коэффициент, зависит от многих факторов. В основном от квалификации разработчиков и размера проекта. Чем больше проект тем больше коэффициент, чем выше квалификация разработчиков - тем ниже коэффициент. А теперь внимание вопрос: что будет, если коэффициент порождения багов станет больше единицы? Это будет значить, что каждый фикс, в среднем порождает больше багов чем исправляет. В такой ситуации проект будет всё хуже и хуже. Это смерть под собственным весом. На некоторое время, ситуацию можно полечить увеличением квалификации разработчиков, и улучшением прочих факторов влияющих на коэффициент порождения багов, но это не устранит самый ужасный фактор - увеличение количества кода. Более того, в любом (наверное в любом) случае, количество кода будет расти со временем, а вместе с ним будет расти и коэффициент багов.
Сейчас я вижу всего два принципиально разных вариантов дальнейших действий. Первый - закрыть проект. Второй - какими-то путями бороться с увеличением кода в проекте. Второй способ кажется возможным, потому что есть большие программы, работающие поверх больших операционных систем. Вместе они (система и приложение) образуют огромнейшую систему, размер которой настолько большой, что в случае объединения в один проект, коэффициент порождения багов вырос бы настолько, что система не дожила бы до релиза, развалившись "под собственным весом". Но при этом по отдельности они живут.
Интуитивно я чувствую что проведение границ между отдельными частями проекта - важно, и что в совокупности оно снижает коэффициент порождения багов. Несмотря на то что совокупный размер проекта остаётся прежним или даже растёт (за счёт необходимости стыковки отдельных частей). Но ведь на огромной операционной системе, работают огромные приложения. И они таки работают. Наверное важную роль также играет то, что на одной операционной системе работает много программ, и все их разработчики так или иначе (посредством баг-репортов) делают вклад в разработку операционной системы (что само по себе увеличивает эффективное количество разработчиков операционной системы), но всё же ключевым мне сейчас кажется другое. А именно - проведение чётких и особенно важно понятных границ между отдельными частями проекта. Хотя в целом, это не решает проблему роста коэффициента багов, а всего лишь ещё один способ уменьшить его, тем самым отложив на некоторое время "первый вариант действий" т.е. закрытие проекта.
Сейчас я вижу всего два принципиально разных вариантов дальнейших действий. Первый - закрыть проект. Второй - какими-то путями бороться с увеличением кода в проекте. Второй способ кажется возможным, потому что есть большие программы, работающие поверх больших операционных систем. Вместе они (система и приложение) образуют огромнейшую систему, размер которой настолько большой, что в случае объединения в один проект, коэффициент порождения багов вырос бы настолько, что система не дожила бы до релиза, развалившись "под собственным весом". Но при этом по отдельности они живут.
Интуитивно я чувствую что проведение границ между отдельными частями проекта - важно, и что в совокупности оно снижает коэффициент порождения багов. Несмотря на то что совокупный размер проекта остаётся прежним или даже растёт (за счёт необходимости стыковки отдельных частей). Но ведь на огромной операционной системе, работают огромные приложения. И они таки работают. Наверное важную роль также играет то, что на одной операционной системе работает много программ, и все их разработчики так или иначе (посредством баг-репортов) делают вклад в разработку операционной системы (что само по себе увеличивает эффективное количество разработчиков операционной системы), но всё же ключевым мне сейчас кажется другое. А именно - проведение чётких и особенно важно понятных границ между отдельными частями проекта. Хотя в целом, это не решает проблему роста коэффициента багов, а всего лишь ещё один способ уменьшить его, тем самым отложив на некоторое время "первый вариант действий" т.е. закрытие проекта.