Comments 62
Кто-нибудь дочитал?
Первое предложение из каждого абзаца.
Дочитал. Воды многовато, но в целом очень неплохо. За статью спасибо.
Дочитал. Хотя вторую половину — по диагонали.
а я прокрутил до коментов=)
Пост — да.
И даже несколько вещей взял на заметку в моем текущем контексте.
Книгу — нет, даже не брал в руки :-)
И даже несколько вещей взял на заметку в моем текущем контексте.
Книгу — нет, даже не брал в руки :-)
Добавил в избранное, завтра прочитаю. Или послезавтра.
А автор прочитал всю книгу!
по 2-3 строчки с каждого)
Я!)
Чуть не сдох, читал день.
Промотал, фоток не нашел — забил.
11. Об эффективности работы программы нужно думать с самого начала — не надейтесь, что в конце разработки вам удастся повысить ее ценой небольших изменений.
Ну наконец-то, голос разума снизошел с небес.
Вопреки распространенному мнению и неверной трактовке о нецелесообразности преждевременных оптимизаций, посмею всем напомнить, что ошибки сделанные в начале разработки имеют сложность в исправлении, которая может быть не меньше сложности разработки приложения с нуля.
Ну наконец-то, голос разума снизошел с небес.
Вопреки распространенному мнению и неверной трактовке о нецелесообразности преждевременных оптимизаций, посмею всем напомнить, что ошибки сделанные в начале разработки имеют сложность в исправлении, которая может быть не меньше сложности разработки приложения с нуля.
По-моему, вы путаете оптимизацию и проектирование. Оптимизировать неправильно спроектированную систему постфактум — сложно/нереально. Оптимизировать систему на этапе разработки не менее сложно (читайте «непродуктивно»).
Система, и общий сценарий в которых работаю я:
разработка -> тестирование -> рефакторинг -> тестирование -> релиз
разработка — чтобы работало
тесторование — чтобы работало без ошибок
рефакторинг — чтобы работало быстро
тестирование после рефакторинга — чтобы работало быстро, правильно и без ошибок
И я не гений, это придумал не я, так работают сотни тысяч разработчиков.
Для меня нормально, когда вся система заработала верно и без ошибок, произвести рефакторинг элементов в которых я сделал те или иные допущения, или тех элементов которые были спроектированы не правильно изначально, годы назад.
Т.е. результат, когда код узла стал занимать вместо 1000 строк — 300, стал работать на 15% быстрее, тесторование после рефакторинга прошло сразу. Рефакторинг длился 40 минут.
Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка. Но отладка после успешного тестирования рецессивных багов заняла еще 20 минут.
Мне не кажется, что на оптимизацию неэффективно потратить час рабочего времени. А зарание всего предусмотреть нет реальной возможности.
разработка -> тестирование -> рефакторинг -> тестирование -> релиз
разработка — чтобы работало
тесторование — чтобы работало без ошибок
рефакторинг — чтобы работало быстро
тестирование после рефакторинга — чтобы работало быстро, правильно и без ошибок
И я не гений, это придумал не я, так работают сотни тысяч разработчиков.
Для меня нормально, когда вся система заработала верно и без ошибок, произвести рефакторинг элементов в которых я сделал те или иные допущения, или тех элементов которые были спроектированы не правильно изначально, годы назад.
Т.е. результат, когда код узла стал занимать вместо 1000 строк — 300, стал работать на 15% быстрее, тесторование после рефакторинга прошло сразу. Рефакторинг длился 40 минут.
Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка. Но отладка после успешного тестирования рецессивных багов заняла еще 20 минут.
Мне не кажется, что на оптимизацию неэффективно потратить час рабочего времени. А зарание всего предусмотреть нет реальной возможности.
Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка.
Вообще-то это от уровня профессионализма зависит. Есть люди, которые сами тестируют так, что отделу тестирования достается полностью работающий функционал. Просто таких очень мало, у большинства такое получается только иногда.
TDD — 2003 год
BDD — 2009 год
Проффесионализм? Это нужно просто брать и делать. Мы разработчики, <тут короткое матершинное слово>. Мы должны выкуривать современные тенденции, и радоваться? не когда мы их осваиваем, а когда их встраивают в код нашей любимой IDE, или когда появляется библиотека для нашего любимого фреймворка. Мы к этому моменту должны быть готовы, должны потеть ладони и дрожать коленки в предвкушении.
сейчас 2012 год
Сейчас не некоторые люди тестируют так, а даже джуниоры должны сначала писать тесты а потом писать код.
Идеальный дзен TDD это когда тестирующий код легким движением руки превращается в программу, вот это уже от «уровня профессионализма».
Отдел тестирования?
Если модульное тестирование в автоматическом режиме длится может часами, на 16 ядрах, то сколько небоскребов должен занимать отдел тестирования?
Отдел тестирования по идде должен писать сценарии, прототипы сценариев в том или ином виде должен предоставить заказчик в человекоподобном языке
Отдел тестирования возможно должен проводить ручное тестирование, или разрабатывать сценарии для автоматического псевдоручного тестирования
rubygems.org/gems/selenium-webdriver
Скачан 2 милиона 300 тысяч раз, в разные проекты, даже если предположить что только 1/3 этих проектов доживает до стадии запуска девелоперского сервера, то таких систем более 700 тысяч.
Т.о., идеологически, отдел тестирования поставляет сценарии BDD, а разработчики разрабатывают это в стиле TDD. Результаты BDD тестов можно в онлайне показывать заказчику как индикатор работоспособности системы и прогресса разработки.
Можно к каждому BDD сценарию придумывать таски с часиками и выставлять счета для оплаты. Идеальный случай — заказчик знает за какой пиксель на экране он сколько заплатил.
BDD — 2009 год
Проффесионализм? Это нужно просто брать и делать. Мы разработчики, <тут короткое матершинное слово>. Мы должны выкуривать современные тенденции, и радоваться? не когда мы их осваиваем, а когда их встраивают в код нашей любимой IDE, или когда появляется библиотека для нашего любимого фреймворка. Мы к этому моменту должны быть готовы, должны потеть ладони и дрожать коленки в предвкушении.
сейчас 2012 год
Сейчас не некоторые люди тестируют так, а даже джуниоры должны сначала писать тесты а потом писать код.
Идеальный дзен TDD это когда тестирующий код легким движением руки превращается в программу, вот это уже от «уровня профессионализма».
Отдел тестирования?
Если модульное тестирование в автоматическом режиме длится может часами, на 16 ядрах, то сколько небоскребов должен занимать отдел тестирования?
Отдел тестирования по идде должен писать сценарии, прототипы сценариев в том или ином виде должен предоставить заказчик в человекоподобном языке
Отдел тестирования возможно должен проводить ручное тестирование, или разрабатывать сценарии для автоматического псевдоручного тестирования
rubygems.org/gems/selenium-webdriver
Скачан 2 милиона 300 тысяч раз, в разные проекты, даже если предположить что только 1/3 этих проектов доживает до стадии запуска девелоперского сервера, то таких систем более 700 тысяч.
Т.о., идеологически, отдел тестирования поставляет сценарии BDD, а разработчики разрабатывают это в стиле TDD. Результаты BDD тестов можно в онлайне показывать заказчику как индикатор работоспособности системы и прогресса разработки.
Можно к каждому BDD сценарию придумывать таски с часиками и выставлять счета для оплаты. Идеальный случай — заказчик знает за какой пиксель на экране он сколько заплатил.
Вообще-то рефакторинг не для того, чтобы работало быстро, а для того, чтобы код стал лучше.
Я часто при рефакторинге делаю код чуть менее оптимальным, но легко читаемым. Естественно, если это не код «бутылочного горлышка», где допустимы хаки и логика «на тоненького».
Я часто при рефакторинге делаю код чуть менее оптимальным, но легко читаемым. Естественно, если это не код «бутылочного горлышка», где допустимы хаки и логика «на тоненького».
Нет, по-моему я путаю всех, кто прочитал этот комментарий.
Я говорил про архитектуру, но на хабре есть множество случаев, когда построение архитектуры называют преждевременной оптимизацией. Пример.
Я говорил про архитектуру, но на хабре есть множество случаев, когда построение архитектуры называют преждевременной оптимизацией. Пример.
Что значит «неправильно спроектированную»? При выборе архитекуры программы можно взять один из многих вариантов. Все они правильные. Только вот, для каждого из них получается свое время на реализацию (может различаться в несколько раз) и свой предел скорости для результата последующей оптимизации (она тоже может различаться в несколько раз!) Если для данной задачи быстродействие (или другой параметр эффективности) является ключевым, то может быть смысл потратить пару недель на анализ и выбор правильной архитектуры — чтобы потом не тратить месяцы на переписывание всего с начала.
тут можно сказать о неявных допущениях, которые все делают, но не все контролируют
преждевременная оптимизация — это допущение о том что данный кусок надо сделать быстрее и допущение что выбранный способ лучше.
правильное проектирование — это прежде всего расчеты параметров и допустимых нагрузок, тоже своего рода допущение, но явное и имеющее возможности для проверки впоследствии
Стоит говорить о best practice, но оптимизацию оставить на время, когда можно что-то померить. Собственно, самое важное правило оптимизации:
>Обязательно проведите измерения до и после оптимизации.
преждевременная оптимизация — это допущение о том что данный кусок надо сделать быстрее и допущение что выбранный способ лучше.
правильное проектирование — это прежде всего расчеты параметров и допустимых нагрузок, тоже своего рода допущение, но явное и имеющее возможности для проверки впоследствии
Стоит говорить о best practice, но оптимизацию оставить на время, когда можно что-то померить. Собственно, самое важное правило оптимизации:
>Обязательно проведите измерения до и после оптимизации.
Эффективность != быстродействие (что вы и подразумеваете под результатом оптимизации). Этот самый performance складывается из нескольких вещей (включая и быстродействие, конечно).
Теперь и книгу покупать не нужно.
Скажи «нет» религиозным войнам. Не вступай в них. Отойди в сторону.
ЧТО?!
Споры в общем и религиозные войны в частности — один из важнейших источников информации! Говоришь: «X sucks, потому что в нём нельзя сделать A, B и C». И получаешь подробную инструкцию, как в X сделать A, B и C десятью способами.
Из-за того, что на Хабре реалигиозные войны практически невозможны, я чувствую себя не в своей тарелке. Никакого свободомыслия. Один раз выскажешь своё мнение — и уже пишешь из-под recovery mode.
Макросы в С/С++ всегда выделяют прописными буквами, чтобы сделать хорошо заметными, и тщательно выбирают их имена, чтобы избежать конфликтов. Никогда не выделяйте прописными буквами другие объекты.
WinApi шлёт вам пламенный привет.
Пишите код, который может прочесть нормальный человек, причем без напряжения. Компилятор как-нибудь справится.
Ну что за абсолютные постулаты… Вот так раз — и запретили ассемблерные вставки.
Компилируйте код при включенном выводе компилятором всех предупредительных сообщений. Тем самым вы обнаружите потенциальные проблемы раньше, чем столкнетесь с ними реально.
Вот прям-таки — всех? Желаю успехов. Когда в вашем проекте будет 500 предупреждений, а половина кода — прикрывалками предупреждений, то вы подумаете по-другому.
Ну, в общем, вода, вода, К.О., вода, постулат, К.О., вода, вода, вода, К.О., постулат… скучно.
Не просто вода, а вредные советы, как у Хармса.
В проекте не будет 500 предупреждений, потому что они будут решаться с первого дня разработки, а не копиться.
А вот вам с 500 игнорируемыми предупреждениями действительно удачи.
А вот вам с 500 игнорируемыми предупреждениями действительно удачи.
Ага, будут решаться. До первого «а-а-а, срочно нужен фикс клиенту! а-а-а!»
У компиляторов, статических анализаторов и прочей нечисти весьма узкие взгляды на мир. Невозможно в крупном проекте удовлетворить все их запросы. Если включить абсолютно все предупреждения, то код будет испещрён затычками анализа ради затычек, а не ради качества.
У компиляторов, статических анализаторов и прочей нечисти весьма узкие взгляды на мир. Невозможно в крупном проекте удовлетворить все их запросы. Если включить абсолютно все предупреждения, то код будет испещрён затычками анализа ради затычек, а не ради качества.
А если еще смотреть на предупреждения IDE, то они иногда и вовсе некорректны в конкретном контексте… Мне лично IntelliJ IDEA для JDK 7 несколько раз предлагала делать неверные мелкие рефакторинги, меняющие семантику кода на неправильную…
Осторожнее, люди, с автоматикой, надо в первую очередь голову иметь, чтобы проверить результаты работы этой автоматики. Чудес не бывает, ошибаются все, увы…
Осторожнее, люди, с автоматикой, надо в первую очередь голову иметь, чтобы проверить результаты работы этой автоматики. Чудес не бывает, ошибаются все, увы…
так с первого для и не было. а потом — внезапно — вышла новая версия компилятора…
Вот так раз — и запретили ассемблерные вставки.
Кто их запретил? Вы же не виноваты, что читать ассемблерные вставки не учат в школе. Нормальный человек вообще никакую программу прочесть не сможет. А для программистов какие могут быть проблемы?
Спасибо, КЭП!
Пока читал книгу (оригинал, а не вырезки выше) в каждой следующей главе ждал чего-то нового, неизведанного, а на деле получались только прописные истины, где в каждом скользком вопросе (оформление фигурных скобок в коде, кол-во точек выходов из функции) автор отдавал право выбора читателю.
п.с. Да и картинки с обезьянками в конце каждой главы доставляли…
п.с. Да и картинки с обезьянками в конце каждой главы доставляли…
А вы хотите, чтобы вам указали единственно верный способ расстановки скобок? Извините, такого нет.
Ну так он плавно подводил к тому, что не надо на скобках затыкаться, это не повод для остановки всей работы, нужно искать баланс, индивидуальных подход. На мой взгляд, эту книжку нужно читать параллельно с «Как пасти котов», они отлично дополняют друг друга.
Потому что нет в этих вопросах стопроцентной истины. Что более важно — единообразие кода. Поэтому если уж говорить о скобочках, то писать нужно так, как принято в вашем проекте.
У меня вопрос.
Есть у меня набор функций, принимающих на вход одинаковые или похожие параметры. Допустим, одна главная функция (public), много вспомогательных (private, вызываемых из главной). Всегда ли стоит ли во вспомогательных функциях проверять входные параметры, которые уже были проверены в главной функции? Часто параметр не один, соответственно код проверки может быть довольно большим (даже если надо просто проверить, например, много int на то, что они i >= -1). Можно конечно создать отдельную функцию проверки и везде ее вызывать, но ведь это не решит проблему огромного числа бесполезных проверок (особенно если вложенные функции вызываются где-нибудь в большом цикле).
Ко всем входным и выходным данным относитесь с подозрением, пока не проверите, что они допустимы.
Есть у меня набор функций, принимающих на вход одинаковые или похожие параметры. Допустим, одна главная функция (public), много вспомогательных (private, вызываемых из главной). Всегда ли стоит ли во вспомогательных функциях проверять входные параметры, которые уже были проверены в главной функции? Часто параметр не один, соответственно код проверки может быть довольно большим (даже если надо просто проверить, например, много int на то, что они i >= -1). Можно конечно создать отдельную функцию проверки и везде ее вызывать, но ведь это не решит проблему огромного числа бесполезных проверок (особенно если вложенные функции вызываются где-нибудь в большом цикле).
Данное высказывание рассматривалось через призму защитного программирования, где каждую вашу функцию мог вызвать любой участник проекта из любого места.
можно ставить ассерты. при компиляции релиза они кода не дают, а при отладке помогают. хотя главная их польза с моей точки зрения — это форма документации. Читаешь код, видишь assert(i >= -1); ага, понятно, мол.
мы ремесленники!
Выясните, к какому типу программистов вы относитесь.
А какие типы есть? Огласите весь список, пожалуйста!
habrahabr.ru/post/88443/
1) Новичок-энтузиаст
2) Подающий надежды гений
3) Поборник абстракции
4) Ветеран
5) Гуру
1) Новичок-энтузиаст
2) Подающий надежды гений
3) Поборник абстракции
4) Ветеран
5) Гуру
Нетерпеливый
Кодер
Гуру
Псевдогуру
Высокомерный гений
Ковбой
Плановик
Ветеран
Фанатик
Монокультурный программист
Лодырь
Руководитель поневолец
Кодер
Гуру
Псевдогуру
Высокомерный гений
Ковбой
Плановик
Ветеран
Фанатик
Монокультурный программист
Лодырь
Руководитель поневолец
как-то сухо, скучно написано. Используйте то, это, делайте так, хотелось бы больше информации, а не указаний.
Глава 16. Кодеры
Выясните, к какому типу программистов вы относитесь. Определите, как можно выгодно использовать свои хорошие качества и компенсировать плохие.
А как это можно узнать? Я думал процесс выяснения долгий и понимание приходит со временем
Именно так. Просто в книге сперва описаны несколько типов, а потом говорится о том, как важно знать, к какому типу вы принадлежит и почему. Как резюме, дальше идет вот это «правило».
Sign up to leave a comment.
Ремесло программиста. Золотые правила