- •Оглавление
- •Об авторе
- •Благодарности
- •Предисловие
- •Глава 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 |
|
|
|
456m |
|||||
|
|
|
|
||||||
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 |
|
|
|
|
|
|
Глава 18. Защита исходного кодаClick |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
паниях пользуются устаревшими системами; затраты и сложности пе% реноса больших объемов кода из одной системы в другую препятству% ют переходу на новую систему.
Родоначальницей всех систем управления версиями является SCCS (Source Code Control System), разработанная в Bell Labs в 1972 году. Ее заменила RCS (Revision Control System). Самая распространенная систе% ма в мире программного обеспечения с открытым кодом – CVS (Concur# rent Versions System), хотя она начала устаревать. CVS, основанная на базе RCS, дает возможность нескольким разработчикам работать над одним файлом одновременно. RCS реализует модель блокировки фай% лов (описанную в разделе «Жесткая блокировка» на стр. 450), тогда как CVS обеспечивает параллельную работу. Преемником CVS является система Subversion, в которой устранено большинство недостатков CVS.
Системы контроля за исходным кодом обладают тонкими функцио% нальными различиями, но при этом большинство из них предоставля% ет оба интерфейса – командной строки и графический. Все они могут встраиваться в популярные IDE. Если вы не знаете, какой инструмент выбрать для своего проекта, попробуйте поработать с Subversion и од% ним из существующих для нее графических интерфейсов.
Управление конфигурацией
Управление конфигурацией программного обеспечения – тема, близ% кая к контролю за исходным кодом, но не следует одно путать с дру% гим. Это отдельная большая тема.
Как мы видели, перед системой контроля за исходным кодом стоят следующие задачи:
•Обеспечить централизованное хранение кода
•Сохранить историю изменений, которым подверглись файлы
•Дать возможность разработчикам совместно трудиться, не создавая друг другу помех
•Дать возможность разработчикам решать задачи параллельно с по% следующим слиянием результатов
Основываясь на этом фундаменте, управление конфигурацией регули% рует разработку программного продукта на протяжении всего времени существования проекта. Оно включает в себя контроль за исходным кодом плюс процедуру разработки. Формально управление конфигу% рацией ПО определяется как «Порядок установления конфигурации системы в дискретные моменты времени с целью систематического контроля за изменениями в этой конфигурации и сохранения целост% ности и возможности слежения за этой конфигурацией на протяжении всего времени существования системы» (Bersoff et al. 80). Оно контро% лирует артефакты проекта (то, что вы помещаете в систему контроля за исходным кодом) и его процессы разработки.
|
|
|
|
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 |
|
|
|
|
|
|
457Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Некоторые системы контроля за исходным кодом предоставляют сред% ства управления конфигурацией и могут интегрироваться с инстру% ментами рабочего процесса проекта, например управлять отчетами об ошибках и запросами на модификацию, следить за ходом их развития и связывать с физическими изменениями в базовом коде.
Управление конфигурацией включает в себя:
•Определение всех отдельных программных компонент системы и ар% тефактов, необходимых для их построения (это особенно полезно, когда один базовый код может быть сконфигурирован для генера%
Терминология и определения
Контроль за исходным кодом – наше главное оружие в борьбе за сохранность кода. Это важный инструмент, без которого профес% сиональный разработчик не может обойтись. Мы уже столкну% лись с разными названиями этой системы. Они используются вза% имозаменяемым образом, но каждое название вскрывает опреде% ленный аспект работы:
Контроль за исходным кодом (source control)
Это механизм управления файлами с кодом, который мы пи% шем. Он поддерживает файлы и структуру их каталогов, а так% же регулирует порядок одновременного доступа к коду и его модификации.
Управление версиями (version control)
Называемая также контролем исправлений (revision control) или модификаций (change control), это система контроля за ис% ходным кодом, регистрирующая изменения, сделанные в фай% ле. Она позволяет изучать, извлекать и сравнивать любые вер% сии файла на протяжении всего времени работы с ним.
Обычно управление версиями наиболее эффективно работает с файлами в текстовом формате – в них легко отыскивать раз% личия. Но можно хранить версии файлов и других типов: до% кументы, графику и т. д. Исходные файлы этой книги хра% нятся в системе управления версиями, и я могу проследить историю их изменений.
Управление конфигурацией
Основано на управлении версиями и обеспечивает надежную среду для управления разработкой программного обеспече% ния и ведением необходимых процессов.
Распространены такие акронимы, как SCMS (система контроля за исходным кодом), VCS (система управления версиями) и RCS (система управления «ревизиями»).
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
|
E |
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
||
|
F |
|
|
|
|
|
|
t |
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
|
P |
|
|
|
|
|
NOW! |
o |
||
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|||
|
|
|
|
to |
|
|
|
|
|
w Click |
|
|
|
458m |
|||||
|
|
|
|
||||||
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 |
|
|
|
|
|
|
Глава 18. Защита исходного кодаClick |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
ции нескольких вариантов продукта или версий для нескольких платформ).
•Управление релизами продукта и версиями компонент, участвую% щими в каждом релизе.
•Слежение за состоянием кода и его компонент и составление отче% тов. В каком состоянии проект – бета%версия или кандидат на вы# пуск? (См. «Альфа, бета, гамма…» на стр. 197.)
•Управление формальными заявками на модификацию, слежение за их приоритетами и принятием для разработки; связь заявок с необ% ходимой проектной работой, исследованиями, модификацией, тес% тированием и проверкой кода.
•Определение документации, относящейся к конкретным вариантам продукта, и среды для компиляции, необходимой в каждом случае.
•Проверка полноты и корректности программных компонент.
Как вы в данное время управляете конфигурацией своего базового кода?
Резервное копирование
Это обычный здравый смысл. Резервные копии – ваша страховка про% тив случайного удаления файла, отказа вычислительной системы и, ес% ли копия хранится в другом месте, против потери данных в случае по% жара в офисе. От простуды пока еще не лечат, но, возможно, какая%ни% будь занимающаяся резервированием компания уже работает над этим.
Каждый знает, что необходимо регулярно делать резервные копии своих разработок. Но все мы люди; если мы знаем, как нужно разумно действовать, это еще не значит, что так мы и поступаем – есть более срочные (и интересные) дела. Задним умом все сильны: сидя среди ды% мящихся обломков компьютера без всякой надежды его починить и потеряв все данные, вы проклянете ту минуту, когда решили сыграть в солитер, вместо того чтобы сделать копию данных. Работу многих дней нужно повторять заново, и, даже если вы почти все помните, вто% рой раз делать то же самое всегда менее интересно (и тяжело морально). Если к тому же близок срок сдачи работы, это чревато катастрофой.
Задумайтесь: есть ли резервная копия всего вашего кода? Меня ужас берет, когда я вижу, для какого огромного объема работы не выполне% но резервное копирование. Люди подвергают себя бессмысленному риску.
Делайте резервное копирование своих данных. Разработайте стратегию восстановления, не дожидаясь, когда грянет катастрофа.
Вы должны разработать разумную процедуру резервного копирова% ния. Не стоит вручную копировать файлы. В один прекрасный день вы забудете скопировать что%то важное, или допустите слишком большой
|
|
|
|
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 |
|
|
|
|
|
|
459Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
промежуток времени между копированиями, или скопируете не то, что нужно. Вспомните закон Мерфи (на стр. 31): Если что#то может сломаться, оно сломается. Правильным будет поместить все важные файлы в файловую систему, которая участвует в резервном копирова% нии. Если я пользуюсь рабочей станцией, которая не участвует в ре% зервном копировании, я сохраняю свой код на сетевом файл%сервере, для которого делается резервная копия, а не оставляю на ненадежном локальном диске.1
Резервное копирование приносит пользу, если оно:
•Осуществляется регулярно
•Контролируется и проверяется
•Данные легко восстанавливаются
•Осуществляется автоматически (автоматически запускается и вы% полняется без вмешательства оператора)
Важно, чтобы все хранилища исходного кода размещались на сервере, который подвергается резервному копированию. Иначе это все равно что положить ценности в сейф, но не закрыть его. На самом деле, за% пись модификаций в хранилище «часто и понемногу» уменьшает за% висимость от резервного копирования персонального компьютера – большая часть проделанной работы есть в копируемом хранилище. Потеря файлов на вашей рабочей станции не будет иметь решающего значения для всего проекта.
Вывод следующий: ваш труд не защищен, если его нельзя восстано% вить в случае человеческой ошибки или отказа аппаратуры. Даже ес% ли это «всего лишь» код для личного использования, защитите его ре% зервным копированием. Стоит немного потратиться на программу ко% пирования, дополнительную внешнюю память и администрирование. Неприятности, связанные с потерей данных, обойдутся вам значи% тельно дороже.
Выпуск исходного кода
Иногда требуется ослабить хватку, с которой вы вцепились в свой ис% ходный код, и отпустить его в Большой мир. Например, вы можете продавать библиотеку, и вашим продуктом будет сам исходный код. Может быть, в условиях контракта оговорено, что вместе с исполняе% мым модулем вы должны предоставить исходный код. Даже если вы не собираетесь выпускать свой исходный код, он может быть продан новому владельцу или вы решите привлечь сторонних разработчиков
1Разумеется, за все приходится платить. Такой простой подход замедляет доступ к файлам, поскольку начинают играть роль задержки в сети и на файловом сервере. Но это неудобство (обычно малосущественное) можно
пережить.
|
|
|
|
hang |
e |
|
|
|
|
|
|
|
C |
|
E |
|
|||
|
|
X |
|
|
|
|
|||
|
- |
|
|
|
|
|
d |
||
|
F |
|
|
|
|
|
|
t |
|
|
D |
|
|
|
|
|
|
|
i |
|
|
|
|
|
|
|
|
r |
|
P |
|
|
|
|
|
NOW! |
o |
||
|
|
|
|
|
|
||||
|
|
|
|
|
BUY |
|
|||
|
|
|
|
to |
|
|
|
|
|
w Click |
|
|
|
460m |
|||||
|
|
|
|
||||||
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 |
|
|
|
|
|
|
Глава 18. Защита исходного кодаClick |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
для реализации новой функции. Необходимо принять меры, чтобы обеспечить защиту и доступность кода и в таких ситуациях.
Какова степень связанной с этим опасности, зависит от характера ва% шего кода. Закрытый исходный код, написанный специально для внутреннего применения в продуктах компании, является тщательно охраняемой интеллектуальной собственностью, и обычно считается самоубийственным с коммерческой точки зрения выпускать его от% крыто, дав вашим конкурентам возможность воспользоваться им. Пол% ной противоположностью является программное обеспечение с бес# платным или свободно распространяемым исходным кодом (open source), которое специально пишется так, чтобы каждый мог его по% смотреть или модифицировать. В каждом случае характер выпускае% мого продукта и варианты различны:
•Если вы выпускаете некий закрытый фирменный код, необходимо заключить с клиентом соглашение о нераскрытии коммерческой тайны (NDA). Это стандартный договор, который обязывает кли% ента не раскрывать код кому%либо и не использовать его иначе, чем это обусловлено в договоре. Договор имеет юридическую силу, и его главная цель – не давать покоя юристам компании, пока техниче% ские специалисты заняты главным делом – созданием замечатель% ных программ.
Если тот, кому вы предоставили код, собирается использовать его для получения прибыли, нужно заключить лицензионное соглаше% ние, которое обеспечит вашу долю. На самом деле, это забота служб маркетинга или продаж, а простым программистам можно не бес% покоиться по поводу этой грызни между компаниями.
•Разработчики открытого программного обеспечения должны вы% брать тип лицензии, которая определит, что пользователь может делать с кодом и должен ли он раскрыть результаты своей работы, построенной на этом коде. Подробнее о лицензировании программ% ного обеспечения сказано во врезке «Лицензии».
В любом случае нужно обеспечить презентабельный вид файлов исход% ного кода. Код должен быть полностью написан вами или у вас долж% ны быть права распространения для тех частей, которые написаны кем%то другим. Это причина, по которой существует масса старого коммерческого кода, который нельзя сделать открытым: если компа% нии не принадлежат все права на исходный код, его можно свободно распространять только после дорогостоящей модификации.
Чтобы обеспечить себе прочную юридическую основу, поместите в каж% дый файл исходного кода сведения об авторских правах, указав вла% дельца (автора или компанию) и краткое описание лицензии, под ко% торой он выпущен. Тогда тот, кому попадется этот код, будет знать, что это конфиденциальный материал. Подробнее об этом см. раздел «Комментарии в заголовке файла» на стр. 124.
|
|
|
|
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 |
|
|
|
|
|
|
461Click |
|
|
|
|
|
m |
||||
|
|
|
|
|
|
|||||
w |
|
|
|
|
|
|
|
o |
|
|
|
w |
|
|
|
|
|
|
|
|
|
w |
|
|
|
|
|
|
.c |
|
||
|
. |
|
|
|
|
|
|
|||
|
|
p |
|
|
|
|
g |
|
|
|
|
|
|
df |
|
|
n |
e |
|
||
|
|
|
|
-x cha |
|
|
|
|
Следите за тем, чтобы не сделать код доступным непреднамеренно: при% мите меры против реконструкции кода из выполняемого модуля, кото% рая иногда оказывается возможной – особенно в случае компилируе% мых в байт%код языков типа Java и C#. Существуют инструменты для обработки байт%кода с целью воспрепятствовать его реконструкции.
Где я оставлю свой код…
Наконец, подумайте о месте для хранения своего исходного кода. Со% вершенно секретную информацию компании не следует оставлять в ноутбуке, лежащем в незапертой машине. Точно так же не стоит дер% жать исходный код в общедоступной сети.
Храните в тайне свои пароли регистрации. У посторонних (или злона% меренных коллег) не должно быть возможности причинить вам ущерб, воспользовавшись не принадлежащими им правами доступа.
Лицензии
Лицензия на программное обеспечение определяет, какие права
вотношении ПО есть у пользователя. Она касается как про% грамм, распространяемых в двоичном виде, так и исходного ко% да, из которого они созданы. Большинство коммерческих лицен% зий запрещает копирование, модификацию, передачу, сдачу
варенду и запуск на нескольких машинах. Напротив, лицензии open source защищают ваше право копировать и распространять программное обеспечение по своему желанию.
Авторы программ выбирают лицензии исходя из своих задач
иидеологии. На самом деле, автор может выпустить программ% ный продукт под несколькими лицензиями, относящимися к раз% ным схемам его применения и предполагающими разные цены
истепень поддержки. Для исходного кода существует много ти% пов лицензий, хотя лишь некоторые из них используются широ% ко. Они различаются в следующих аспектах:
Допустимые способы применения
Можно ли использовать лицензированный код коммерче% ским образом или его можно применять только в бесплатно распространяемых программах? Проблема не столько в день% гах, сколько в праве включать вашу разработку в закрытый коммерческий продукт без вашего разрешения. Некоторые лицензии open source требуют, чтобы пользователь делал от% крытым любой код, построенный с помощью лицензирован% ного продукта. Коммерческие лицензии обычно допускают любое применение, если вы его оплачиваете.