12 июля 2012 в 01:53

Ремесло программиста. Золотые правила

imageДанный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

Кто-то освежит память, кто-то сверится как с чек-листом, а кто-то заинтересуется и прочтет книгу. Т.к. пост получился достаточно объемным, можно добавить его в закладки и периодически к нему возвращаться.

Глава 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
карма
133,0
рейтинг 0,0
Пользователь
Самое читаемое Разработка

Комментарии (62)

  • +72
    Кто-нибудь дочитал?
    • +18
      Первое предложение из каждого абзаца.
    • +3
      Дочитал. Воды многовато, но в целом очень неплохо. За статью спасибо.
    • +1
      Дочитал. Хотя вторую половину — по диагонали.
    • +5
      а я прокрутил до коментов=)
    • 0
      Пост — да.
      И даже несколько вещей взял на заметку в моем текущем контексте.
      Книгу — нет, даже не брал в руки :-)
    • +2
      Добавил в избранное, завтра прочитаю. Или послезавтра.
      • +2
        то есть никогда :)
        • 0
          Я уже скинул на свой Incredible S и читаю в автобусе по утрам.
    • +3
      А автор прочитал всю книгу!
    • 0
      по 2-3 строчки с каждого)
    • +2
      Я!)
    • +3
      Чуть не сдох, читал день.
  • +39
    Промотал, фоток не нашел — забил.
    • +6
      Поражаюсь вашему трудолюбию. Я то, что длиннее 140 символов, даже и не проматываю.
  • –3
    11. Об эффективности работы программы нужно думать с самого начала — не надейтесь, что в конце разработки вам удастся повысить ее ценой небольших изменений.

    Ну наконец-то, голос разума снизошел с небес.

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

    • +9
      По-моему, вы путаете оптимизацию и проектирование. Оптимизировать неправильно спроектированную систему постфактум — сложно/нереально. Оптимизировать систему на этапе разработки не менее сложно (читайте «непродуктивно»).
      • –1
        Система, и общий сценарий в которых работаю я:
        разработка -> тестирование -> рефакторинг -> тестирование -> релиз
        разработка — чтобы работало
        тесторование — чтобы работало без ошибок
        рефакторинг — чтобы работало быстро
        тестирование после рефакторинга — чтобы работало быстро, правильно и без ошибок
        И я не гений, это придумал не я, так работают сотни тысяч разработчиков.

        Для меня нормально, когда вся система заработала верно и без ошибок, произвести рефакторинг элементов в которых я сделал те или иные допущения, или тех элементов которые были спроектированы не правильно изначально, годы назад.
        Т.е. результат, когда код узла стал занимать вместо 1000 строк — 300, стал работать на 15% быстрее, тесторование после рефакторинга прошло сразу. Рефакторинг длился 40 минут.
        Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка. Но отладка после успешного тестирования рецессивных багов заняла еще 20 минут.
        Мне не кажется, что на оптимизацию неэффективно потратить час рабочего времени. А зарание всего предусмотреть нет реальной возможности.
        • 0
          Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка.


          Вообще-то это от уровня профессионализма зависит. Есть люди, которые сами тестируют так, что отделу тестирования достается полностью работающий функционал. Просто таких очень мало, у большинства такое получается только иногда.
          • 0
            TDD — 2003 год
            BDD — 2009 год
            Проффесионализм? Это нужно просто брать и делать. Мы разработчики, <тут короткое матершинное слово>. Мы должны выкуривать современные тенденции, и радоваться? не когда мы их осваиваем, а когда их встраивают в код нашей любимой IDE, или когда появляется библиотека для нашего любимого фреймворка. Мы к этому моменту должны быть готовы, должны потеть ладони и дрожать коленки в предвкушении.
            сейчас 2012 год
            Сейчас не некоторые люди тестируют так, а даже джуниоры должны сначала писать тесты а потом писать код.
            Идеальный дзен TDD это когда тестирующий код легким движением руки превращается в программу, вот это уже от «уровня профессионализма».
            Отдел тестирования?
            Если модульное тестирование в автоматическом режиме длится может часами, на 16 ядрах, то сколько небоскребов должен занимать отдел тестирования?
            Отдел тестирования по идде должен писать сценарии, прототипы сценариев в том или ином виде должен предоставить заказчик в человекоподобном языке
            Отдел тестирования возможно должен проводить ручное тестирование, или разрабатывать сценарии для автоматического псевдоручного тестирования
            rubygems.org/gems/selenium-webdriver
            Скачан 2 милиона 300 тысяч раз, в разные проекты, даже если предположить что только 1/3 этих проектов доживает до стадии запуска девелоперского сервера, то таких систем более 700 тысяч.
            Т.о., идеологически, отдел тестирования поставляет сценарии BDD, а разработчики разрабатывают это в стиле TDD. Результаты BDD тестов можно в онлайне показывать заказчику как индикатор работоспособности системы и прогресса разработки.
            Можно к каждому BDD сценарию придумывать таски с часиками и выставлять счета для оплаты. Идеальный случай — заказчик знает за какой пиксель на экране он сколько заплатил.
        • 0
          Вообще-то рефакторинг не для того, чтобы работало быстро, а для того, чтобы код стал лучше.

          Я часто при рефакторинге делаю код чуть менее оптимальным, но легко читаемым. Естественно, если это не код «бутылочного горлышка», где допустимы хаки и логика «на тоненького».
      • –1
        Нет, по-моему я путаю всех, кто прочитал этот комментарий.

        Я говорил про архитектуру, но на хабре есть множество случаев, когда построение архитектуры называют преждевременной оптимизацией. Пример.
        • +1
          На хабре вообще есть множество случаев)
      • +1
        Что значит «неправильно спроектированную»? При выборе архитекуры программы можно взять один из многих вариантов. Все они правильные. Только вот, для каждого из них получается свое время на реализацию (может различаться в несколько раз) и свой предел скорости для результата последующей оптимизации (она тоже может различаться в несколько раз!) Если для данной задачи быстродействие (или другой параметр эффективности) является ключевым, то может быть смысл потратить пару недель на анализ и выбор правильной архитектуры — чтобы потом не тратить месяцы на переписывание всего с начала.
    • 0
      тут можно сказать о неявных допущениях, которые все делают, но не все контролируют
      преждевременная оптимизация — это допущение о том что данный кусок надо сделать быстрее и допущение что выбранный способ лучше.
      правильное проектирование — это прежде всего расчеты параметров и допустимых нагрузок, тоже своего рода допущение, но явное и имеющее возможности для проверки впоследствии

      Стоит говорить о best practice, но оптимизацию оставить на время, когда можно что-то померить. Собственно, самое важное правило оптимизации:
      >Обязательно проведите измерения до и после оптимизации.
    • 0
      Эффективность != быстродействие (что вы и подразумеваете под результатом оптимизации). Этот самый performance складывается из нескольких вещей (включая и быстродействие, конечно).
      • 0
        Быстродействие и потребление ресурсов? Я 5 раз перечитал свой коммент, и не увидел ничего похожего на «эффективность = быстродействие»
  • +5
    Теперь и книгу покупать не нужно.
    • –1
      Не то что покупать, а даже читать и тратить на это время!
  • +21
    Скажи «нет» религиозным войнам. Не вступай в них. Отойди в сторону.

    ЧТО?!

    Споры в общем и религиозные войны в частности — один из важнейших источников информации! Говоришь: «X sucks, потому что в нём нельзя сделать A, B и C». И получаешь подробную инструкцию, как в X сделать A, B и C десятью способами.

    Из-за того, что на Хабре реалигиозные войны практически невозможны, я чувствую себя не в своей тарелке. Никакого свободомыслия. Один раз выскажешь своё мнение — и уже пишешь из-под recovery mode.

    Макросы в С/С++ всегда выделяют прописными буквами, чтобы сделать хорошо заметными, и тщательно выбирают их имена, чтобы избежать конфликтов. Никогда не выделяйте прописными буквами другие объекты.

    WinApi шлёт вам пламенный привет.

    Пишите код, который может прочесть нормальный человек, причем без напряжения. Компилятор как-нибудь справится.

    Ну что за абсолютные постулаты… Вот так раз — и запретили ассемблерные вставки.

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

    Вот прям-таки — всех? Желаю успехов. Когда в вашем проекте будет 500 предупреждений, а половина кода — прикрывалками предупреждений, то вы подумаете по-другому.

    Ну, в общем, вода, вода, К.О., вода, постулат, К.О., вода, вода, вода, К.О., постулат… скучно.
    • 0
      Не просто вода, а вредные советы, как у Хармса.
      • +3
        Вредные советы были не у Хармса, а у Остера. Хотя может быть, и у Хармса тоже?
        • 0
          Похоже, что Вован что-то люто напутал :)
        • 0
          Может его совет вредный? :)
    • +7
      В проекте не будет 500 предупреждений, потому что они будут решаться с первого дня разработки, а не копиться.

      А вот вам с 500 игнорируемыми предупреждениями действительно удачи.
      • +2
        Ага, будут решаться. До первого «а-а-а, срочно нужен фикс клиенту! а-а-а!»

        У компиляторов, статических анализаторов и прочей нечисти весьма узкие взгляды на мир. Невозможно в крупном проекте удовлетворить все их запросы. Если включить абсолютно все предупреждения, то код будет испещрён затычками анализа ради затычек, а не ради качества.
        • 0
          А если еще смотреть на предупреждения IDE, то они иногда и вовсе некорректны в конкретном контексте… Мне лично IntelliJ IDEA для JDK 7 несколько раз предлагала делать неверные мелкие рефакторинги, меняющие семантику кода на неправильную…
          Осторожнее, люди, с автоматикой, надо в первую очередь голову иметь, чтобы проверить результаты работы этой автоматики. Чудес не бывает, ошибаются все, увы…
      • +2
        так с первого для и не было. а потом — внезапно — вышла новая версия компилятора…
    • +2
      Вот так раз — и запретили ассемблерные вставки.


      Кто их запретил? Вы же не виноваты, что читать ассемблерные вставки не учат в школе. Нормальный человек вообще никакую программу прочесть не сможет. А для программистов какие могут быть проблемы?
  • +1
    Спасибо, КЭП!
  • +2
    Пока читал книгу (оригинал, а не вырезки выше) в каждой следующей главе ждал чего-то нового, неизведанного, а на деле получались только прописные истины, где в каждом скользком вопросе (оформление фигурных скобок в коде, кол-во точек выходов из функции) автор отдавал право выбора читателю.

    п.с. Да и картинки с обезьянками в конце каждой главы доставляли…
    • +1
      А вы хотите, чтобы вам указали единственно верный способ расстановки скобок? Извините, такого нет.
    • 0
      Ну так он плавно подводил к тому, что не надо на скобках затыкаться, это не повод для остановки всей работы, нужно искать баланс, индивидуальных подход. На мой взгляд, эту книжку нужно читать параллельно с «Как пасти котов», они отлично дополняют друг друга.
      • 0
        Мне «Как пасти котов» не понравилась, после 150-й страницы перестал читать, то ли не дорос, то ли просто заскучал. P.S. не поверю, что в ней что-то про скобки есть ;)
    • 0
      Потому что нет в этих вопросах стопроцентной истины. Что более важно — единообразие кода. Поэтому если уж говорить о скобочках, то писать нужно так, как принято в вашем проекте.
  • 0
    У меня вопрос.

    Ко всем входным и выходным данным относитесь с подозрением, пока не проверите, что они допустимы.

    Есть у меня набор функций, принимающих на вход одинаковые или похожие параметры. Допустим, одна главная функция (public), много вспомогательных (private, вызываемых из главной). Всегда ли стоит ли во вспомогательных функциях проверять входные параметры, которые уже были проверены в главной функции? Часто параметр не один, соответственно код проверки может быть довольно большим (даже если надо просто проверить, например, много int на то, что они i >= -1). Можно конечно создать отдельную функцию проверки и везде ее вызывать, но ведь это не решит проблему огромного числа бесполезных проверок (особенно если вложенные функции вызываются где-нибудь в большом цикле).
    • 0
      Данное высказывание рассматривалось через призму защитного программирования, где каждую вашу функцию мог вызвать любой участник проекта из любого места.
    • +1
      можно ставить ассерты. при компиляции релиза они кода не дают, а при отладке помогают. хотя главная их польза с моей точки зрения — это форма документации. Читаешь код, видишь assert(i >= -1); ага, понятно, мол.
  • 0
    мы ремесленники!
    • 0
      Стремящиеся стать мастерами
      • 0
        А потом — гуру :-) Если доживем.
  • +2
    Выясните, к какому типу программистов вы относитесь.

    А какие типы есть? Огласите весь список, пожалуйста!
    • +2
      habrahabr.ru/post/88443/
      1) Новичок-энтузиаст
      2) Подающий надежды гений
      3) Поборник абстракции
      4) Ветеран
      5) Гуру
  • +4
    Нетерпеливый
    Кодер
    Гуру
    Псевдогуру
    Высокомерный гений
    Ковбой
    Плановик
    Ветеран
    Фанатик
    Монокультурный программист
    Лодырь
    Руководитель поневолец
    • –2
      пруф?
  • 0
    как-то сухо, скучно написано. Используйте то, это, делайте так, хотелось бы больше информации, а не указаний.
    • 0
      За информацией в книгу :).
      • +1
        Вы знаете, прочитав этот пост у меня не появилось желания купить книгу. Именно по тому, что всё выглядит сухо и что в книге всё выглядит именно так.
  • 0
    Глава 16. Кодеры

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

    А как это можно узнать? Я думал процесс выяснения долгий и понимание приходит со временем
    • 0
      Именно так. Просто в книге сперва описаны несколько типов, а потом говорится о том, как важно знать, к какому типу вы принадлежит и почему. Как резюме, дальше идет вот это «правило».
      • 0
        Ну тогда оно не совсем полное, а описание типов большое? Если большое, то можно просто перечислить для самостоятельного поиска?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.