CC BY
74
Нв4(10) 2007
А.В. Леденев, И.А. Семёнов
Программирование ПРОТИВ проектирования
Наряду с задачами классификации, внедрения и применения информационных систем перед специалистами в области информационных технологий сегодня по-прежнему остро стоят проблемы, связанные непосредственно с проектированием и разработкой программного обеспечения. Быстрые изменения в отрасли IT, появление все большего числа инструментов взаимосвязано с необходимостью пересмотра, коррекции и развития принципов и парадигм как проектирования, так и кодирования.
Все мы уже привыкли, что программирование— трудоемкий, сложный процесс, затрагивающий многие области современной жизни. Его трудоемкость составляет львиную долю затрат, связанных с построением информационной системы, в то время как доля стоимости аппаратной части системы постоянно снижается (рис. 1).
Рис. 1. Изменение стоимости программного и аппаратного обеспечения
Необходимо отметить также и тот факт, что трудоемкость этого процесса в настоящее время напрямую связана с информационным охватом программного обеспечения (ПО). Разрабатываемое ПО строится для решения сложных задач в условиях определенной интеграции всех сфер человеческой жизнедеятельности.
Давно уже подмечено, что в связи с вышеперечисленными особенностями, разрабатывать новое ПО «с нуля» — далеко не всегда оправданный шаг. Помимо не очень приятного процесса наступания на одни
и те же «грабли», требуются существенные денежные вливания и временные затраты. «Время — деньги» — это суровое правило нашей жизни стало такой же привычной аксиомой, как и, например, «Реклама — двигатель торговли». Для этого разработаны различные методики, позволяющие значительно сократить или приблизить к ожидаемым денежно-временные ресурсы, связанные с конкретным проектом.
Среди подобных методик можно отметить структурное проектирование (модульное построение); CASE-проектирование (Computer Aided Software Engineering — автоматизированное конструирование ПО) с поддержкой системы прототипирования (активное использование методических, технологических и программных наработок из предшествующих проектов); сборочное проектирование (технология открытых систем); RAD-проектирование (Rapid Application Development — быстрая разработка приложений).
Обычно в работах по данной тематике затрагиваются проблемы, связанные с умением правильно и быстро оценить архитектуру системы, а также с влиянием действий, осуществляемых на данных этапах и связанных с проектированием системы, на последующие, в том числе и на этапы физического проектирования (кодирования) системы.
Особое внимание следует уделить влиянию этапа кодирования на процесс программирования в целом, и этапу проектирования, тоже, как ни парадоксально это звучит. Ведь зачастую уже на этапе кодирова-
133
No4(10) 2007
ния по тем или иным причинам приходится возвращаться к этапу проектирования. И вот тогда эта связка очевидна. Особо стоит упомянуть итерационный подход при программировании — в этом случае код программы играет еще более важную роль.
Некоторые вопросы проектирования и его влияние на последующие этапы рассмотрены в [1-3].
Программирование ПРОТИВ проектирования?
Итак, под проектированием следует понимать процесс, способствующий построению архитектуры системы, т. е. в определенном смысле формальной модели, адекватно описывающей условия математической постановки задачи/требования заказчика.
Весь процесс разработки принято условно делить на следующие этапы:
• предпроектный анализ (включает формулирование технического задания и технико-экономического обоснования);
• техническое проектирование (ТП);
• физическое(рабочее)проектирование (ФП);
• внедрение;
• эксплуатация;
• сопровождение.
В зависимости от целей, преследуемых конкретным разработчиком, количество § этапов может быть сокращено до 3-4, в ча-§ стности, именно столько этапов использует ^ RAD-проектирование. | В литературе можно найти данные, сви-|| детельствующие о важности тех или иных § этапов разработки системы в зависимости
I
I
«о со
!
8-¿1
от применяемой стратегии разработки (табл. 1).
Из таблицы следует, что применяемые стратегии используют проектирование, как один из основных этапов разработки системы. При этом очень сильно изменены (по отношению к классической разработке) ре-сурсо-временные характеристики, затрачиваемые на последующие этапы.
Таким образом, сильные наработки на этапе проектирования дадут существенную инерционную свободу в развитии данного проекта на последующих этапах. Этот существенный плюс настолько ошеломляет многих, что они забывают о других подводных камнях, которые встречаются на пути ничего не подозревающего разработчика:
• планы проекта не увязаны со стратегией развития организации;
• принципы построения проекта и организации не совмещены;
• вектор проектного развития не соответствует вектору задач, к которым в дальнейшем этот проект будет применяться;
• недостаточная поддержка руководства.
Получается, что произведя значительные затраты на процесс проектирования (до 40% времени) и некоторое количество на разработку (5-10%), могут возникнуть непредвиденные условия, в результате чего проект придется пересматривать заново.
По закону обнаружения ошибок, вероятность нахождения ошибки на конкретном этапе прямо пропорциональна числу ошибок, уже обнаруженных на этом этапе. Таким образом, данный процесс может неоднократно повторяться.
Таблица 1
Учет ресурсных показателей построения проекта системы при использовании различных стратегий, %
Стратегия Анализ Проектирование Кодирование Тестирование
Классическая 20 15 20 45
Структурная 30 30 15 25
CASE 40 40 5 15
134
Нв4(10) 2007
Заметим, что рассматриваемые вопросы носят несколько субъективный характер, связанный с личным опытом и мастерством конкретного руководителя определенным проектом.
Тем не менее, подобные «если» не лишены здравого смысла. Вывод, который мы сделали на основе изложенных выше рассуждений — одним только проектированием при построении системы не обойтись. И связано это с тем, что процесс проектирования носит доминирующий характер над всеми другими этапами разработки ПО, в том числе и над следующим непосредственно за ним этапом физического проектирования. И что самое важное — вектор доминирования (взаимодействия) имеет всегда одно направление:
ТП ^ ФП.
Имея уже опыт в разработке ПО, можно выделить отдельную составляющую, возникающую при «кодировании» логики программы, называемую «сомнительным кодом».
Сомнительный код (СК) — участок программы, работающий и, казалось бы, правильный, но сомнительно реализованный, не отлаженный и не оттестированный, который потенциально может быть причиной сбоев всей программы.
Множество участков СК образуется на начальном этапе разработки программы, когда программист не уделяет достаточного внимания отдельным небольшим частям, стремясь обрисовать ее в целом. Синдромом СК обычно страдают не основные ветви программы или участки кода, которые редко выполняются. Сомнительный код бывает двух видов: синтаксический, где сомнение вызывают синтаксические конструкции языка, и логический, где сомнителен используемый алгоритм.
Надежных методов обнаружения участков СК не существует. Программист находит их на основании своего опыта, а зачастую ему помогает интуиция. Он, как правило, не может объяснить, что именно ему не нравится в коде. Если какой-то участок вашей про-
граммы кажется «некрасивым», вызывает § необъяснимые сомнения или раздражает, скорее всего, это — СК. Не надо стесняться <2 спросить совета у своих более опытных кол- ^ лег по поводу обнаруженного участка СК. <о
Как показывает практика, лишь освое- ;§ ние в полной мере средств языка, которые ¿ц используются в ходе работы над проектом, оо позволяет обрести то самое шестое чувст- ^ во, необходимое для обнаружения СК. Как правило, дело даже не в накопленном опыте по разработке похожих задач, а именно в проблеме наработки определенных шаблонов и приемов программирования, когда используемый инструментарий языка сразу же подсказывает, что такое «хорошо» и что такое «плохо».
Можно со здоровой долей скептицизма относиться к факту составления таблицы химических элементов Менделеевым во сне, но прошедшая практика подтверждает данную теорию фактами: СК может быть обнаружен умозрительно, на основе случайных (возможно, даже не связанных с проблемой) жизненных происшествий и ассоциаций или даже во сне (без явной необходимости прогона программы и захода в сомнительный блок).
Наличие СК в программе несет в себе также дополнительный подводный камень — отвлечение внимания от действительных ошибок и, возможно, более серьезных проблем. При просмотре написанного кода СК моментально отвлекает внимание опытного программиста от сути текущей решаемой проблемы, заставляя задумываться над логикой поведения, как правило, внезапно обнаруженного участка СК. Проще один раз исправить СК, чтобы в будущем не отвлекаться на решение возникающей из раза в раз проблемы — что данный фрагмент СК делает, в чем заключается логика его работы и т. д.
Итак, субъективизм построенного проекта с точки зрения качества связан с личными характеристиками менеджера проекта, например, его опытом, квалификацией, личным видением проблемы и пр.
135
№4(10) 2007
Подобные аналогии можно выделить и при рассмотрении процесса «кодирования».
Как правило, код, написанный двумя людьми с разной квалификацией, в достаточной степени отличается (возможно, за исключением фрагментов, в которых используются общеизвестные алгоритмы или приемы кодирования). Более того, предоставляя некоторую свободу действий «кодировщикам» (роль которых на наш взгляд очень сильно недооценена в современной литературе) можно получить от двух специалистов поразительно отличающиеся результаты.
И дело здесь не только (и не столько) в чисто личностных моментах, например профессионал/новичок, опытный/неопытный. Дело еще и в уровне требований, предъявляемых менеджером проекта к кодировщикам. Сейчас все эти требования сводятся к простому работает/не работает, т. е. никто особенно не проверяет качество кода. И это в то время, когда повторное использование кода является одним из самых приоритетных направлений развития технологии программирования! Как можно повторно использовать некачественный, сомнительный код? Это приведет к тому, что потенциальные ошибки, не выявленные в этом проекте, будут множиться в других проектах, а выявить и исправить их будет сложно.
Высококлассный специалист, имеющий определенные навыки при выполнении заданий под проект, уже на этапе исполнения § своей работы может «внутренним чутьем» § обнаруживать узкие места как в своей ра-^ боте (которая также в некотором роде явля-§ ется проектированием), так и в работе не-|| посредственно команды проектировщиков. § Назовем данную особенность — пост-сэ проектированием (мини-проектирование на
этапе кодирования). | Такой подход обусловливает двусторон-§ нюю связь этапов технического и физиче-|| ского проектирования: €
ТП о ФП.
а
с Существующая точка зрения выделяет в качестве доминанты проекта (и это, несо-
136
мненно, правильно) стадию технического проектирования, когда на основе входных условий (требований заказчика к системе) создается проект системы, включающий схему архитектуры системы, которая затем детализируется с такой степенью, которая необходима компании разработчика. Последующая стадия физического проектирования (термин «кодирование», на наш взгляд, не совсем уместен и правилен) с этой же точки зрения является простой вехой в жизненном цикле системы.
Но дело в том, что стадия технического проектирования требует более детального анализа и внимания к себе. Необходима двусторонняя связь между ней и последующей стадией физического проектирования. Слова «физическое проектирование» отражают внесение определенных изменений в архитектуру системы. Разумеется, их широта и масштабность не должна носить всеобъемлющий характер. Должны существовать определенные границы — «песочница», за пределы которой программист не должен выходить.
Плюсы подобного подхода:
• возможность меньше времени уделять проектированию (без потери качества);
• возможность уменьшить число итераций, связанных с детализацией проекта;
• возможность раннего и быстрого обнаружения ошибок;
• более четкая структура проекта;
• удобство повторного использования кода;
• понятность кода — тогда исправить ошибку или добавить нечто новое сможет другой программист, причем без обычного «несколькомесячного» копания в коде.
Его минусы:
• требуются более высококлассные специалисты с опытом работы;
• требуются более квалифицированные менеджеры, способные осуществлять контроль качества кода;
N94(10) 2007
• «свобода» в действиях может привести к новым (упущенным и проектировщиком, и «кодировщиком» или добавленным «кодировщиком») ошибкам;
• опасность увести проект по ложному следу.
Специалисты понимают термин «кодирование» не всегда в том значении, которого он заслуживает в действительности. Как невозможно найти две одинаковые звезды на небе, также невозможно в общем случае написать два одинаковых фрагмента кода. Более того, «похожая одинаковость» может быть только с точки зрения визуальной, т. е. с точки зрения получаемого результата и видимого на экране текста программы. Но ведь и сами авторы программы обычно по-разному видят предназначение программы. Б. Страуструп [2] приводит на этот счет замечательный пример: зачем писать объектно-ориентированные программы, сокращающие количество затраченного времени и объемы написанного кода, если вам платят за число написанных строк.
Отметим, что указанные недостатки по большей части решаются высоко квалифицированной командой проектировщиков.
Что касается «границ», устанавливаемых для программиста, выполняющего постпроектирование, то необходимо вводить определенные и достаточно жесткие правила для «кодировщиков». И эти правила должны касаться не только спецификаций и соглашений об именовании функций, классов и переменных. Должны быть оговорены и способы взаимодействия с системой. Если существует несколько способов взаимодействия, все программисты в группе должны использовать только один (например, файловый ввод/вывод). Это оптимизирует код и облегчает его отладку.
Таким образом, рассматриваемый в данной статье подход требует в общем случае, чтобы команда разработчиков системы состояла из высококлассных специалистов.
В заключение хотелось бы привести ряд простых требований, позволяющих, на наш
взгляд, избежать появления СК в програм- § мах. Мы не пытаемся заставить беспрекословно следовать данным требованиям, од- <2 нако полагаем, что они могут помочь в опре- ^ деленных случаях. еа
1
1. При применении любых правил снача- ¿ц ла используйте здравый смысл. оо
2. Сосредоточьтесь на истинном реше- ^ нии проблемы, а не том, которое вам кажется верным с первого взгляда. Неуверенность в понимании задачи — первая причина появления СК.
3. Решайте проблему в общем, а не в частностях, если это возможно (и оптимально).
Пример: проблема — функция в определенных случаях возвращает неправильные значения (или зависает).
Частное решение: написать дополнительный код, который обрабатывает эти случаи.
Общее решение: переписать (исправить) функцию.
В данном примере общее решение более оптимально, чем частное.
4. Используйте инструментарий, который позволяет адекватно оперировать необходимыми понятиями (объектами). Отсутствие подобного удобства — вторая причина появления СК.
Пример: если вы используете С++, то должны точно знать, почему вы выбрали именно этот язык для реализации. Нельзя использовать язык только потому, что так делают все, или вы делали это прежде. Правильно подобранный инструментарий — грозное оружие в умелых руках!
5. Помните, что дело не только в языке, но и в используемых инструментах самого языка.
Пример: программа должна производить сортировку списка объектов. Это не основная, но необходимая часть программы.
137
№4(10) 2007
Плохое решение: на скорую руку написать сортировку любым методом (например, Пузырька). Требуется примерно 10 мин.
Хорошее решение: тщательно написать и отладить Быструю сортировку. Требуется примерно 1 ч.
Наиболее разумное решение: воспользоваться какой-либо стандартной реализацией (на языке С++ — эИ^воП). Требуется примерно 10 с.
6. Используйте единый стиль программирования. Это поможет:
• избежать типичных ошибок;
• быстро понять семантику кода;
• ускорить освоение кода новым специалистом;
• избавиться от появления СК.
• если используется стандартный алгоритм, разумно поместить ссылку на Inter-net-ресурс с его описанием;
• хорошо прокомментированный код не вызывает вопросов у профессионального программиста.
8. Каждое отступление от правил и стиля должны четко комментироваться.
9. Следует выбирать оптимальное значение между эффективностью кода и степенью его читабельности(понятности).
Пример: наиболее критичные фрагменты кода можно оптимизировать вплоть до использования ассемблера (не забывая их подробно комментировать). Менее критичные фрагменты нужно делать более понятными.
7. Придерживайтесь определенных правил комментирования:
• наилучшим образом должны комментироваться наиболее сложные участки кода (например, ядро информационной системы, реализация математических алгоритмов), а также интерфейсные части библиотек;
• разумная достаточность комментариев. Не следует комментировать каждый оператор. Простые участки кода не нуждаются в комментариях. В то же время сложные участки должны комментироваться как
§ можно подробнее, не следует бояться по-§ вторений;
^ • перед вызовом функции должен сто-| ять комментарий, поясняющий, что делает || функция;
§ • внутри функции, в самом начале (или о перед ее объявлением/определением) должен стоять комментарий, поясняющий, что | функция делает, и какие параметры ей пе-§ редаются;
II • в том случае, если для комментирова-| ния кода требуется подробное описание, которое нецелесообразно размещать в комментарии, следует поместить ссылку, например, на внешний файл;
138
10. Помните: преждевременная оптимизация — корень всех зол [4]!
11. Если участок кода кажется сомнительным, исправлять его бесполезно. Как правило, попытки исправить СК приводят к еще большим проблемам, ведь СК обычно не содержит ошибки в явном виде. Самое лучшее — полностью переписать этот участок. Не бойтесь переписывать его до тех пор, пока ясно не увидите отсутствие СК. Это поможет вам и вашим последователям.
12. Кодирование — не есть механический процесс. Помните об этом! Определенная широта кругозора (способность видеть несколько «дальше» установленной границы) просто необходимы.
Вместо заключения
На наш взгляд, в современной литературе не отдают должное роли «программиста-кодировщика».
Ошибочно полагают, что «проектирование решит все проблемы». Это утверждение не вполне корректно. Дело в том, что такие проблемы необходимо решать с итерационной детализацией, которая требует дополнительных ресурсов. Только правильно
проведенное проектирование действительно решает эти проблемы.
Допущенные на этапе технического проектирования ошибки переносятся впоследствии и на этап физического проектирования, где они могут быть обнаружены в кратчайшие сроки программистом-кодировщиком (при наличии определенной подготовки данного специалиста и наличии на то полномочий).
Учитывая, что определенные технологии проектирования используют итерационный подход при построении системы, и ошибки могут переходить (и преумножаться) на последующие итерации, указанный подход существенно повысит качество разработки ПО.
Необходимо особо подчеркнуть тот факт, что мы ни в коем случае не отрицаем и не пытаемся преуменьшить значение и роль такого важного этапа построения системы как проектирование.
Например, технология RAD предполагает применение в небольших по сложности системах (проектах), и позволяет за счет итеративного построения рабочих проектов, последовательно уменьшая число ошибок, довести их до предельного минимума. В связи с таким подходом особый акцент делается не на проектирование, а на скорость перехода от этапа к этапу.
Мы же предполагаем сильную работу на этапе проектирования (особенно это становится важным в больших по сложности проектах) с последующим усилением контроля качества результатов, полученных на последующих этапах физического проектирования.
Получается, что необходимо решить задачу оптимизации, устанавливающую зависимость между приемлемым числом итераций детализации (при проектировании) и необходимым уровнем качества «кодирования» элементов.
Несомненно одно — отсутствие сомнительного кода приносит разработчику не меньшую радость, чем для художника законченное полотно. Даже закон Россий-
N94(10) 2007
ской Федерации «Об авторском праве § и смежных правах» сравнивает программы
с литературными произведениями. <2
^
Глоссарий *
<и
Проект системы — проектно-конструк- ;§ торская и технологическая документация, ¿ц в которой представлено описание проект- оо ных решений по созданию и эксплуатации ^ информационных систем в конкретной программно-технической среде.
Проектирование — процесс преобразования входной информации об объекте, методах и опыте проектирования объектов аналогичного назначения в проект информационной системы.
Программист («кодировщик») — лицо, способное преобразовать формальные требования постановки задачи в объекты построения системы, которые на должном уровне адекватно дополнят требования проектировщиков.
Сомнительный код — определенная составляющая физической части системы, способная ввести в заблуждение (возможно, написанная с ошибками) программистов/проектировщиков.
Постпроектирование — процесс мини-проектирования на этапе кодирования, который включает в себя возможность внесения определенных(целесообразных) изменений основного проекта системы на этапе ее физического построения.
Список литературы
1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. 2-е изд. М.: Издательство «Бином», СПб.: Невский диалект, 1998.
2. Страуструп Б. Язык программирования С++. 3-е изд. М.: Издательство «Бином», СПб.: Невский диалект, 1999.
3. Брукс Ф. Мифический человекомесяц или как создаются программные системы. М.: Издательство «Символ-Плюс», 2006.
4. Кнут Д. Искусство программирования. Т. 1. Основные алгоритмы. 3-е изд. М.: Издательский дом «Вильямс», 2001.
139
No4(10) 2007
Артюхин Валерий Викторович — к.э. н., доцент, декан факультета Программирования Московской финансово-промышленной академии (МФПА).
Белый Владимир Михайлович — к.т.н., с.н.с., заведующий кафедрой Информационных технологий и управляющих систем Королёвского института управления, экономики и социологии.
Жижин Константин Сергеевич — д.м.н., доцент, заместитель директора по научно-методической работе Ростовского базового медицинского колледжа (ГОУ СПО РО РБМК).
Землянский Антон Адольфович — руководитель Отдела сопровождения WF Управления ^провождения компании «Диасофт».
Иванов Николай Николаевич — к. ф.-м.н., директор НПФ «Бизнес-Технологии».
Коваленко Игорь Николаевич — преподаватель Каменского педагогического колледжа Ростовской области.
Леденев Александр Вячеславович — программист Отдела разработок для мобильных платформ Xtra Information Management (XIM Inc.), представительство в России — ООО «Ин-фотех».
Литвинова Ольга Александровна — к.э. н., директор по корпоративным коммуникациям управляющей компании «Национальной компьютерной корпорации».
Речинский Александр Витальевич — к.т.н., директор Института государственного управления и информатизации (ИГУИ) Санкт-Петербургского государственного политехнического университета (СПбГПТУ), заведующий кафедрой Компьютерных интеллектуальных технологий в проектировании ИГУИ СПбГПТУ.
Семёнов Игорь Алексеевич — программист ЗАО «СУП Фабрик».
Хаханов Владимир Иванович — д. т. н., профессор, декан факультета Компьютерной инженерии Харьковского национального университета радиоэлектроники (ХНУРЭ).
140
