6.3. Проектирование, обеспечивающее удобство сопровождения

6.3. Проектирование, обеспечивающее удобство сопровождения

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

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

"Данный код живой, замороженный или мертвый?" — это вопрос, который обычно задают Unix-программисты и особенно программисты сообщества открытого исходного кода при оценке тех или иных инструментов. Вокруг "живого" кода сосредотачивается сообщество активных разработчиков. "Замороженный" код часто становится таковым ввиду того, что создает гораздо больше проблем, чем конструктивных решений для его разработчиков. "Мертвый" код так долго пребывает в "замороженном" состоянии, что было бы проще реализовать его эквивалент с самого начала. Для того чтобы код "жил", необходимо направить максимум усилий на то, чтобы сделать код удобным в сопровождении (и, следовательно, привлекательным для будущих кураторов).

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

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

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

Сообщество открытого исходного кода постигло и выработало этот обычай. Кроме того что хакерские руководства являются рекомендациями для будущих кураторов, в проектах с открытым исходным кодом они также предназначены для того, чтобы способствовать добавлению функций и исправлению ошибок со стороны программистов-любителей. Характерным примером является файл Design Notes, поставляемый с программой fetchmail. Исходные коды ядра Linux включают в себя буквально десятки подобных документов.

В главе 19 описаны соглашения, выработанные Unix-разработчиками для облегчения изучения дистрибутивов исходных кодов и создания исполняемого кода.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Удобно ли использовать удобство пользования?

Из книги Журнал "Компьютерра" №713 автора Журнал «Компьютерра»

Удобно ли использовать удобство пользования? Автор: Юрий РевичКонстантин Самойлов уверяет, что термин "юзабилити" лучше не переводить, а использовать, как есть. Возможно, он прав - английское usability в принципе можно перевести, как "удобство пользования", но суть данной


Особенности создания звукового сопровождения формата 5.1

Из книги Видеосамоучитель монтажа домашнего видео в Adobe Premiere Pro CS3 автора Днепров Александр Г

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


6.2. Проектирование, обеспечивающее прозрачность и воспринимаемость

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

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


6.2.2. Программирование, обеспечивающее прозрачность и воспринимаемость

Из книги Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ автора Мейерс Скотт

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


17.5. Программирование, обеспечивающее переносимость

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

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


Правило 19: Рассматривайте проектирование класса как проектирование типа

Из книги Наглядный самоучитель работы на нетбуке автора Сенкевич Г. Е.

Правило 19: Рассматривайте проектирование класса как проектирование типа В C++, как и в других объектно-ориентированных языках программирования, при определении нового класса определяется новый тип. Потому большую часть времени вы как разработчик C++ будете тратить на


6.2. Проектирование, обеспечивающее прозрачность и воспринимаемость

Из книги Программирование для Linux. Профессиональный подход автора Митчелл Марк

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


6.2.2. Программирование, обеспечивающее прозрачность и воспринимаемость

Из книги Как тестируют в Google автора Уиттакер Джеймс

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


6.3. Проектирование, обеспечивающее удобство сопровождения

Из книги автора

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


17.5. Программирование, обеспечивающее переносимость

Из книги автора

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


В чем удобство переводчика Bing?

Из книги автора

В чем удобство переводчика Bing? Поддержка онлайн-переводчика Bing встроена прямо в браузер Internet Explorer (версии 8 и 9). Этот переводчик — один из сервисов портала Bing, который уже знаком нам как одна из поисковых систем Интернета.Когда вы выделяете текст на веб-странице, рядом с


9.6. Вопросы сопровождения и переносимости

Из книги автора

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


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

Из книги автора

Тестирование в режиме сопровождения Google известен своими ранними и частыми выпусками, а еще — стремлением понять, что проект провальный, как можно быстрее. Поэтому мы можем срочно перебросить ресурсы на проект с наибольшими рисками. Что это значит для тестировщика? Фичи,


Пример режима сопровождения: Google Desktop Джейсон Арбон

Из книги автора

Пример режима сопровождения: Google Desktop Джейсон Арбон На середине очередного проекта мне предложили взяться за колоссальную задачу тестирования Google Desktop с десятками миллионов пользователей, клиентскими и серверными компонентами и интеграцией с поиском Google. Я стал