The Pragmatic Programmer: From Journeyman to Master
Andrew Hunt, Dave Thomas
Подсказка 1: Позаботьтесь о вашем ремесле. Нет смысла разрабатывать программы, если вы не заботитесь о качестве работы.
Подсказка 2: Думай! О своей работе
Отесывая камни, всегда думай о соборах, которые будут строиться из них. Кредо средневекового каменотеса
"Кайдзен" – японский термин, означающий политику непрерывного внедрения большого количества мелких усовершенствований.
Каждый день необходимо работать, оттачивая свои навыки и добавляя в свой репертуар новые произведения.
Страх показаться слабым есть величайшая из всех слабостей. Ж. Б. Боссюэ, Политика и Священное Писание, 1709
Если вы приняли на себя ответственность за результат, то вам придется за него перед кем-то отчитываться. Если вы делаете ошибку (как и все мы), признайте ее честно и попытайтесь предложить варианты исправления. Не стоит перекладывать вину на кого-либо (или на что-либо) или выдумывать отговорки.
Подсказка 3: Представьте варианты решения проблемы, а не варианты отговорок
Подсказка 4: Не живите с разбитыми окнами
Подсказка 5: Будьте катализатором изменений
Подсказка 6: Следите за изменениями
Не будьте лягушкой. Не сводите глаз с общей картины происходящего. Постоянно наблюдайте за тем, что происходит вокруг вас, а не только за тем, что делаете вы лично.
Подсказка 7: Сделайте качество одним из пунктов требований
Не стоит портить очень хорошую программу путем приукрашивания и излишней шлифовки.
Инвестиции в знания окупаются лучше всего. Бенджамин Франклин
Портфелями знаний мы предпочитаем называть все факты, известные программистам об информатике, области приложений, в которых они работают, и накопленный ими опыт. Управление портфелем знаний очень похоже на управление финансовым портфелем:
- Серьезные инвесторы инвестируют регулярно – это как привычка
- Диверсификация – это залог успеха в течение длительного времени.
- У проворных инвесторов портфель всегда сбалансирован – в нем имеются и консервативные, и высокорисковые, высокодоходные инвестиции.
- Инвесторы стараются покупать ценные бумаги подешевле и продавать их подороже, обеспечивая тем самым максимальный возврат.
- Портфели нуждаются в периодическом пересмотре и повторной балансировке. Управляйте вашим портфелем знаний, используя те же самые принципы, и ваша карьера будет успешной.
Подсказка 8: Инвестируйте регулярно в ваш портфель знаний
Цели
- Учите (как минимум) по одному языку программирования каждый год.Различные языки решают различные проблемы по-разному. Выучив несколько различных подходов, вы можете расширить мышление и избежать закоснелости.
- Читайте по одной технической книге ежеквартально.
- Читайте книги, не относящиеся к технической литературе.
- Повышайте квалификацию на курсах.
- Участвуйте в собраниях локальных групп пользователей.
- Экспериментируйте с различными операционными средами
- Оставайтесь в курсе событий. Подпишитесь
- Подключайтесь к информационным сетям.
Подсказка 9: Критически анализируйте прочитанное и услышанное
Лучше быть проигнорированным вовсе, чем недооцененным. Мэй Уэст, Красавица 90-х, 1934.
Лучшие идеи, лучшие программы или самое прагматичное мышление практически не приносят результата, если вы не можете общаться с другими людьми.
Подсказка 10: Важно, что говорить и как говорить
КАЖДЫЙ ФРАГМЕНТ ЗНАНИЯ ДОЛЖЕН ИМЕТЬ ЕДИНСТВЕННОЕ, ОДНОЗНАЧНОЕ, НАДЕЖНОЕ ПРЕДСТАВЛЕНИЕ В СИСТЕМЕ.
Подсказка 11: Не повторяй самого себя
дублирования подпадают под одну из следующих категорий:
- Навязанное дублирование. Разработчики чувствуют, что у них нет выбора – им кажется, что дублирования требует среда окружения.
- Неумышленное дублирование. Разработчики не осознают, что они тиражируют информацию.
- Нетерпеливое дублирование. Разработчики ленятся и осуществляют дублирование, потому что им кажется, что так проще.
- Коллективное дублирование. Фрагмент информации тиражируются несколькими членами одной команды разработчиков (или нескольких команд) Рассмотрим эти четыре категории дублирования более подробно.
где это возможно, всегда используются функции средства доступа – для чтения и записи атрибутов объектов [6]. Это облегчает добавление функциональных возможностей (типа кэширования) в будущем.
Назначьте одного из членов команды библиотекарем проекта, чьей обязанностью будет обеспечение обмена знаниями. Организуйте специальное место в каталоге с исходными текстами, в котором будут сохраняться сервисные подпрограммы и скрипты. Обратите особое внимание на чтение исходного текста и документации других членов команды, неформально или при анализе текста программы. При этом вы отнюдь не шпионите за ними – вы учитесь у них. И помните, что доступ к тексту программы осуществляется по взаимной договоренности – вас не должно коробить, если и другие члены команды сосредоточенно изучают (или вынюхивают?) ваш текст программы.
Подсказка 12: Сделайте так, чтобы программу можно было легко использовать повторно
Подсказка 13: Исключайте взаимодействие между объектами, не относящимися друг к другу
Есть ряд методик, которые можно использовать для поддержки ортогональности:
- Сохраните вашу программу «несвязанной». Напишите «скромную» программу – модули, которые не раскрывают ничего лишнего для других модулей и не полагаются на их внедрение. Попробуйте применить закон Деметера [LH89], который обсуждается в разделе "Несвязанность и закон Деметера". При необходимости изменения состояния объекта это должен делать сам объект. В таком случае программа остается изолированной от реализации другой программы, а вероятность того, что система останется ортогональной, увеличивается.
- Избегайте глобальных данных. Всякий раз, когда ваша программа ссылается на глобальные данные, она привязывается к другим компонентам, использующим эти данные. Даже глобальные переменные, которые вы собираетесь использовать только для чтения, могут вызвать проблемы (например, если вам необходимо срочно изменить программу, сделав ее многопоточной). Вообще программа станет проще в понимании и сопровождении, если вы явно перешлете любой требуемый контекст в ваши модули. В объектно-ориентированных приложениях контекст часто пересылается как параметр к конструкторам объектов. В другой программе вы можете создать конструкции, содержащие контекст, и обходить ссылки на них. Шаблон Singleton, упомянутый в книге "Design Patterns" [GHJV95], представляет собой способ подтвердить существование единственного представителя объекта определенного класса. Многие используют эти объекты типа Singleton как своего рода глобальную переменную (особенно при работе с языками типа Java, которые иначе не поддерживают технологию глобальных переменных). Будьте внимательны с шаблонами Singleton – они также могут приводить к ненужному связыванию.
- Подобные функции. Зачастую вы сталкиваетесь с набором функций, похожих друг на друга; возможно, они используют общий фрагмент в начале и конце программы, но в ее середине каждая пользуется своим алгоритмом. Дублированная программа является признаком структурных проблем. Для того чтобы составить программу лучше, следует обратить внимание на шаблон Strategy в книге "Design Patterns". Пусть постоянное критическое отношение к вашей программе войдет у вас в привычку. Ищите любые возможности реорганизации для усовершенствования ее конструкции и повышения уровня ортогональности. Этот процесс называется реорганизацией, и он важен настолько, что в книге ему посвящен целый раздел (см. "Реорганизация").
Нет ничего опаснее идеи, если это единственное, что у вас есть. Эмиль-Огюст Шартье, Разговор о религии, 1938
Подсказка 14: Не существует окончательных решений
Подсказка 15: Пользуйтесь трассирующими пулями, для того чтобы найти цель
Подсказка 16 Создавайте прототипы, чтобы учиться на них
Цель работы с прототипом – исследование определенных характеристик (аспектов) конечной версии системы. Создавая истинный прототип, вы отбросите все то, что критиковали при опробовании принципа, и перепишете его надлежащим образом, используя полученные уроки.
Подсказка 17: Программируйте ближе к предметной области вашей задачи
Подсказка 18: Проводите оценки во избежание сюрпризов
Заведите журнал регистрации сделанных вами оценок. Для каждой оценки укажите, насколько точной она оказалась. Если отклонение превысило 50 %, постарайтесь выяснить, где была допущена ошибка.
Подсказка 19: Уточняйте график проекта на основе текста программы
Подсказка 20: Сохраняйте знания в формате простого текста
Подсказка 21: Используйте сильные стороны командных оболочек
Подсказка 22: Используйте один текстовый редактор, но по максимуму
Подсказка 23: Всегда используйте управление исходным текстом программы
Подсказка 24: Занимайтесь устранением проблемы, а не обвинениями
Подсказка 25: Не паникуйте
Подсказка 26: Ищите ошибки вне пределов операционной системы
Подсказка 27: Не предполагайте – доказывайте
Подсказка 29: Пишите текст программы, которая пишет текст программы
Подсказка 31: Проектируйте в соответствии с контрактами
Подсказка 32: Пусть аварийное завершение работы программы произойдет как можно раньше
В большинстве случаев мертвая программа приносит намного меньше вреда, чем испорченная.
Подсказка 33: Если что-либо не может произойти, воспользуйтесь утверждениями, которые гарантируют, что это не произойдет вовсе
Подсказка 34: Пользуйтесь исключениями только в исключительных случаях
Подсказка 35: Доводите до конца то, что начинаете
При работе на более низком (но не менее полезном) уровне можно потратиться на инструментальные средства, которые (помимо всего прочего) проверяют выполняемые программы на наличие утечек памяти (регулярного неосвобождения области памяти). Весьма популярными являются Purify (www.rational.com) и Insure++ (www.parasoft.com).
Хороший способ сохранить гибкость – это писать программы меньшего размера.
Хорошая изгородь – добрые соседи. Роберт Фрост, Подготовка к выборам
Подсказка 36: Минимизируйте связывание между модулями
Подсказка 37: Осуществляйте настройку, а не интеграцию
Подсказка 38: Пом ещайте абстракции в текст программы, а подробности – в область метаданных
Подсказка 39: Анализируйте последовательность операций для увеличения параллелизма
Подсказка 40: Проектируйте, используя службы
Подсказка 41: При проектировании всегда есть место параллелизму
Подсказка 42: Отделяйте визуальные представления от моделей
Подсказка 43: Используйте доски объявлений для координации потоков работ
Подсказка 44: Не пишите программы в расчете на стечение обстоятельств
Подсказка 45: Оцените порядок ваших алгоритмов
Подсказка 46: Проверяйте ваши оценки
Подсказка 47: Реорганизация должна проводиться часто и как можно раньше
1. Не пытайтесь одновременно производить реорганизацию и добавлять функциональные возможности. 2. Перед тем как начинать реорганизацию, убедитесь, что тестирование прошло успешно. Проводите тестирование как можно чаще. В этом случае вы сразу увидите нарушение, которое было вызвано внесенными изменениями. 3. Двигайтесь обдуманно и не спеша: переместите поле из одного класса в другой, объедините два подобных метода в суперкласс. Часто при реорганизации вносится много локальных изменений, которые приводят к серьезным сдвигам. Если вы двигаетесь без спешки и проводите тестирование после каждого шага, вы избежите длительной процедуры отладки.
Подсказка 48: Проектируйте с учетом тестирования
Подсказка 49: Тестируйте ваши программы, в противном случае это сделают ваши пользователи
Подсказка 50: Не пользуйтесь программой функции-мастера, которую не понимаете
Подсказка 51: Не собирайте требования – выискивайте их
Подсказка 52: Работайте с пользователем, чтобы мыслить категориями пользователя
Подсказка 53: Абстракции живут дольше, чем подробности
Подсказка 54: Используйте глоссарий проекта
Подсказка 55: Не размышляйте вне ящика – найдите этот ящик
Подсказка 56: Прислушайтесь к сомнениям – начинайте тогда, когда полностью готовы
Подсказка 57: Некоторые вещи лучше сделать, чем описывать
Подсказка 58: Не будьте рабом формальных методов
Подсказка 59: Дорогие инструменты не всегда создают лучшие решения
Команда в целом не должна допускать наличия разбитых окон – этих маленьких недостатков, которые никем не устраняются.
В маркетинге существует простой трюк, помогающий командам взаимодействовать как одно целое: создание брэнда. Когда вы начинаете некий проект, придумайте имя для проектной команды, в идеале – нечто из ряда вон выходящее.
Некоторые команды включают в свой состав библиотекаря проекта, который несет ответственность за координацию документации и хранение текстов исходных программ.
Подсказка 60: Организуйте команду на основе функциональности, а не должностных обязанностей
Проекту необходимы как минимум два руководителя – один технический, другой административный. Технический руководитель определяет философию и стиль разработки, распределяет обязанности между группами и является арбитром в неизбежных «дискуссиях» между членами команды. Он также осуществляет контроль за ситуацией в целом, стараясь найти ненужную общность задач между группами, которая снижает ортогональность общих прилагаемых усилий. Административный руководитель, или руководитель проекта, намечает ресурсы, необходимые группам, контролирует ход выполнения работ, отчитывается о проделанной работе и помогает в определении приоритетов с точки зрения потребностей бизнеса. Административный руководитель может действовать и в роли полномочного представителя команды при общении с внешним миром.
Подсказка 61: Не используйте процедуры, выполняемые вручную
С помощью cron можно планировать процедуры резервного копирования, сопровождение web-сайтов и любых других операций, которые нужно проводить без участия пользователя, т. е. автоматически.
Подсказка 62: Тестируйте раньше. Тестируйте часто. Тестируйте автоматически
Подсказка 63: Программа не считается написанной, пока не пройдет тестирование
Подсказка 64: Используйте диверсантов для тестирования самих тестов
Подсказка 65: Тестируйте степень покрытия состояний, а не строк текста программы
Подсказка 66: Дефект должен обнаруживаться единожды
А у нас просто нет времени гоняться за дефектами, которые автоматизированные тесты не могли обнаружить.
Лучше выцветшие чернила, чем отличная память. Китайская пословица
Подсказка 67: Считайте естественный язык одним из языков программирования
Подсказка 68: Встраивайте документацию в проект, а не накручивайте ее сверху
Вот перечень того, чего не должно быть в комментариях к исходному тексту программы.
- Перечень функций, экспортируемых программой в файл.Существуют программы, которые анализируют исходный текст. Воспользуйтесь ими, и этот перечень никогда не устареет.
- Хронология изменений.Для этого предназначены системы управления исходным текстом программы (см. "Управление исходным текстом"). Однако, будет полезно включить информацию о дате последнего изменения и сотруднике, который внес это изменение [52].
- Список файлов, используемых данным файлом.Это можно более точно определить при помощи автоматических и нструментальных средств.
- Имя файла.Если оно должно указываться в файле, не поддерживайте его вручную. Система RCS и ей подобные могут обновлять эту информацию автоматически. При перемещении и удалении файла вам не хочется вспоминать о необходимости редактирования заголовка.