6.4 Программирование

Спецификации модулей можно рассматривать как технические задания группам программистов (рис. 6.3) на кодирование (программирование) внутренней логики каждого модуля.

Этот процесс состоит из следующих действий:

1) изучение спецификации модуля – проверяется правильность, понятность и внутренняя непротиворечивость информации;

2) выбор языка программирования, если это не сделано на этапе выработки требований к ППП. Использование того или иного языка программирования часто предопределено имеющимися у заказчика вычислительными ресурсами (для заказного ППП), принятыми у разработчика стандартами, уровнем квалификации программистов;

3) выбор алгоритма и структуры данных – или выполняя оригинальные разработки, или используя опыт предыдущих работ;

4) собственно программирование;

5) компиляция (трансляция) модуля – это действие уже означает переход к тестированию модуля. Компилятор, строя машинную программу, проводит проверку правильности синтаксиса и частично семантики исходной программы.

Очень большое влияние на качество создаваемой программы оказывает стиль программирования. Пять десятилетий программирования для электронно-вычислительных машин выработали свои правила, приемы, формы программирования, которые, в принципе, являются общими, независимыми от конкретного алгоритмического языка¹.

Стилю программирования посвящено немало замечательных книг, например, «Стиль, разработка, эффективность, отладка и испытание программ» Д. Ван Тассела [7].

Под фактором хорошего стиля программирования автор, прежде всего, понимает простоту и «удобочитаемость» программы (реализация знаменитого KISS – принципа: Keep It Simple, Stupid!). В частности, он отмечает: «Начинающие программисты думают, что они пишут программы для машин. Опытные программисты знают, что программы пишут для людей». Другим фактором, в некоторой степени определяющим первый, является использование идей структурного программирования [8], которые соответствуют общим принципам структурного подхода:

1. разбиение задачи на ряд небольших подзадач;

2. широкое применение стандартных подпрограмм;

3. использование простых логических программных структур: линейной (например, операторы присваивания), ветвления (например, оператор ЕСЛИ) и циклической (например, DO).

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

Переход к спиральной модели жизненного цикла ППП привел к появлению экстремального программирования (ХР – eXtremely Programming)², как стилю и методу современного программирования (рис. 6.4).

Основные принципы ХР – это достаточно простые и здоровые идеи, применяемые в экстремальных ситуациях:

• стремиться к простоте (все тот же KISS – принцип);

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

• двигаться вперед по мере конкретизации стоящих перед вами задач (не тратить время на создание чего-то грандиозного и всеобъемлющего);

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

• работать напрямую с потребителями и пользователями, стремясь превратить их в участников группы разработки;

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

• стимулировать постоянную переработку кода (то есть переписывание и совершенствование программ).

ХР предполагает изменение методов работы программистов. Более того, оно основано на новой философии разработки программ – парном программировании. Парное программирование – это, возможно, самый спорный аспект ХР. Этот метод предполагает, что два программиста на одном и том же компьютере пишут текст программы и, тем самым, сокращается вероятность создания ошибочного кода.

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

Как начинается проект разработки для парного программирования? В рамках модели ХР большая часть работы над проектом формулируется с помощью карт CRC (Class, Responsibility, Collaboration – «класс, обязанности и сотрудничество») – листов бумаги, представляющих собой объекты данного проекта.

Перед началом проекта рабочая группа проводит встречи, на которых моделируются взаимосвязи всех известных объектов, причем карты CRC используются для наглядности. Программистам приходится обсуждать аспекты, вызывающие наибольшие сомнения, и убирать или добавлять новые карты, чтобы отразить изменения в плане. Описывая объекты как отдельные сущности, сложные концепции можно упростить, превратив их в понятную структуру.

Результатом этапа CRC становится список небольших задач. Разработчики разбиваются на пары, и каждая пара определяет модульный тест для выделенной ей задачи. Следует отметить, что такие тесты создаются до того, как начинается сам процесс кодирования. По словам сторонников ХР, такой подход упрощает и ускоряет разработку приложений: тесты при этом пишутся более аккуратно, поскольку они служат для проверки критически важной функциональности, кроме того, улучшается обратная связь, позволяющая точно определить, что именно требуется сделать. Иными словами, отпадает необходимость тратить время на создание огромных тестов для проверки работоспособности проекта в целом.

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

Как только код, реализующий решение задачи, за которое отвечала та или иная пара, завершен, запускается определенный ранее тест. Если тестирование завершается успешно, код интегрируется в репозитарий (хранилище), где к нему могут обращаться все члены группы разработчиков. Измененный код должен помещаться в репозитарий каждые несколько часов (по крайней мере, раз в сутки). При этом все разработчики будут получать актуальный код – такой подход снижает вероятность возникновения в проекте ошибок, связанных с нестыковкой версий.

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

Последний шаг – выполнение всех модульных и функциональных тестов. Вполне вероятно, что этот процесс придется повторить несколько раз, пока не удастся достичь корректной работы и взаимодействия всех объектов. Может понадобиться провести несколько CRC-сессий; объекты, не прошедшие функциональное тестирование, должны быть переданы для доработки другой паре программистов¹.

Сторонники ХР исходят из того, что если уж проект обречен на неудачу, то лучше признать это сразу и уберечь себя от бессмысленной траты времени и средств. Вместо того, чтобы не покладая рук трудиться над всеобъемлющей спецификацией программы, а затем выше головы загрузить своих программистов на полгода; разработчики, придерживающиеся методологии ХР, создают программы путем небольших итераций и пишут самый простой работоспособный код. При таком подходе нет необходимости заниматься предупреждением ошибок, которые могут никогда не возникнуть, или вводить возможности, которые никогда не потребуются.

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