Его подход основывается на принципе Эйнштейна "умный человек решает проблему, а мудрый ее обходит".
[spoiler]Брайтон предлагает:
- регулярно вести список ошибок;
- выявлять в нем типовые (шаблонные) ошибки;
- перепроектировать процесс разработки так, чтобы эти шаблоны исключить.
В итоге же не потребуется ни тренировок в избегании ошибок, ни дополнительного тестирования, а выигрыш будет существенным, так как исключаются ошибки массовые.
Вопрос, как же (в каком направлении) процесс разработки перепроектировать. Правильный процесс создания практически чего угодно (применительно например к дизайну) характеризуется такими особенностями:
- легко делать правильно;
- трудно делать неправильно;
- когда это выглядит правильно, это правильно;
- когда это выглядит неправильно, это неправильно.
Один из наиболее известных подходов к формированию такого процесса -- это применение шаблонов безошибочного кода. Программисты, которые готовятся по типовым учебным курсам, и ошибки допускают типовые и одинаково унылые, статистика эти ошибки давно уже посчитала, и рекомендации выработаны проверенные и надежные. Другое дело, что их крайне мало кто применяет (во многом, кстати, из-за жадности горе-руководителей -- кодирование по стандартам требует больше времени на первых этапах, зато впоследствии на отладке экономится на порядки больше), но это тема для обсуждений бессмысленная.
Брайтон в качестве одного из образцовых примеров приводит подробный стандарт кодирования на С++ для истребителя F-35 (объем бортового кода этой машины, напомню, больше, чем в Windows XP, где-то под 10 млн. строк кода -- и это в ситуации, когда отладка из-за аппаратной специфики весьма затруднена). Скачать его можно со странички Бьярна Страуструпа (pdf).
Еще один отличный стандарт -- Cert (C Secure Coding Standard), разработанный в институте программной инженерии SEI при университете Карнеги-Меллона (это где создана модель зрелости программных процессов CMM) при поддержке специалистов ISO.
Все подходы к минимизации ошибок Брайтон делит на две группы:
Субъективные.
- полагаться на удачу/авось;
- применять стандарты кодирования;
- использовать средства статического анализа кода;
- регулярно проводить обзоры кода, т.н. метод пристального взгляда (одно из важных правил, на котором категорически настаивает SEI);
- организовывать качественное обучение;
- нанимать хороших программистов.
Объективные.
- делать ошибки трудными для "создания";
- делать ошибки невозможными;
- делать правильный код легко пишущимся.
В этом как раз и помогут новые языки (например, D и Go из предыдущего поста) -- их грамматика не допустит множество потенциально ошибочных конструкций.
