Баги, которые нельзя победить
Откуда в системе берутся ошибки? Ответ, который кажется всем очевидным и лежащим на поверхности, это недоброкачественная работа того или иного специалиста. Кому-то может показаться, что вот если бы все участники команды работали ответственно и качественно, багов и ошибок в системе бы не было вовсе. Но я думаю, что это не так.
Почему в системе появляются баги? Есть две группы причин: плохое исполнение и ошибки в архитектуре, в проекте. Представим, что у нас идеальное исполнение, исключающее ошибки, а может ли быть идеальная архитектура?
Наверное, да, если это простая система, функционирующая в ограниченных условиях, созданная одним хорошим специалистом. А что делать, если система сложнее? Что если система такая сложная, что ее уже не только не может сделать один специалист, но один специалист не справится и с ее проектированием? Ответ очевиден - систему надо дробить на составные части. Одна команда разработчиков делает один узел, вторая другой, а третья интерфейс взаимодействия этих узлов. Приблизительно так проектируется и разрабатывается любой сложный продукт - и большой софт, и автомобиль, и здание.
Но чем сложнее продукт, чем больше «узлов» и интерфейсов их взаимодействия, чем больше команд участвует, тем выше вероятность возникновения сценария, не предусмотренного проектом, а следовательно появления ошибки.
Проще говоря, при определенном размере продукта, он станет уже настолько сложным, что невозможно описать и предусмотреть все возможные комбинации взаимодействия узлов, кусков кода, друг с другом. А следовательно, при усложнении системы рано или поздно вероятность появления ошибки будет 100 %. Но как тогда делать большую и сложную систему и при этом обеспечить высокий уровень надежности и отказоустойчивости? Например, нам надо ракету запустить или атомную электростанцию.
Ответ прост. Если нельзя избавиться от ошибок, значит нужно минимизировать их последствия. Есть только один способ обеспечить надежность сложной системы - это сделать ее устойчивой к появлению ошибок. Диагностировать некорректное поведение системы на ранних стадиях, предусмотреть возможности отключения частей системы при их некорректной работе, заложить дублирование функций разных узлов.
Но это не решение проблемы, а лишь борьба со следствием. Как, все-таки, сделать так, чтобы ошибок на уровне архитектуры было меньше, как повысить качество проекта в будущем, сделать так, чтобы хотя бы следующая версия продукта была лишена обнаруженных архитектурных недочетов.
Приблизительно такую задачу ежедневно решает автомобилестроение. Если посмотреть на статистику отказов, то обнаружится, что японские промышленники выдают продукт с минимальным количеством брака на этапе производства. Но любопытно, что по статистике ADAC среди 10-летних машин количество отказов уже минимальное у немецких автомарок. Почему? Потому что, сделать качественный продукт на этапе выпуска - это задача, сугубо производственная (задача исполнения), с которой отлично справляются в Японии, а вот сделать так, чтобы машина оставалась надежной на протяжении долгого периода эксплуатации - это уже задача архитектурная. А как этого достичь, если мы не можем все с самого начала хорошо спроектировать, предусмотреть все сценарии эксплуатации? Мне кажется, секрет в том, чтобы тщательно анализировать реальные данные по использованию, выявлять ситуации, не предусмотренные проектом, фиксировать их и учитывать при следующем проекте. Именно поэтому производство современного надежного автомобиля это не только тщательное проектирование и культура производства, но и уникальные методики сбора и анализа статистики отказов, параметров эксплуатации, опыта сервисов и потребителей - это культура управления поступившими знаниями и их учет при проектировании последующих версий системы. И это прекрасный пример того, как все-таки избавляться от ошибок на системном уровне.
Если перед вами стоит задача поднять не только качество исполнения, но и качество проектирования и как следствие уменьшить количество ошибок, вы должны не столько уповать на проработку системы на этапе проекта, сколько на анализ опыта эксплуатации и внесение правок в следующих итерациях.