Некоторые говорят, что разработка программного обеспечения является сложной из-за  сложности . Это может быть правдой, но это определение не помогает нам находить решения для уменьшения сложности. Нам нужен лучший способ объяснить сложность нетехническим людям.

Реальность такова, что при кодировании размер проекта  имеет значение . Размер измеряется количеством путей через базу кода, а не количеством строк кода. Размер пропорционален количеству  функциональных точек  в проекте.

Есть много ИТ-специалистов, которые преуспевают с программами определенного размера, а затем с треском проваливаются, принимая более сложные программы. Сложность возрастает с увеличением размера , поскольку число путей увеличения экспоненциально  в больших программах.

Практически любой (даже генеральный директор :-)) может построить  привет, мир!  применение; приложение, которое имеет только один путь через него и настолько простое, насколько вы можете получить. Некоторые руководители пишут просто  привет, мир!  Программируют и  неправильно убеждают себя, что разработка проста . Привет мир!  есть только один путь, и практически любой может написать это. 

main() { 
     printf( "hello, world" ); 
}

Сложность определена

По мере того как программы становятся более сложными, количество решений  , которые необходимо принять, увеличивается, а глубина дерева вызовов  увеличивается . Каждая нетривиальная рутина будет   проходить через нее несколько путей .

Если ваша средняя глубина вызова составляет 10 со средним числом 4 путей в каждой процедуре, то это представляет более  1 миллиона путей. Если средняя глубина вызова составляет 15, то это представляет  107 миллионов  путей. Растущие сложные программы имеют большую глубину вызовов, чем когда-либо, а распределенные приложения увеличивают глубину вызовов, даже если глубина вызовов системы является аддитивной. Это то, что мы подразумеваем под  сложностью; для нас невозможно проверить все различные пути в стиле черного ящика.

Теперь в действительности каждая комбинация путей невозможна, но вам нужно всего лишь оставить пробелы в нескольких подпрограммах, и у вас будут сотни, если не тысячи путей, где вычисления и решения могут пойти не так.

Кроме того, неправильные вычисления или решения, расположенные выше в дереве вызовов, могут привести к трудностям в поиске дефектов, которые могут взорваться намного дальше от источника проблемы.

Какие дефекты?

Мы признаем, что имеем дефект, только когда видим выходное значение и признаем, что оно неверно. Скорее всего, QA видит это и говорит нам, что мы не правы.

По сути, мы следуем по правильному пути через узлы 1, 2, 3, 4 и 5. В точке 6 мы делаем  расчет просчета , а затем у нас неправильные значения в точках 7 и 8 и обнаруживаем  проблему в узле 9. Поэтому, как только у нас произойдет просчет, мы будем либо продолжать делать неправильные вычисления, либо принимать неправильные решения и идти по неверным путям (где мы затем будем делать неправильные вычисления). 

Не все дефекты равны

Ясно, что чем больше расстояние между просчетом и его обнаружением, тем труднее  будет обнаружить дефекты  . Чем длиннее глубина вызова, тем больше вероятность того, что между источником и обнаружением может быть большое расстояние, другими словами:

Сегодня мы создаем сложные системы из множества взаимодействующих приложений, и глубина вызовов экспоненциально зависит от размера системы. Это то, что мы подразумеваем под 
сложностью  программного обеспечения. 

Уменьшение сложности

Сложность уменьшается для каждой функции, где: 

• Вы можете определить, когда непоследовательные параметры передаются в функцию
• Все вычисления внутри функции выполнены правильно
• Все решения через код принимаются правильно

Лучший способ решить все 3 проблемы — это формальное планирование и разработка. Двумя методологиями, непосредственно ориентированными на планирование на личном и командном уровне, являются «  Процесс персонального программного обеспечения» (PSP) и «  Процесс  группового программного обеспечения» (TSP), изобретенный Уоттсом Хамфри.

Выявить противоречивые параметры проще всего, когда вы используете  Design By Contract  (DbC), метод, впервые внедренный в язык программирования Eiffel. Важно использовать DbC для всех функций, которые находятся в основных путях приложения.

Использование разработки через  тестирование  — это верный способ убедиться, что все вычисления внутри функции выполнены правильно, но только если вы пишете тесты для каждого пути через функцию.

Убедиться в том, что все вычисления внутри функции выполняются правильно и что правильные решения принимаются с помощью кода, лучше всего выполнять с помощью проверок кода (см. « Проверки не являются обязательными»,  а «  Специалисты по программному обеспечению выполняют проверки» ). 

Вывод