- •Оглавление
- •Об авторе
- •Благодарности
- •Предисловие
- •Глава 1. Держим оборону
- •На пути к хорошему коду
- •Готовьтесь к худшему
- •Что такое защитное программирование?
- •Этот страшный, ужасный мир
- •Технологии защитного программирования
- •Выберите хороший стиль кодирования и пользуйтесь крепкой архитектурой
- •Пишите код без спешки
- •Не верьте никому
- •Стремитесь к ясности, а не к краткости
- •Не позволяйте никому лезть туда, где ему нечего делать
- •Включайте вывод всех предупреждений при компиляции
- •Пользуйтесь средствами статического анализа
- •Применяйте безопасные структуры данных
- •Проверяйте все возвращаемые значения
- •Аккуратно обращайтесь с памятью (и другими ценными ресурсами)
- •Инициализируйте все переменные там, где вы их объявили
- •Объявляйте переменные как можно позже
- •Пользуйтесь стандартными средствами языка
- •Пользуйтесь хорошими средствами регистрации диагностических сообщений
- •Выполняйте приведение типов с осторожностью
- •Подробности
- •Ограничения
- •Какие ограничения налагать
- •Снятие ограничений
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 2. Тонкий расчет
- •Да в чем проблема?
- •Знайте своих клиентов
- •Что такое хорошее представление?
- •Размещение скобок
- •Скобки в стиле K&R
- •Расширенный стиль скобок
- •Стиль Уайтсмита (с отступами)
- •Другие стили скобок
- •Единственно верный стиль
- •Внутрифирменные стили (и когда их придерживаться)
- •Установка стандарта
- •Религиозные войны?
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 3. Что в имени тебе моем?
- •Зачем нужны хорошие имена?
- •Каким объектам мы даем имена?
- •Игра в названия
- •Описательность
- •Техническая корректность
- •Идиоматичность
- •Тактичность
- •Технические подробности
- •Имена переменных
- •Имена функций
- •Имена типов
- •Пространства имен
- •Имена макросов
- •Имена файлов
- •Роза пахнет розой
- •Соблюдайте единообразие
- •Связывайте имя с содержимым
- •Извлекайте выгоду из выбора имени
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 4. Литературоведение
- •Самодокументируемый код
- •Техника написания самодокументируемого кода
- •Пишите простой код с хорошим форматированием
- •Выбирайте осмысленные имена
- •Разбивайте код на самостоятельные функции
- •Выбирайте содержательные имена типов
- •Применяйте именованные константы
- •Выделяйте важные фрагменты кода
- •Объединяйте взаимосвязанные данные
- •Снабжайте файлы заголовками
- •Правильно обрабатывайте ошибки
- •Пишите осмысленные комментарии
- •Практические методологии самодокументирования
- •Грамотное программирование
- •Инструментарий документирования
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 5. Заметки на полях
- •Что есть комментарий в коде?
- •Как выглядят комментарии?
- •Сколько комментариев требуется?
- •Что помещать в комментарии?
- •Не нужно описывать код
- •Не подменяйте код
- •Как сделать комментарии полезными
- •Не отвлекаться
- •На практике
- •Замечание об эстетичности
- •Единообразие
- •Четкие блочные комментарии
- •Отступы в комментариях
- •Комментарии в конце строки
- •Помощь в чтении кода
- •Стиль должен обеспечивать легкость сопровождения
- •Границы
- •Флажки
- •Комментарии в заголовке файла
- •Работа с комментариями
- •Помощь при написании программ
- •Заметки об исправлении ошибок
- •Устаревание комментариев
- •Сопровождение и бессодержательные комментарии
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 6. Людям свойственно ошибаться
- •Откуда что берется
- •Механизмы сообщения об ошибках
- •Без обработки ошибок
- •Возвращаемые значения
- •Переменные, содержащие состояние ошибки
- •Исключения
- •Сигналы
- •Обнаружение ошибок
- •Обработка ошибок
- •Когда обрабатывать ошибки
- •Варианты реагирования
- •Последствия для кода
- •Подымаем скандал
- •Управление ошибками
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 7. Инструментарий программиста
- •Что такое инструмент программирования?
- •А зачем они нужны – инструменты?
- •Электроинструменты
- •Выясните, каковы его возможности
- •Научитесь им управлять
- •Выясните, для каких задач он пригоден
- •Убедитесь, что он работает
- •Имейте четкие данные о том, как получить дополнительные сведения
- •Узнайте, как получить новые версии
- •Какой инструмент необходим?
- •Средства редактирования исходного кода
- •Средства построения кода
- •Инструменты для отладки и тестирования
- •Средства поддержки языка
- •Инструменты различного назначения
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 8. Время испытаний
- •Проверка на подлинность
- •Кто, что, когда, зачем?
- •Зачем тестировать
- •Кому тестировать
- •В чем состоит тестирование
- •Когда тестировать
- •Типы тестирования
- •Выбор контрольных примеров для блочного тестирования
- •Архитектура и тестирование
- •Руками не трогать!
- •Анатомия провала
- •Справлюсь ли я сам?
- •Система контроля ошибок
- •Обсуждение ошибок
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 9. Поиск ошибок
- •Реальные факты
- •Природа этого зверя
- •Взгляд с высоты птичьего полета
- •Взгляд с поверхности земли
- •Взгляд из глубины
- •Борьба с вредителями
- •Обходная дорога
- •Правильный путь
- •Охота за ошибками
- •Ошибки этапа компиляции
- •Ошибки этапа исполнения
- •Как исправлять ошибки
- •Профилактика
- •Отладчик
- •Средство проверки доступа к памяти
- •Трассировщик системных вызовов
- •Дамп памяти
- •Журналирование
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 10. Код, который построил Джек
- •Языковые барьеры
- •Интерпретируемые языки
- •Компилируемые языки
- •Делаем слона из мухи
- •Выполнение сборки
- •Что должна уметь хорошая система сборки?
- •Простота
- •Единообразие
- •Повторяемость и надежность
- •Атомарность
- •Борьба с ошибками
- •Механика сборки
- •Выбор целей
- •Уборка
- •Зависимости
- •Автоматическая сборка
- •Конфигурация сборки
- •Рекурсивное применение make
- •Мастер на все руки
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 11. Жажда скорости
- •Что такое оптимизация?
- •От чего страдает оптимальность кода?
- •Доводы против оптимизации
- •Альтернативы
- •Нужна ли оптимизация
- •Технические подробности
- •Убедитесь, что нужна оптимизация
- •Определите самую медленную часть кода
- •Тестирование кода
- •Оптимизация кода
- •После оптимизации
- •Методы оптимизации
- •Конструктивные изменения
- •Модификация кода
- •Как писать эффективный код
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 12. Комплекс незащищенности
- •Риски
- •Наши оппоненты
- •Оправдания, оправдания
- •Ощущение незащищенности
- •Опасный проект и архитектура
- •Переполнение буфера
- •Встроенные строки запросов
- •Условия гонки
- •Целочисленное переполнение
- •Дела защитные
- •Технология установки системы
- •Технология конструирования программного обеспечения
- •Технологии реализации кода
- •Технологии процедуры
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 13. Важность проектирования
- •Программирование как конструкторская работа
- •Что нужно проектировать?
- •Хороший проект программного продукта
- •Простота
- •Элегантность
- •Модульность
- •Хорошие интерфейсы
- •Расширяемость
- •Избегайте дублирования
- •Переносимость
- •Идиоматичность
- •Документированность
- •Как проектировать код
- •Методы и процедуры проектирования
- •Инструменты проектирования
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 14. Программная архитектура
- •Что такое программная архитектура?
- •План программы
- •Точки зрения
- •Где и когда этим заниматься?
- •Для чего она применяется?
- •Компоненты и соединения
- •Какими качествами должна обладать архитектура?
- •Архитектурные стили
- •Без архитектуры
- •Многоуровневая архитектура
- •Архитектура с каналами и фильтрами
- •Архитектура клиент/сервер
- •Компонентная архитектура
- •Каркасы
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 15. Программное обеспечение – эволюция или революция?
- •Гниение программного обеспечения
- •Тревожные симптомы
- •Как развивается код?
- •Вера в невозможное
- •Как с этим бороться?
- •Как писать новый код
- •Сопровождение существующего кода
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 16. Кодеры
- •Мартышкин труд
- •Нетерпеливый
- •Кодер (Code Monkey)
- •Гуру
- •Псевдогуру
- •Высокомерный гений
- •Ковбой
- •Плановик
- •Ветеран
- •Фанатик
- •Монокультурный программист
- •Лодырь
- •Руководитель поневоле
- •Идеальный программист
- •И что из этого следует?
- •Для глупцов
- •Резюме
- •План действий
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 17. Вместе мы – сила
- •Команды – общий взгляд
- •Организация команды
- •Методы управления
- •Разделение ответственности
- •Организация и структура кода
- •Инструменты для групповой работы
- •Болезни, которым подвержены команды
- •Вавилонская башня
- •Диктатура
- •Демократия
- •Большой Каньон
- •Зыбучие пески
- •Лемминги
- •Личное мастерство и качества, необходимые для работы в команде
- •Общение
- •Скромность
- •Разрешение конфликтов
- •Обучение и приспособляемость
- •Знание пределов своих возможностей
- •Принципы групповой работы
- •Коллективное владение кодом
- •Нормы кодирования
- •Определите, что считать успехом
- •Установите ответственность
- •Избегайте истощения
- •Жизненный цикл команды
- •Создание команды
- •Рост команды
- •Групповая работа
- •Роспуск команды
- •Резюме
- •План действий
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 18. Защита исходного кода
- •Управление версиями исходного кода
- •Контроль версий
- •Контроль доступа
- •Работа с хранилищем
- •Пусть растут деревья
- •Краткая история систем контроля за исходным кодом
- •Управление конфигурацией
- •Резервное копирование
- •Выпуск исходного кода
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 19. Спецификации
- •Что же это такое, конкретно?
- •Типы спецификаций
- •Спецификация требований
- •Функциональная спецификация
- •Спецификация системной архитектуры
- •Спецификация интерфейса пользователя
- •Проектная спецификация
- •Спецификация тестирования
- •Что должны содержать спецификации?
- •Процесс составления спецификаций
- •Почему мы не пишем спецификации?
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Когда проводить рецензирование?
- •Нужно ли рецензировать
- •Какой код рецензировать
- •Проведение рецензирования кода
- •Рецензирование на собраниях
- •Интеграционное рецензирование
- •Пересмотрите свое отношение
- •Позиция автора
- •Позиция рецензента
- •Идеальный код
- •За пределами рецензирования кода
- •Резюме
- •Контрольный список
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 21. Какой длины веревочка?
- •Выстрел в темноте
- •Почему трудно делать оценки?
- •Под давлением
- •Практические способы оценки
- •Игры с планами
- •Не отставай!
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 22. Рецепт программы
- •Стили программирования
- •Структурное программирование
- •Функциональное программирование
- •Логическое программирование
- •Рецепты: как и что
- •Процессы разработки
- •Каскадная модель
- •SSADM и PRINCE
- •Создание прототипов
- •Итеративная и инкрементная разработка
- •Спиральная модель
- •Другие процессы разработки
- •Спасибо, хватит!
- •Выбор процесса
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 23. За гранью возможного
- •Программирование приложений
- •Коробочные продукты
- •Заказные приложения
- •Программирование игр
- •Системное программирование
- •Встроенное программное обеспечение
- •Программирование масштаба предприятия
- •Численное программирование
- •И что дальше?
- •Резюме
- •Контрольные вопросы
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 24. Что дальше?
- •Но что же дальше?
- •Ответы и обсуждение
- •Глава 1. Держим оборону
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 2. Тонкий расчет
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 3. Что в имени тебе моем?
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 4. Литературоведение
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 5. Заметки на полях
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 6. Людям свойственно ошибаться
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 7. Инструментарий программиста
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 8. Время испытаний
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 9. Поиск ошибок
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 10. Код, который построил Джек
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 11. Жажда скорости
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 12. Комплекс незащищенности
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 13. Важность проектирования
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 14. Программная архитектура
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 15. Программное обеспечение – эволюция или революция?
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 16. Кодеры
- •Вопросы для размышления
- •Глава 17. Вместе мы – сила
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 18. Защита исходного кода
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 19. Спецификации
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 20. Рецензия на отстрел
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 21. Какой длины веревочка?
- •Вопросы для размышления
- •Вопросы личного характера
- •Глава 22. Рецепт программы
- •Вопросы для размышления
- •Глава 23. За гранью возможного
- •Вопросы для размышления
- •Вопросы личного характера
- •Библиография
- •Алфавитный указатель
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
|
E |
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
||
|
F |
|
|
|
|
|
|
t |
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
|
P |
|
|
|
|
|
NOW! |
o |
||
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|||
|
|
|
|
to |
|
|
|
|
|
w Click |
|
|
|
536m |
|||||
|
|
|
|
||||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
. |
|
|
|
|
|
.c |
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
df |
|
|
n |
e |
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
Глава 22. Рецепт программыClick |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
лее обсудим процессы разработки. Важно овладеть разными имеющи% мися методами разработки, чтобы расширить свой кругозор и пра% вильно выбрать процесс, если вам представится возможность выбора.
Наши программные проекты определяются теми стилями и процессами, которые мы применяем. Они неизбежно отражаются на форме и качестве кода.
Следующие разделы не являются учебником по этим темам, а пред% ставляют собой достаточно беглый обзор, позволяющий их сравнить. Если вас заинтересуют подробности, найти соответствующий учебник будет нетрудно.
Процессы разработки
Существует много процессов разработки, поскольку есть люди, кото% рые любят их изобретать. Многие из них лишь незначительно развива% ют одну%две базовые модели. Эти базовые варианты мы здесь рассмот% рим. Как вы убедитесь, некоторые из них тесно связаны между собой.
Выбор вами процесса разработки определяет планирование проектов, переход работы из одной фазы в другую и взаимодействие между чле% нами команды, осуществляющей проект. Различие между процессами проявляется по разным направлениям:
Толстый/тонкий
Толстый процесс разработки тяжел и бюрократичен. Он создает массу бумажных документов, регламентирует поведение разработ% чиков и предполагает определенную структуру команды. Его ха% рактеризует организационная модель ISO 9000, в которой каждая производственная процедура раболепно расписана во всех деталях, несмотря на изъяны или неуместность процесса.
На другом полюсе располагаются тонкие процессы разработки, из% бегающие ненужной бюрократичности и благоприятствующие бо% лее скромным и ориентированным на людей принципам. Такую практику поддерживают процессы ускоренного программирования, описанные на стр. 547.
Последовательность событий
В некоторых процессах разработки разумно учитывается, что ре% альность непредсказуема, и предпринимаются попытки учесть это в планах путем выполнения нескольких итераций в цикле процес% са. Это дает возможность разработчикам учесть в новой итерации результаты, полученные на предыдущей. Они могут приспособить% ся к естественным изменениям, происходящим по мере разработки продукта (новые требования клиентов, непредвиденные проблемы и т. п.).
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
|
|
P |
|
|
|
|
|
NOW! |
o |
|
||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
Процессыm |
разработки |
|||||
|
|
|
|
|||||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
537Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Другие процессы более регламентированы и линейны и полагаются на формальный переход разработки от одной стадии к другой. Они предусматривают значительные затраты на предварительное пла% нирование и попытки в деталях предвидеть будущее. Такие пред% сказания ограничивают возможность будущих коррекций направ% ления разработки.
Направление проектирования
При нисходящем проектировании система создается на основе на% чального общего представления. Каждый пакет верхнего уровня уточняется и подвергается разбиению на составляющие. Этот про% цесс продолжается до тех пор, пока не будут получены специфика% ции продукта, позволяющие начать работу. В нисходящем проек% тировании велика роль планирования и хорошего представления о результирующей системе и предполагается, что в процессе разра% ботки требования будут меняться мало.
В противоположной процедуре – восходящем проектировании – подробно описываются отдельные части системы, а затем отыски% вается лучший способ соединить их вместе. При этом легче вклю% чить в новый проект уже существующие компоненты. В современ% ной практике эти два подхода часто объединяются – для начально% го планирования создается некоторое представление о системе в це% лом, а затем происходит выявление и кодирование компонент и объектов низкого уровня.
Ни один из процессов разработки не лучше остальных. Существуют крайние точки зрения относительно правильного выбора позиции по каждой из этих осей. Правильная методология для любого проекта определяется рядом факторов, включая культуру разработки, сущест% вующую в организации, тип разрабатываемого продукта и опыт ко% манды разработчиков.
Теперь пристегните ремни безопасности, и мы начнем наше голово% кружительное путешествие по процессам разработки программного обеспечения.
Ad Hoc
Это исходная точка, но на самом деле это анти%процесс. Здесь нет ни% какого процесса либо он не документирован. Каждый работает по соб% ственному плану, никто не знает, чем занимаются остальные, и можно только надеяться, что в итоге получится что%то полезное. Может быть, и ваша команда работает так, как показано на рис. 22.1?
Когда организация не знает, как она делает свои программы, это не% простительно, даже если она малочисленна и считает, что ей не нужен процесс. При таком положении нет гарантий, что программы будут выпускаться вовремя, поскольку нет подотчетности. Кто ответит за то, чтобы были реализованы все функции?
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
|
E |
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
||
|
F |
|
|
|
|
|
|
t |
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
|
P |
|
|
|
|
|
NOW! |
o |
||
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|||
|
|
|
|
to |
|
|
|
|
|
w Click |
|
|
|
538m |
|||||
|
|
|
|
||||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
. |
|
|
|
|
|
.c |
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
df |
|
|
n |
e |
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
Глава 22. Рецепт программыClick |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
|
|
|
|
Кодировать, |
|
|
|
|
|
|
|
|
|
|
как сумасшедшие |
|
|
|
|
|
|
|
|
|
|
ОКОНЧАТЕЛЬНЫЙ |
|
|
|
|
||
|
|
|
|
СРОК |
|
|
|
|
|
|
Нет |
Все |
|
|
Нет |
Код |
Да |
|
Он |
|
|
важные части |
|
|
делает то, что |
|
||||||
|
|
завершен? |
|
|
|
|||||
|
завершены? |
|
|
Нет |
должен? |
|
Да |
|||
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
||
|
Да |
|
|
|
|
|
|
|
|
|
|
|
|
|
Есть |
Да |
|
|
|
Проходит |
|
|
|
|
|
что7то полез7 |
|
|
|
|
все тесты |
|
|
|
|
|
ное? |
|
|
Нет |
|
модулей? |
|
|
Можешь |
Да |
|
Тяп7ляп7 |
Нет |
|
|
|
|
Да |
|
состряпать специ7 |
спецификация |
|
|
|
|
|
|||
|
фикацию? |
|
|
|
|
Какие тесты |
|
|
||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
модулей? |
|
|
|
Нет |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
QA |
|
|
|
|
|
|
|
|
|
заметило? |
|
|
|
|
|
|
|
|
|
|
Нет |
|
|
Пройдет |
|
|
|
Вы |
|
|
|
Да |
|
Учитесь лучше |
||||
|
|
|
ли тестирование |
|||||||
|
|
|
|
писать тесты |
||||||
обречены |
|
|
|
|
Нет |
QA? |
Да |
|
||
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
|
|
Руководство |
|
|
Возможно |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
|
заметит? |
|
Назовем все ошибки |
|
Какое |
|
|
|||
|
Да |
|
|
|
|
|
||||
|
|
|
|
тестирование |
|
|
||||
|
|
Нет |
|
«функциями» |
|
|
|
|
||
|
|
|
|
|
QA? |
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Поздравляем! |
|
|
|
|
|
|
|
|
|
|
|
Как вам |
|
Не было |
|
|
Вам снесут |
|
|
|
это удалось? |
||
ли это вообще глу7 |
|
|
|
|
|
|
||||
|
пой идеей? |
Это была |
голову, если вы |
|
|
|
|
|||
|
|
не успеете |
|
|
|
|
|
|||
|
|
пустая трата |
|
|
|
|
|
|||
Нет, все |
Да |
к сроку? |
|
|
|
|
|
|||
времени |
|
|
|
|
|
|||||
должно |
|
|
|
Нет |
|
|
|
|
|
|
|
было |
|
|
|
|
|
|
|
Клиентам |
|
работать |
ПРОЕКТ |
|
|
|
|
|
Нет |
|
||
|
|
|
|
|
все еще нужен этот |
|||||
|
|
|
|
|
|
|
|
|||
|
ЗАКОНСЕРВИРОВАН |
|
|
|
|
|||||
|
|
|
|
|
|
продукт? |
||||
Можно |
|
|
Скажите |
|
|
|
|
|
Да |
|
ли найти, кто |
|
|
пользователям, |
|
|
Он |
|
|
||
виноват? |
|
|
что это |
|
|
достаточно |
|
|
||
Нет |
Да |
|
|
бета7версия |
|
|
хорош? |
|
|
|
|
|
|
|
|
|
|
Да |
Нет |
|
Уложились |
|
|
Есть ли |
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
в бюджет? |
||
Вам точно |
|
в портфеле |
|
|
|
|
|
|||
|
|
|
|
|
|
|
||||
конец |
|
еще заказы? |
|
|
|
|
Нет |
Да |
||
|
|
Нет |
|
Да |
|
|
|
|
|
|
|
У вас |
|
|
Придумайте |
Скорее |
Что |
|
Обманщик |
||
|
есть еще |
|
|
|
(или администра7 |
|||||
|
|
|
новый срок |
всего, нет |
дальше? |
|||||
|
задания? |
|
|
тивный талант) |
||||||
Да |
|
|
|
|
|
|
|
|
||
Нет |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Выход |
Вы уволены |
|
Берите |
Вернитесь |
Отгружайте |
Пишите собственную |
||||
следующий проект |
в начало |
|
продукт |
|
методологию |
|||||
|
|
|
|
|
||||||
Рис. 22.1. Путь к выпуску продукта |
|
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
|
|
P |
|
|
|
|
|
NOW! |
o |
|
||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
w Click |
|
|
|
Процессыm |
разработки |
|||||
|
|
|
|
|||||||
w |
|
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
|
. |
|
|
|
|
|
.c |
|
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
539Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Таким хаотическим способом создаются многие программы с откры% тым исходным кодом.1 Если есть бесконечное число обезьян и беско% нечное число компьютеров, то е]сть шанс, что получится программа, но ждать придется бесконечно долго. Даже эскиз, сделанный на салфет% ке, – это шаг в направлении более формального и предсказуемого про% цесса разработки.
Без процесса разработки команда находится в состоянии анархии. Программы появляются благодаря удаче, а не в результате целенаправленных действий.
Это случай анархии в разработке. Отдельные программисты могут ста% рательно трудиться, и их героические усилия могут привести к появ% лению чего%то стоящего. Однако серьезно рассчитывать на такой ре% зультат не стоит. Вероятнее всего, команда окажется очень неэффек% тивной и едва ли выпустит что%либо стоящее.
Каскадная модель
Каскадная модель представляет классический цикл разработки про% граммных продуктов. Ее много критикуют за простоту (и даже за ста% ромодность). Однако на ней в какой%то мере базируются практически все процессы разработки. У нее много недостатков, но, несмотря на них, это полезная отправная точка в изучении процессов. Она сделана по подобию более традиционного жизненного цикла в инженерном де% ле и была описана Ройсом в 1970 году (Royce 70). Это самый предска% зуемый среди всех процессов разработки.
Идея проста: процесс разработки разбивается на несколько сменяющих друг друга стадий. Это напоминает водопад, поскольку поток устойчи% во и неотвратимо движется от одного каскада к другому. Как вода в ре% ке всегда течет в одну сторону, так и разработка последовательно про% ходит все стадии в направлении выпуска готового продукта.
Традиционная каскадная модель показана на рис. 22.2.2 Вы видите пять обычный стадий, описанных во врезке «Стадии разработки». Ко% гда одна стадия успешно закончена, с помощью некой промежуточ# ной процедуры (обычно это обзорное совещание) осуществляется пере% ход к следующей стадии. На выходе большинства стадий появляется
1Там это может не быть столь существенно, поскольку нет заказчика, кото% рый платит деньги, и формального набора требований – множество про% грамм с открытым текстом разрабатывается, потому что этого хочется про% граммисту. Однако хотя бы частичное введение методологии в проекты open source наверняка привело бы к улучшению программ.
2Это обычное упрощение первоначальной статьи Ройса. У Ройса допускалось движение в обратном направлении, но не очень поощрялось. Рьяные адми% нистраторы вообразили, что разработка программного обеспечения должна быть строго линейным процессом, и вскоре убрали эти пути вверх по тече%
нию; водопад был опорочен.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
|
E |
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
||
|
F |
|
|
|
|
|
|
t |
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
|
P |
|
|
|
|
|
NOW! |
o |
||
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|||
|
|
|
|
to |
|
|
|
|
|
w Click |
|
|
|
540m |
|||||
|
|
|
|
||||||
w |
|
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
|
o |
|
. |
|
|
|
|
|
.c |
||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
df |
|
|
n |
e |
||
|
|
|
|
-xcha |
|
|
|
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
|
C |
|
E |
|
|
|||
|
|
X |
|
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
|
||
|
F |
|
|
|
|
|
|
t |
|
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
|
r |
||
P |
|
|
|
|
|
NOW! |
o |
|||
|
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|
|||
|
|
|
|
to |
|
|
|
|
|
|
Глава 22. Рецепт программыClick |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Стадии разработки
Каскадная модель описывает пять стадий процесса разработки программного продукта. Во многих других процессах выделяют% ся те же фазы, но располагаются в них в другом порядке или ме% няют свое относительное значение.
Анализ требований заказчика
Сначала нужно определить требования к программному проек% ту. В них входят цели проекта, услуги, которые должен предо% ставлять продукт, и накладываемые на него ограничения. Это% му шагу часто предшествует технико%экономическое обоснова% ние, либо оно проводится одновременно. Обоснование должно дать ответы на вопросы: Сможет ли продукт работать? Нужно ли разрабатывать этот продукт? Какие есть альтернативы?
Проектирование и спецификация
Выявленные на первом этапе требования превращаются в тре% бования к программному и аппаратному обеспечению. Затем требования к программному обеспечению преобразуются к та% кому виду, чтобы можно было легко реализовать их в компью% терной программе – вероятно, с помощью разбиения на от% дельно разрабатываемые компоненты.
Реализация
На этом этапе создаются программы. Каждая программа или компонента является модулем и подвергается тестированию. Тестирование модулей должно обеспечить их соответствие спецификациям, определенным в предшествующей фазе.
Интеграция и тестирование
Все модули объединяются в единую систему, которая подвер% гается тестированию. Проверяются правильность интеграции кода, корректность работы системы в целом и ее соответствие системным требованиям. Если система успешно прошла тес% тирование, разработка считается завершенной.
Сопровождение
Наконец, продукт поставляется заказчику. Не думайте, что ес% ли продукт отгружен заказчику, работа над ним закончена; это наивно. Самую длинную фазу жизненного цикла программно% го продукта составляет его сопровождение (см. «Сопровожде% ние существующего кода» на стр. 374). Приходится исправ% лять ошибки, реализовывать пропущенные и изменившиеся требования, а также выполнять другую работу по сопровож% дению продукта.