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

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

Отчет по введению в специальность

 

 

Выполнил: студент гр. 1- 41 …

Дубровина Е.С. Ф.И.О.

Проверил: д.т.н., профессор_____

Косяков С.В. Ф.И.О.

 

Иваново

2011.

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

Введение

Разработка ПО — непростой процесс, который может включать множество компонентов. Вот какие составляющие разработки ПО определили ученые за последние 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 - Место конструирования среди других процессов разработки ПО.

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

Конвенции программирования

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

Работа в группе

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

Б) Определение, будут ли программисты программировать парами, индивидуально или эти подходы будут скомбинированы.

Гарантия качества

Программисты должны будут разработать:

- тесты для своего кода до написания самого кода;

- блочные тесты для своего кода;

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

- выполнить интеграционное тестирование своего кода до его включения в исходный код проекта;

- выполнять взаимные обзоры или инспекцию кода.

Разработка архитектуры

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

Основные классы

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

Организация данных

Архитектура должна описывать основные виды формата файлов и таблиц. Она должна описывать рассмотренные альтернативы и обосновывать итоговые варианты.

Бизнес-правила

Архитектура, зависимая от специфических бизнес-правил, должна определять их

и описывать их влияние на проект системы.

Пользовательский интерфейс

Пользовательский интерфейс (GUI) часто проектируется на этапе выработки требований. Если это не так, его следует определить на этапе разработки архитектуры. Архитектура должна описывать главные элементы формата Web-страниц, GUI, интерфейс командной строки и т. д.

Управление ресурсами

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

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

Безопасность

Архитектура должна определять подход к безопасности на уровне проекта приложения и на уровне кода. Если модель угроз до сих пор не разработана, это следует сделать при проектировании архитектуры.

Производительность

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

Масштабируемость

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

Ввод-вывод

Ввод-вывод — еще одна область, на которую стоит обратить внимание при проектировании архитектуры. Архитектура должна определять схему чтения данных: упреждающее чтение, чтение с задержкой или по требованию. Кроме того, она должна описывать уровень, на котором будут определяться ошибки ввода-вывода: на уровне полей, записей, потоков данных или файлов.

Обработка ошибок

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

Отказоустойчивость

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

Избыточная функциональность

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

Купить или создавать самим?

Самый радикальный подход к созданию ПО - не создавать его вообще, а купить или загрузить из Интернета бесплатное ПО с открытым исходным кодом. Вы можете приобрести элементы управления GUI, менеджеры БД, процессоры изображений, компоненты для работы с графикой и диаграммами, компоненты для коммуникации по Интернету,

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

Проектирование ПО

Под «проектированием ПО» понимают разработку или изобретение схемы преобразования спецификации приложения в готовое приложение. Проектирование — это тот процесс, который связывает выработку требований с кодированием и отладкой.

Сложность

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

Подход к управлению сложностью:

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

- сдерживайте необязательный рост несущественной сложности.

Простота сопровождения

Проектируя приложение, не забывайте о программистах, которые будут его сопровождать (проектируйте систему так чтобы ее работа была очевидной). Слабое сопряжение (loose coupling) предполагает сведение к минимуму числа соединений между разными частями программы. Расширяемостью системы называют свойство, позволяющее улучшать систему, не нарушая ее основной структуры. Изменение одного фрагмента системы не должно влиять на ее другие фрагменты.

Стратификация

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

Уровни проектирования

Проектирование программной системы требует нескольких уровней детальности.

Рис.3 - Уровни проектирования программы. Систему A) следует разделить

на подсистемы B), подсистемы - на классы C), а классы - на методы и данные D);

методы также необходимо спроектировать E).

 

Список использованной литературы

1. Гудлиф П. Ремесло программиста. Практика написания хорошего кода. / Пер. с англ. - СПб.: Символ-Плюс, 2009. - 704 с., ил.

2. Макконнелл С. Совершенный код. Мастер-класс. / Пер. с англ. - М.: Издательско-торговый дом «Русская Редакция»; СПб.: Питер, 2005. - 896 стр.: ил.

3. Учебное пособие «Принципы разработки алгоритмов и программ для решения прикладных задач» http://revolution.allbest.ru/programming/00055669_0.html

4. Gilb T. Principles of Software Engineering Management. - Addison Wesley, Reading MA, 1988. - 464 p.

 

Содержание

Введение. 2

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

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

Разработка архитектуры.. 10

Проектирование ПО.. 13

Список использованной литературы.. 15

Содержание. 15

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

Отчет по введению в специальность

 

 

Выполнил: студент гр. 1- 41 …

Дубровина Е.С. Ф.И.О.

Проверил: д.т.н., профессор_____

Косяков С.В. Ф.И.О.

 

Иваново

2011.