Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».
Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.
Глава 1. Держим оборону
Не делайте никаких допущений. Не зафиксированные формально допущения, часто служат причиной отказов, особенно с ростом объема кода.
Чем больше спешки, тем меньше скорость. Всегда думайте, что вы собираетесь ввести с клавиатуры.
Не верьте никому. Кто угодно, включая вас самих, может сделать ошибки в логике вашей программы. Ко всем входным и выходным данным относитесь с подозрением, пока не проверите, что они допустимы.
Предупреждения компилятора помогают выявить массу глупых ошибок. Всегда включайте их вывод. Держитесь того, чтобы ваш код компилировался молча.
Берегите все ограниченные ресурсы. Тщательно организуйте их захват и освобождение.
Глава 2. Тонкий расчет
Поймите, кто реально станет читать ваш исходный код: другие программисты. Пишите с расчетом на них.
Выясните, какие стандарты кода есть для выбранного вами языка, и освойте каждый из них на практике. Оцените преимущества и недостатки каждого.
Выберите какой-то один правильный стиль кодирования и придерживайтесь его постоянно.
Если в вашей группе принят некий стандарт кодирования, придерживайтесь его. Свой собственный излюбленный стиль оставьте в стороне.
Скажи «нет» религиозным войнам. Не вступай в них. Отойди в сторону.
Глава 3. Что в имени тебе моем?
Учитесь давать объектам прозрачные имена — они должны ясно описывать то, что за ними скрывается.
Чтобы придумать хорошее имя, главное — четко понимать, для кого оно предназначено. Только в этом случае имя может стать осмысленным. Если не удается придумать хорошее имя объекту, спросите себя, понятно ли его назначение.
Изучите правила образования имен в языке, с которым работаете. Еще важнее изучить идиомы этого языка. Есть стандартные способы формирования имен? Вот ими и пользуйтесь.
Ясность имени предпочтительнее его краткости.
Следует учитывать относительные достоинства коротких и длинных имен, особенно в зависимости от области действия переменной.
Предпочтительней такое правило именования, которое различает имена переменных и имена типов.
Давайте функциям имена с внешней точки зрения, в виде фраз, выражающих действия. Описывайте логическую операцию, а не способ реализации.
Избегайте в именах лишних слов. В частности, в именах типов — таких слов, как class, data, object и type.
Давайте пространствам имен и пакетам имена, логически связанные с содержимым.
Макросы в С/С++ всегда выделяют прописными буквами, чтобы сделать хорошо заметными, и тщательно выбирают их имена, чтобы избежать конфликтов. Никогда не выделяйте прописными буквами другие объекты.
Выберите единообразную системы именования и последовательно применяйте ее.
Степень необходимой детализации имени зависит от контекста его применения. Создавая имена, учитывайте контекстную информацию.
Глава 4. Литературоведение
Не пишите код, который нуждается во внешней документации. Он ненадежен. Пишите такой код, который понятен без посторонней документации.
Пишите код, который может прочесть нормальный человек, причем без напряжения. Компилятор как-нибудь справится.
Избегайте волшебных чисел. Пользуйтесь именованными константами.
Важный участки кода должны выделяться на общем фоне и быть легко читаемыми. Спрячьте все, что не должно интересовать клиентов.
Старайтесь группировать родственную информацию. Делайте эту группировку наглядной с помощью средств языка.
Не выводите бессмысленных сообщений об ошибках. В зависимости от контекста представьте наиболее уместную информацию.
Помещайте в код комментарии только в том случае, если не удается облегчить его понимание иными способами.
Пользуйтесь инструментариями грамотного документирования для автоматической генерации документации по вашему коду.
Глава 5. Заметки на полях
Учитесь писать ровно столько комментариев, сколько необходимо. Отдайте предпочтение качеству, а не количеству.
Не пожалейте труда, чтобы ваш код не требовал поддержки в виде уймы комментариев.
Хорошие комментарии объясняют «почему», а не «как».
Один источник для каждого факта. Не копируйте код в комментариях.
Обнаружив, что вы пишете многословные комментарии, описывающие ваш код, остановитесь и задумайтесь. Не признак ли это того, что существует некая проблема более высокого порядка?
Думайте, что пишете в комментариях; не давите бездумно на клавиши. Прочтите комментарий снова в контексте кода. Ту ли информацию он содержит?
Комментарии — часть повествования кода. Размещайте их так, чтобы порядок чтения был естественным.
Снабжайте каждый файл исходного кода прологом в виде комментария.
Комментарии должны касаться настоящего, а не прошлого. Не описывайте того, что претерпело изменения, и не рассказывайте о том, что было раньше.
Если вы изменили код, проверьте правильность комментариев, находящихся рядом с ним.
Глава 6. Людям свойственно ошибаться
Обработка ошибок — дело серьезное. От нее зависит стабильность вашего кода.
Не оставляйте сбойную ситуацию без внимания. Если вы не знаете, как справиться с проблемой, сигнализируйте об отказе вызвавшему коду. Не заметайте мусор под ковер в надежде, что все как-нибудь обойдется.
Никогда не пренебрегайте поступающими вам сообщениями об ошибках. Если существует канал для сообщений об ошибках, значит, для этого есть причины.
Обрабатывайте все ошибки в наиболее благоприятном контексте, когда становится ясно, как корректно с ней справиться.
Игнорирование ошибок не экономит вашего времени. Вы потратите больше времени на выяснение причин некорректного поведения программы, чем вам понадобилось бы для написания обработчика ошибок.
Если вы пишете код, который может отказать, одновременно с ним пишите код для обнаружения и обработки ошибок. Не откладывайте это на будущее. Если вы все же вынуждены отложить обработку, по крайней мере, напишите оснастку для обнаружения ошибок.
Глава 7. Инструментарий программиста
Изучите свои стандартные инструменты вдоль и поперек. Время, которое вы потратите на их изучение, незамедлительно окупится.
Относитесь к инструментам программирования прагматически; пользуйтесь ими, только если они облегчают вашу жизнь.
Узнайте, какие виды инструментов существуют. Выясните, где их можно взять, даже если в данный момент они вам не нужны.
Для каждой задачи есть свой инструмент. Не стоит щелкать орехи кувалдой.
Следите за выпуском новейших версий своего инструмента, но проявляйте осторожность при обновлении.
Выбор редактора кода имеет решающее значение; он оказывает огромное влияние на то, как вы будете писать код.
Выучите несколько языков. В каждом вы обнаружите особый способ решения задач. Рассматривайте их как набор инструментов и выбирайте тот, который наиболее эффективен в конкретной ситуации.
Глава 8. Время испытаний
Тестирование может вскрыть только наличие ошибок. Оно не может доказать отсутствие неисправностей. Не поддавайтесь ложному чувству спокойствия, если код прошел ряд неадекватных тестов.
Тестируйте каждый написанный вами фрагмент кода. Не рассчитывайте, что кто-то другой сделает это за вас.
Чтобы сделать тестирование эффективным, его нужно начинать заранее, когда выявляемые ошибки еще не могут принести большого вреда. Тестовый код можно писать раньше, чем рабочий!
Пишите тесты для всех выявленных ошибок.
Прогоняйте свои тесты как можно чаще.
Читая код, очень легко обмануться и поверить, что он работает правильно. Если вы написали код, то при его чтении вы будете видеть то, чтособирались написать, а не то, что написали на самом деле. Учитесь читать код с циничным недоверием.
Напишите полный набор тестов, каждый из которых будет проверять определенный аспект кода. Пятнадцать тестов, которые демонстрируют одну и ту же ошибку, менее полезны, чем 15 тестов, демонстрирующих 15 разных ошибок.
Архитектура кода должна облегчать его тестирование.
Насколько это возможно, автоматизируйте тестирование кода. Это быстрее и проще, чем выполнять тесты вручную, и гораздо надежнее: более вероятно, что тесты станут выполняться регулярно.
Выполняйте тестирование автоматически в ходе процедуры сборки.
Глава 9. Поиск ошибок
Компилируйте код при включенном выводе компилятором всех предупредительных сообщений. Тем самым вы обнаружите потенциальные проблемы раньше, чем столкнетесь с ними реально.
Следуйте золотому правилу отладки: думать головой.
Установите разумное временное ограничение на «бессистемную» отладку, и если она окажется безуспешной, переходите на более методичный способ.
Изучите отлаживаемый код — трудно найти ошибки в коде, который вам непонятен.
Когда вы ищете ошибку, неверьте никому. Проверьте самые невероятные причины, вместо того чтобы сходу отвергнуть их. Не принимайте ничего на веру.
Если сборка продукта не прошла, смотрите на первую ошибку компилятора. Последующие сообщения заслуживают гораздо меньше доверия.
Отладка — это методичная работа, медленно сужающая кольцо вокруг места нахождения ошибки. Не следует относиться к ней как к игре в укадайку.
Первый шаг на пути установления места ошибки — это определение способа ее уверенного воспроизведения.
Начните с известного места, например, с точки аварийного завершения программы. Затем двигайтесь в обратном направлении в сторону причины, вызвавшей сбой.
Если вам показалось, что вы нашли причину ошибки, досконально исследуйте ее и убедитесь, что не ошиблись. Не принимайте безрассудно первую же гипотезу.
Отладка заканчивается лишь тогда, когда вы докажете, что ошибка устранена и проблема решена навсегда.
Проявляйте крайнюю осторожность при исправлении ошибок. Следите, чтобы ваша модификация не покалечила ничего остального.
Исправляя ошибку, проверьте, не повторяется ли она в близких разделах кода. Уничтожьте ошибку раз и навсегда: исправьте все ее дубликаты немедленно.
Из каждой исправленной ошибки делайте выводы. Можно ли было ее избежать? Можно ли было обнаружить ее быстрее?
Столкнувшись с поведением, которое вы не можете объяснить, умеренно пользуйтесь отладчиками. Не привыкайте к тому, чтобы сразу бросаться на них, не попытавшись сначала понять, как работает ваш код.
Глава 10. Код, который построил Джек
Считайте систему сборки частью дерева исходного кода и ведите их совместно. Они тесно связаны между собой.
Все программисты, участвующие в проекте, должны пользоваться единой системой сборки. Иначе все они будут собираться разные программные пакеты.
Правильная система сборки позволяет многократно создавать физически идентичные бинарные файлы.
Вы должны быть в состоянии достать дерево исходные кодов трехлетней давности и правильно собрать его заново.
Правильная система выглядит как одна операция. Достаточно нажать кнопку или выполнить одну команду.
Для каждого правила сборки напишите соответствующее правило чистки, которое отменяет всю операцию.
Организуйте автоматическую процедуру сборки своего программного продукта. Проверяйте с ее помощью работоспособность вашего кода.
Финальные сборки всегда выполняются из чистого исходного кода. Позаботьтесь, чтобы потом всегда можно было получить этот чистый исходный код из архива или системы управления версиями.
Проводите тестирование финальной конфигурации своего приложения, а не только рабочих сборок.Небольшие различия между ними могут отрицательно сказаться на поведении кода.
Глава 11. Жажда скорости
Об эффективности работы программы нужно думать с самого начала — не надейтесь, что в конце разработки вам удастся повысить ее ценой небольших изменений.
Корректность кода гораздо важнее его скорости. Что толку быстро получить результат, если он неверный!
Рассмотрите альтернативы оптимизации; не удастся ли вам повысить эффективность программы иными способами?
Выясните, действительно ли есть необходимость оптимизировать код, но лучше с самого начала писать эффективный код высокого качества.
Оптимизируйте код отдельно от всякой прочей работы, чтобы результаты одной работы не оказывали влияния на другую.
Оптимизируйте окончательные версии программы, а не промежуточные сборки.
Тщательно отберите входные данные для профилирования, с тем чтобы они отражали реальный мир. В противном случае может оказаться, что вы оптимизируете те части программы, которые в обычных условиях не выполняются.
Не ограничивайтесь профайлером при поиске причин недостаточной эффективности программы; они могут оказаться более глубокими.
Обязательно проведите измерения до и после оптимизации.
Лучше заменить медленный алгоритм быстрым, чем пытаться улучшить реализацию имеющегося алгоритма.
Глава 12. Комплекс незащищенности
Следует учитывать, какими важными ресурсами вы располагаете. Есть ли у вас особо деликатная информация или специальные возможности, за которыми могут охотиться? Обеспечьте их защиту.
Чем сложнее компьютерная система, тем более вероятно, что в ее системе безопасности есть пробелы. Следовательно, пишите как можно более простое программное обеспечение!
Не проходите мимо уязвимостей и не считайте себя непобедимым. Где-нибудь обязательно найдется тот, кто пытается применить эксплойт к вашему коду.
Запускайте на своем компьютере только программы, полученные из надежных источников. Установите четкую политику определения надежности источников.
Безопасность — важный аспект архитектуры любого программного продукта. Будет ошибкой не позаботиться о ней на ранних стадиях разработки.
Проектируя программу, рассчитывайте только на известные, защищенные компоненты сторонних разработчиков.
Готовьтесь к тому, что ваша система будет атакована, и проектируйте с учетом этого все ее части.
Глава 13. Важность проектирования
Программирование — это работа по проектированию. Это творческий и художественный акт, а не механическое написание кода.
Думайте, прежде чем стучать по клавишам; составьте понятный проект. Иначе у вас получится не код, а хаос.
Чем меньше, тем лучше. Вашей целью должен быть простой код, который при малом размере решает большие задачи.
Сделать простую вещь сложно. Если структура кода кажется очевидной, не надо думать, что это далось без труда.
Проектируйте такие модули, которые внутренне связны и минимально соединены между собой. Декомпозиция должна отражать правильное разбиение задачи на части.
Проведите черту, за которую никто не должен переступать: определите четкие API и интерфейсы.
Проектируйте с учетом последующего расширения, но неперестарайтесь, иначе вы напишете не программу, а ОС.
Делай один раз. Делай хорошо. Избегай дублирования.
Решайте вопросы переносимости кода на этапе проектирования, а не путем переделки готового кода.
Прагматически относитесь к инструментам и методологиям проектирования: применяйте их тогда, когда это действительно полезно, но не становитесь их рабами.
Глава 14. Программная архитектура
Архитектура оказывает самое большое влияние на проектирование и дальнейшее развитие программной системы. По этой причине важно правильно определить ее на самых ранних стадиях разработки.
Храните описание системной архитектуры в таком месте, где оно доступно всем, кому может потребоваться: программистом, ответственным за сопровождение и установку, менеджерам, а возможно, и клиентам.
Спецификация архитектуры — важное средство для информирования о состоянии вашей системы. Следите за тем, чтобы она соответствала состоянию программного обеспечения.
Все проектные решения для программного продукта принимайте в контексте архитектуры. Следите за тем, чтобы не отклоняться от системного видения и стратегии. Не делайте мелких ни к чему не относящихся изменений.
Хорошая архитектура системы должны быть простой. Достаточно бывает описания, состоящего из одного абзаца и одной простой диаграммы.
Архитектура определяет важнейшие компоненты системы и их взаимодействие. Она не описывает их устройство.
Хорошая архитектура оставляет пространство для маневра, расширения, модификации. Но ее общность не переходит разумных границ.
Разберитесь с основными архитектурными стилями и оцените их достоинства и недостатки. Это поможет вам более благожелательно относиться к программным продуктам, с которыми вы столкнетесь, и правильно проектировать системы.
Глава 15. Программное обеспечение — эволюция или революция?
Помните о том, как легко деградирует модифицируемый код. Избегайте модификаций, после которых система оказывается в худшем состоянии.
Научитесь обнаруживать испорченный код. Изучите его признаки и обращайтесь с разложившимся кодом с крайней осторожностью.
Добросовествно относитесь к написанию кода. Хорошие программисты думают о том, как будет выглядеть их код через несколько лет, а не о том, сколько усилий им понадобится приложить сегодня.
Пишите новый код с учетом возможной потребности модифицировать его в будущем. Делайте его понятным, расширяемым и простым.
Соблюдайте осторожность при модификации. Будьте в курсе того, не занимается ли кто-то модификацией близлежащего кода.
Проводите обсуждение опасных изменений, особенно при подготовке к выпуску новой версии. Даже простейшие модификации могут нарушить работу другого кода.
Не курочьте код бездумно. Остановитесь и поразмыслите, чем вы занимаетесь.
Тщательно тестируйте все сделанные вами модификации, какими простыми они бы ни были. Очень легко пропустить глупую ошибку.
Глава 16. Кодеры
Выясните, к какому типу программистов вы относитесь. Определите, как можно выгодно использовать свои хорошие качества и компенсировать плохие.
Глава 17. Вместе мы — сила
Умение работать в команде — важное качество высококвалифицированного разработчика программного обеспечения.
На результирующий код влияют как отношения внутри команды, так и внешние контакты. Следите за тем, как они отражаются на вашей работе.
Организуйте свою команду в соответствии с кодом, который собираетесь построить, а не наоборот — код в соответствии с имеющейся командой.
Наличие каналов для эффективного общения жизненно необходимо для нормальной работы команды. Такие каналы необходимо организовать и поддерживать. Хороший программист должен уметь хорошо общаться.
Никто из программистов не является владельцем никакой части кода. Каждый из участников имеет доступ ко всему коду и может модифицировать его по мере надобности.
Успешные команды развиваются и работают целенаправленно; их возникновение нельзя приписывать случаю.
Не теряйте информацию при уходе людей из команды. Организуйте ее передачу и получите от них все важные данные, включая документацию по коду, инструментарий тестирования и инструкции по сопровождению.
Глава 18. Защите исходного кода
Код обладает ценностью. Относитесь к нему с уважением и заботой.
Система контроля версий — важный инструмент разработки программного обеспечения. Она необходима для надежной работы команды.
Внимательно относитесь к хранилищу. Следите, чтобы не записать в него неработающий код, который не позволит работать остальным разработчикам.
Делайте резервное копирование своих данных. Разработайте стратегии восстановления, не дожидаясь, когда грянет катастрофа.
Глава 19. Спецификации
Процесс разработки программного обеспечения нуждается не просто в наличии спецификаций, но в их высоком качестве.
Спецификации — важный механизм связи между разработчиками программного обеспечения. Они служат для фиксирования сведений, которые не должны быть потеряны или забыты.
Требования к программному обеспечению нужно установить заранее, чтобы не возникало неоправдавшихся ожиданий, чтобы препятствовать расширению функциональности и снизить беспокойство разработчиков.
Если ваша задача программирования недостаточно четко поставлена, не начинайте кодирование, не написав спецификации и не согласовав ее.
Пользуйтесь инструментами грамотного программирования для составления технической документации. Не пишите в текстовом редакторе документ, который быстро устаревает.
Составляя спецификацию, обдумайте ее содержание. Выберите структуру и словарь, понятные аудитории, и убедитесь, что документ корректен, полон и содержит собственное описание.
Избегать составления спецификаций опасно и непрофессионально. Если не хватает времени для написания спецификаций, его, скорее всего, недостаточно и для написания кода.
Глава 20. Рецензия на отстрел
Рецензирование кода — отличное средство для поиска и устранения скрытых ошибок, повышения качества кода, усиления коллективной ответственности за код и распространения знаний.
Создавая систему, выясните, нужно ли проводить рецензирование, и если да, то какого кода.
Тщательно отберите код для рецензирования. Если вы не можете прорецензировать весь код, сделайте обоснованный выбор. Не нужно отбирать наугад и терять драгоценное время.
Кем бы ни был написан код, он подлежит рецензированию и тщательному изучению со стороны коллег. Добивайтесь рецензирования своего кода.
Успех рецензирования сильно зависит от позитивной позиции автора и рецензентов. Цель рецензирования — совместными усилиями улучшить код, а не назначить виновных или оправдать решения, принятые во время реализации.
Если вы не знаете, как должен выглядеть хороший код, вы не сможете обоснованно судить о качестве работы других программистов.
Глава 21. Какой длины веревочка?
Оценка длительности разработки программного продукта представляет собой основанную на фактах догадку. Для каждой оценки есть некоторая мера вашей уверенности в ней.
Оценка времени разработки программ представляет собой действительно трудную задачу. Избегайте недооценки объема предстоящей работы. Учтите возможные последствия неправильной оценки.
Все (включая вас) хотят сокращенных графиков. Не обманывайте себя относительно того, что реально можно сделать за выделенное вам время. Не давайте нереальных обещаний, когда требуется предоставить код, готовый для поставки.
Оценки времени надо применять к небольшим задачам, объем работы которых легко понять. Единицей измерения должны быть человеко-часы или человеко-дни.
Различайте, чью работу вы оцениваете по срокам: свою (над системой, которую хорошо понимаете) или чужую (того, кому может потребоваться изучение системы).
Не занимайтесь оцениванием в одиночестве. Выясните мнение других людей, чтобы уточнить свои оценки.
Составляйте графики работ так, чтобы оставалось время на приведение кода в порядок. Планируйте возврат технической задолженности.
Постоянно сверяйте свои успехи с планом. Тогда не случится внезапно обнаруженного отставания.
Глава 22. Рецепт программы
Хорошие программисты знают, как программировать — владеют методами и приемами работы.
Наши программные проекты определяются теми стилями и процессами, которые мы применяем. Они неизбежно отражаются на форме и качестве кода.
Без процесса разработки команда находится в состоянии анархии. Программы появляются благодаря удаче, а не в результате целенаправленных действий.
Выбор рецепта программы может определяться многими причинами, которые должны быть вескими. Мотивировка вашего выбора многое говорит о степени зрелости вашей организации.
Процесс, который вы принимаете, не должен быть слишком формальным и трудным в осуществлении. Обычно признаками хорошего процесса служат как раз противоположные характеристики. Однако определенный процесс должен быть.
Выборпроцесса имеет жизненно важное значение. Неудачные проекты в большинстве случаев оказываются такими не по техническим причинам. Почти всегда одной из главных причин оказывается плохая организация процесса.
Глава 23. За гранью возможного
Существуют разные виды программирования в различных предметных областях. В каждой области есть свои особые проблемы и требуются специфические умения и опыт.
Знайте свою область программирования. Изечите ее специфику. Научитесь писать отличные программы, которые удовлетворяют ее требованиям.
Глава 24. Что дальше?
Чтобы стать хорошим программистом, нужно выбрать правильную позицию — тот угол, под которым рассматривается создание программного обеспечения.
Занимайтесь совершенствованием своего мастерства. Не теряйте любви к программированию и желания быть в нем мастером.
Автор: andreycha
