Основы написания хорошего кода

Введение

Разработка ПО — непростой процесс, который может включать множество компонентов. Вот какие составляющие разработки ПО определили ученые за последние 25 лет:

- определение проблемы;

- выработка требований;

- создание плана конструирования;

- разработка архитектуры ПО, или высокоуровневое проектирование;

- детальное проектирование;

- кодирование и отладка;

- блочное тестирование;

- интеграционное тестирование;

- интеграция;

- тестирование системы;

- корректирующее сопровождение.

Рассмотрим некоторые из этих этапов.

Предварительные условия

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

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

Определите тип ПО, над которым вы работаете.

- Встроенные системы, от которых зависит жизнь людей;

- Бизнес-системы;

- Системы целевого назначения;

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

Вы можете выбрать более последовательный подход (при котором вопросы решаются заблаговременно), если:

- требования довольно стабильны;

- проект приложения прост и относительно понятен;

- группа разработчиков знакома с прикладной областью;

- проект не связан с особым риском;

- важна долговременная предсказуемость проекта;

- затраты на изменение требований, проекта приложения и кода скорее всего окажутся высокими.

Более итеративный подход (при котором вопросы решаются по мере работы) можно предпочесть, если:

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

- проект приложения сложен, не совсем ясен или и то и другое;

- группа разработчиков незнакома с прикладной областью;

- проект сопряжен с высоким риском;

- долговременная предсказуемость проекта не играет особой роли;

- затраты на изменение требований, проекта приложения и кода скорее всего будут низкими.

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

Предварительные условия, связанные с определением проблемы

Первое предварительное условие, которое нужно выполнить перед конструированием, - ясное формулирование проблемы, которую система должна решать.

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

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

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

Рис.2 - Место определения проблемы в разработке ПО.

Не имея хорошего определения проблемы, можно потратить усилия на решение не той проблемы (см. Рис.2). Разумеется, нужную проблему вы при этом тоже не решите.

Чтобы лучше понять проблему и пути ее решения существуют метафоры.

Метафоры и алгоритмы

Терминология компьютерных наук - одна из самых красочных. В этой области существуют стерильные комнаты с тщательно контролируемой температурой, заполненные вирусами, троянскими конями, червями и др.?

Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем понятное явление с чем-то похожим, но более понятным, вы можете догадаться, как справиться с проблемой. Такое использование метафор называется моделированием.

В целом эффективность моделей объясняется их яркостью и концептуальной целостностью. Модели подсказывают ученым свойства, отношения и перспективные области исследований.

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

Подходы к созданию алгоритмов и требования к ним существенно изменялись в ходе эволюции компьютеров. Первоначально, в эпоху ЭВМ 1 - го и 2-го поколений, когда они были еще мало распространены, машинное время было дорого, а возможности ЭВМ очень скромны (с точки зрения сегодняшних достижений), основным требованием к алгоритму была его узко понимаемая эффективность:

· минимальные требования в отношении оперативной памяти компьютера.

· минимальное время исполнения (минимальное число операций).

Такой подход в программировании (создании алгоритмов), ориентированный на непосредственно выполняемые компьютером операции, можно назвать операциональным.

С появлением массовых ЭВМ 3-го поколения устаревшая технология программирования оказалась основным фактором, сдерживающим развитие и распространение компьютерных (информационных) технологий, что подтолкнуло ведущие в этой сфере деятельности фирмы, в первую очередь IBM, к разработке новых методологий программирования. Появившийся в начале 1970-х годов новый подход к разработке алгоритмов получил название структурного.

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

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

Само структурное программирование, наиболее отчетливо выраженное в языке Паскаль (PASCAL), возникло в ходе развития процедурно-ориентированного подхода, заложенного в исторически первом из языков программирования - Фортране (FORTRAN). Во всех языках этого направления разработчик алгоритма (он же, как правило, и программист) описывает, какими действиями следует реализовать процесс. В основе языков этой группы лежат понятия команд (операторов) и данных. Отдельные группы операторов могут объединяться во вспомогательные алгоритмы (процедуры, подпрограммы).

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

3. Предварительные условия, связанные с выработкой требований

Важность явного набора требований объясняется несколькими причинами:

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

- Наличие явных требований помогает избегать споров.

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

Требования подробно описывают, что должна делать программная система, а их

выработка - первый шаг к решению проблемы.

Среди специфических функциональных требований должны быть определены:

- все способы ввода и вывода данных в систему с указанием источника, точности, диапазона значений и частоты ввода;

- все форматы вывода для Web-страниц, отчетов;

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

- задачи, в выполнении которых нуждается пользователь;

- данные, используемые в каждой задаче, и данные, являющиеся результатом выполнения каждой задачи.

Среди специфических нефункциональных требований (требований к качеству) должны быть определены:

- ожидаемое пользователем время реакции для всех необходимых операций;

- другие временные параметры, такие как время обработки данных, скорость их передачи и пропускная способность системы;

- уровень защищенности системы;

- надежность системы, в том числе такие аспекты, как следствия сбоев в ее работе;

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

- минимальные требования программы к объему памяти и свободного дискового пространства;

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

Качество требований:

1. Требования должны быть написаны на языке, понятном пользователям.

2. Между требованиями не должно быть конфликтов.

3. Должно быть определено приемлемое равновесие между параметрами-антагонистами, такими как устойчивость к нарушению исходных предпосылок и корректность.

4. Не должны присутствовать в требованиях элементы проектирования.

5. Должен быть согласован уровень детальности требований.

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

7. Каждое требование должно быть релевантно для проблемы и ее решения.

8. Должно быть возможно протестировать каждое требование, чтобы можно было провести независимое тестирование, которое позволит сказать, выполнены ли все требования.

9. Должны быть определены все возможные изменения требований и вероятность каждого изменения.

Полнота требований:

1. Должны быть указаны недостающие требования, которые невозможно определить до начала разработки.

2. Требования должны быть полны в том смысле, что если приложение будет удовлетворять всем требованиям, то оно будет приемлемо.

3. Требования не должны вызывать у вас дискомфорта. Должны быть исключены требования, которые не поддаются реализации и были включены лишь для успокоения клиента или начальника.

Конструирование

Иногда конструирование называют «кодированием» или «программированием». Но конструирование вовсе не механический процесс, он часто связано с творчеством и анализом.

Вот некоторые конкретные задачи, связанные с конструированием:

- проверка выполнения условий, необходимых для успешного конструирования;

- определение способов последующего тестирования кода;

- проектирование и написание классов и методов;

- создание и присвоение имен переменным и именованным константам;

- выбор управляющих структур и организация блоков команд;

- блочное тестирование, интеграционное тестирование и отладка собственного кода;

- взаимный обзор кода и низкоуровневых программных структур членами группы;

- «шлифовка» кода путем его тщательного форматирования и комментирования;

- интеграция программных компонентов, созданных по отдельности;

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

степени использования ресурсов.

Почему конструирование ПО так важно?

- Конструирование - крупная часть процесса разработки ПО. В зависимости от размера проекта на конструирование обычно уходит 30-80 % общего времени работы.

- Конструирование занимает одно из центральных мест в процессе разработки ПО (см.Рис.2).

 

Рис.2 - Место конструирования среди других процессов разработки ПО.

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