Несмотря на довольно большое количество научных исследований более чем за полвека развития и в computer science и в программной инженерии, в 99% организаций, занимающихся разработкой софта, при создании очередной новой системы мы встретим единый шаблон: код пишется вручную с нуля, а проектирование системы выполняется на глазок. Этот подход изначально дорог и подвержен множеству ошибок, независимо от того, какие языки программирования, какие фреймворки, какие наборы стандартных библиотек и какие методологии разработки мы используем.
Эли Уитни ещё в 1784-м году придумал технологию массового промышленного производства и принципы разделения труда и взаимозаменяемости деталей, и успешно произвёл 10 тысяч мушкетов по своей универсальной технологии. И хотя сроки первого заказа он затянул на восемь лет :) , зато второй заказ, уже на 15 тысяч мушкетов, выполнил всего за два года.
Сегодня массовые технологии разработки софта находятся на уровне 18-го века и не способны реализовать даже принципы Уитни. Поэтому применительно к ним действует и ещё достаточно долго будет действовать ряд вечных эмпирических законов из программной индустрии и смежных инженерных сфер.
Boehm’s Second Law
Прототипирование существенно снижает процент ошибок, связанных с проектированием программы.
Перед созданием крупной системы настоятельно рекомендуется создать её прототип объёмом примерно в 10%, в котором будут реализованы все наиболее сложные и непонятные моменты. На следующих итерациях можно использовать элементы этого прототипа, или разрабатывать всё с нуля, но тоже не браться сразу за весь проект целиком, а воплощать очередную часть и изучать, насколько правильно и эффективно она работает.
Хорошие системы нередко переписываются с нуля по три раза, и это нормально.
Barry Boehm -- очень известный американский профессор-математик, получивший огромное количество почётных титулов, возглавлявший компьютерный департамент DARPA, автор системы оценки стоимости софта COCOMO и спиральной модели разработки.
Jones’ Law of Defect Removal Efficiency
Каждая форма деятельности по удалению багов характеризуется своим особым уровнем эффективности, или процентом реально находимых ошибок.
Метрика defect removal efficiency (DRE) была разработана в IBM ещё в 1970-х годах, но активно применяется в корпорации и по сей день. По статистике 26 тысяч программных проектов, DRE для тестирования показывает 35% (выявляется лишь один баг из трёх), системы статического анализа кода выдают 55% (каждый второй баг может быть найден качественным линтером по сути автоматически), ну и code review (пресловутый метод пристального взгляда) остаётся непревзойдённым: 85%. Кстати, в Personal Software Process Карнеги-Меллона большое внимание уделяется именно обзорам кода.
По стандартам International Software Benchmark Standards Group, DRE измеряется так: количество багов, о которых сообщили пользователи в течение первых 30 дней использования софта (это баги, которые по сути не были найдены) к общему числу багов. Точнее, единица минус это отношение. Например, если юзеры сообщили о 100 ошибках, а пофикшено было в процессе разработки 900 багов, то DRE составит 90%.
В сегодняшних проектах IBM суммарная метрика DRE немного не дотягивает до 90%, а топовые мировые проекты характеризуются 99% уровнем качества, однако и затраты на обеспечение такого качества пока очень высоки. Более того, повсеместно применяются вредные метрики вроде "стоимости бага", которые только снижают качество и провоцируют выпуск сырых продуктов.
В общем, идея DRE в том, что нету единой универсальной/массовой технологии обеспечения высокого качества кода, и поэтому надо применять вместе хотя бы три основных подхода, а результирующее качество контролировать правильными метриками.
Weinberg/Okimoto Law of “TEMP” Hazards
или "нет ничего более постоянного, чем временное".
Любая программа, в коде которой имеется строка "TEMP", будет проблематична в сопровождении, потому что была разработана небрежно.
Weinberg также активно изучал проблему error-prone modules (EPM) -- модулей кода, в которых имелось немало ошибок. Как оказалось по множеству независимых исследований, фактически все они не проходили один из этапов проверки качества: обзор кода, статический анализ, формальное тестирование.
Gerald Weinberg -- американский учёный в сфере computer science, автор 40 книг, специалист по психологии разработки программного обеспечения, наиболее известны "The Psychology of Computer Programming" и "Introduction to General Systems Thinking".
Самый знаменитый и самый известный закон Вайнберга:
если бы строители строили здания так, как программисты пишут программы, то любой дятел мог бы разрушить цивилизацию.
Фактически, одна строчка кода, добавленная в "нужное" место в проект любой сложности, если он был создан "на коленке", без соблюдения важных принципов надёжности, может разрушить его полностью.
Однако это т.н. Второй закон Вайнберга. А Первый его закон гласит, что если уж программа не может быть безошибочной, то как минимум она должна удовлетворять всем другим проектным требованиям.
Действительно, мы каждый день пользуемся программами с ошибками, некоторые из них работают ощутимо плохо, однако если они нам нужны и аналогов им нету, мы продолжаем эти программы эксплуатировать.