Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
Ох, эта 8 ловушка! Спасибо за статью, будем выбираться из ям.
Использование в похожих по синтаксису языках (например Java и C)
одного стиля отступов и метода наименования сущностей
А тут что плохого? Если компилятору это не мешает, то это чисто вопрос личных привычек и предпочтений.
Я бы еще дополнил это простым примечанием и пожеланием для разработчиков современных IDE. Я считаю, что форматирование может быть выполнено IDE так, как нравится конкретному человеку. Лично я категорически против определенных стилей форматирования и у меня свои заморочки. И так у каждого. Код, в конце концов может быть обработан в соотвествии с правилами настроенными по вкусу разработчика. Благо, уже сейчас есть IDE, которые неплохо с этим справляются и даже умеют автоматически форматировать код перед отправкой в VCS.
А по поводу статьи — все, как говорится, хорошо в меру. Именно поэтому в команды программистов стараются набирать людей с определенными склонностями. И разнообразие может приводить как к плачевным, так и к великолепным результатам. Тут уже все зависит от лида или менеджера проекта. Кроме того, немаловажно значение амбиций и пристрастий, да и с возрастом понимаешь, что все люди разные, что каждый по-своему на все смотрит. Учишься уважать мнение других людей, учитывать чужие и свои ошибки. Главное, не быть заложником своих идей, быть открытым всему новому и способным изменить (не предать!) свою точку зрения.
А по поводу статьи — все, как говорится, хорошо в меру. Именно поэтому в команды программистов стараются набирать людей с определенными склонностями. И разнообразие может приводить как к плачевным, так и к великолепным результатам. Тут уже все зависит от лида или менеджера проекта. Кроме того, немаловажно значение амбиций и пристрастий, да и с возрастом понимаешь, что все люди разные, что каждый по-своему на все смотрит. Учишься уважать мнение других людей, учитывать чужие и свои ошибки. Главное, не быть заложником своих идей, быть открытым всему новому и способным изменить (не предать!) свою точку зрения.
>>пожеланием для разработчиков современных IDE
Я у себя в NetBeans настраиваю так как удобно мне. Т.е. меняю дефолтовое форматирование
Я у себя в NetBeans настраиваю так как удобно мне. Т.е. меняю дефолтовое форматирование
Во всех крупных компаниях стиль форматирования — как футбольная форма. Единый для всей команды. И это правильно. Любители индивидуальных отступов либо переучиваются, либо их увольняют.
Это — показатель того, что вы, возможно, в ловушке золотого молотка. Не факт, просто повод задуматься.
Компилятору не мешает — очень плохой аргумент. Компилятору не мешает код в одну строку (если это не строчно-ориентированный язык), не мешают имена переменных в одну букву, не мешает отсутствие (или огромное количество) комментариев.
Код-стайл — он для людей, а не для компиляторов.
Если вы применяете один и тот-же код-стайл в нескольких разных языках — возможно этот код-стайл для вас — золотой молоток. (подчеркиваю — возможно)
Компилятору не мешает — очень плохой аргумент. Компилятору не мешает код в одну строку (если это не строчно-ориентированный язык), не мешают имена переменных в одну букву, не мешает отсутствие (или огромное количество) комментариев.
Код-стайл — он для людей, а не для компиляторов.
Если вы применяете один и тот-же код-стайл в нескольких разных языках — возможно этот код-стайл для вас — золотой молоток. (подчеркиваю — возможно)
Я считаю, что необходимо появление психологов, специализирующихся на программистах и их «болезнях». Потому что от некоторым самостоятельно исцелиться крайне сложно.
Соответственно при устройстве в крупную фирму, бесплатный абонемент к такому специалисту, входящий в «соц. пакет», может быть серьёзным подспорьем в выборе фирмы. Работодатели, ау!
Соответственно при устройстве в крупную фирму, бесплатный абонемент к такому специалисту, входящий в «соц. пакет», может быть серьёзным подспорьем в выборе фирмы. Работодатели, ау!
Тестами покрывается абсолютно весь код, включая сторонние библиотеки
Особое внимание при проверках уделяйте пользовательскому вводу и внешним ресурсам
Я бы как раз особое внимание выделила тестам сторонних библиотек и сервисов, особенно если они обновляются.
Вы, возможно в ловушке защитного программирования.
А может и нет. Признаки того, что вы в ловушке созданы для того, чтобы подумать, не доходите ли вы до крайности. Если нет — все хорошо, независимо от того, тестируете ли вы встроенную функцию max или нет.
А может и нет. Признаки того, что вы в ловушке созданы для того, чтобы подумать, не доходите ли вы до крайности. Если нет — все хорошо, независимо от того, тестируете ли вы встроенную функцию max или нет.
А мне кажется, что вы в ловушке пытаетесь каждого определить в какую-нибудь ловушку из вашей системы.
А ещё вы попали в ловушку выканья в вашем тексте 88 (восемьдесят восемь) раз встречается слово «вы», по шесть раз слова «вам» и «вас», а также четыре раза слово «ваш». А текст-то небольшой.
Вы не подумайте, ваш пост имеет рациональное ядро, и его смысл мне понравился и показался полезным, но от такого количества (больше ста!) словоформ личного местоимения второго лица множественного числа у меня при прочтении текста аж язык сковало.
Вы не подумайте, ваш пост имеет рациональное ядро, и его смысл мне понравился и показался полезным, но от такого количества (больше ста!) словоформ личного местоимения второго лица множественного числа у меня при прочтении текста аж язык сковало.
Обычно, выпуская что-то в продакшн, версии сторонних библиотек морозят намертво. Поэтому написание тестов — лишняя трата времени, лучше уж сразу использовать те библиотеки, которые изначально покрыты тестами их авторами.
Кстати, к перечисленным в статье когнитивным искажениям можно добавить еще пару противоположных друг другу:
1. Беззаветное доверие любому «чужому» коду (обычно свойственно наивным новичкам, которые считают, что библиотеки пишут «умные дяди», которые никогда не ошибаются). Крушение надежд обычно очень болезненно и иногда приводит даже к провалу проекта (если приходится сидеть в отладке чужого, непонятного кода, вместо того, чтобы писать свой.
2. Хроническое недоверие ко всем сторонним решениям — часто приводит к проблеме «велосипедов». В лучшем случае человек обкладывает чужой код кучей тестов, в худшем рассуждает так: нафиг эти чужие глючные вещи, напишу своё. Простое, работающее, годящееся в моей задаче.
1. Беззаветное доверие любому «чужому» коду (обычно свойственно наивным новичкам, которые считают, что библиотеки пишут «умные дяди», которые никогда не ошибаются). Крушение надежд обычно очень болезненно и иногда приводит даже к провалу проекта (если приходится сидеть в отладке чужого, непонятного кода, вместо того, чтобы писать свой.
2. Хроническое недоверие ко всем сторонним решениям — часто приводит к проблеме «велосипедов». В лучшем случае человек обкладывает чужой код кучей тестов, в худшем рассуждает так: нафиг эти чужие глючные вещи, напишу своё. Простое, работающее, годящееся в моей задаче.
Нагромоздить 20 классов, использовать 12 разных паттернов, реализовать свой DSL для парсинга другого DSL, создать кроссплатформенный фреймворк для визуализации циклических графов для создания очередного тетриса — это про “поборников абстракции”.
Однако именно из такого (или примерно такого) подхода рождаются фреймворки, новые языки, новые СУБД и т.д. Не стоит забывать, что для многих программирование это не только кратчайшее решение поставленной задачи по ТЗ, но и творчество и научные изыскания в процессе.
Безусловно, существует вероятность, что при таком подходе программист создаст новую крутую библиотеку, которая сэкономит сотни тысяч человеко-часов для всего мира. Но вероятность того, что такая библиотека уже есть, а из вновь написанной будет использоваться в текущем проекте не больше 10%, намного выше. В словах автора главное, я думаю, «для создания очередного тетриса». То есть, если задача тривиальна, надо ее просто решать наиболее быстрым способом. Писать фреймворки стоит в тех случаях, когда существующие решения объективно не очень хороши.
Больше библииотек и языков — хорошо. Естественный отбор может работать только на дастаточно больших популяуиях.
Проблемы не в количестве библиотек, а в сложности их инвентаризации. Если бы большенство библиотек были бы описаны в системах, подобных Hoogle, Scalex, Clojure Atlas, «слздавать тертисы» было бы приятнее и интереснее.
Проблемы не в количестве библиотек, а в сложности их инвентаризации. Если бы большенство библиотек были бы описаны в системах, подобных Hoogle, Scalex, Clojure Atlas, «слздавать тертисы» было бы приятнее и интереснее.
Что хочется добавить:
Дело в том, что порой нужно написать велосипед, чтобы понять, «как всё работает». Думаю, не секрет, что копание в чужом коде и написание своего — совершенно разные по фану вещи. Это как с играми — через них всё познаётся проще и порой быстрее.
Тут, создавая свой велосипед, натыкаешься на проблемы, о которых возможно даже и не задумаешься, используя сторонний продукт.
Т.е., подводя итог, если относиться к созданию велосипеда как к игре, то в этом нет ничего плохого. Главное, не заиграться.
Дело в том, что порой нужно написать велосипед, чтобы понять, «как всё работает». Думаю, не секрет, что копание в чужом коде и написание своего — совершенно разные по фану вещи. Это как с играми — через них всё познаётся проще и порой быстрее.
Тут, создавая свой велосипед, натыкаешься на проблемы, о которых возможно даже и не задумаешься, используя сторонний продукт.
Т.е., подводя итог, если относиться к созданию велосипеда как к игре, то в этом нет ничего плохого. Главное, не заиграться.
(далее следует юмор, о автор и читатели)
Ловушка номер 9: самопрограмирование
Постоянное самокопание, анализ причин своей непродуктивности, чтение литературы о селф-менеджменте, ноотропы, медитация, расписание, спорт.
Признаки того что вы в ловушке: вы пишете статьи о повышении своей эффективности как програмиста.
Выход: писать код
Или как один писатель, чтобы каждый раз как он ловил себя на мысли, что говорит или думает что-то умное, хотел чтобы это сразу ложилось в книгу, и повесил на стеле плакатик с двумя словами «НА БУМАГУ»
Ловушка номер 9: самопрограмирование
Постоянное самокопание, анализ причин своей непродуктивности, чтение литературы о селф-менеджменте, ноотропы, медитация, расписание, спорт.
Признаки того что вы в ловушке: вы пишете статьи о повышении своей эффективности как програмиста.
Выход: писать код
Или как один писатель, чтобы каждый раз как он ловил себя на мысли, что говорит или думает что-то умное, хотел чтобы это сразу ложилось в книгу, и повесил на стеле плакатик с двумя словами «НА БУМАГУ»
Забыли про обратную сторону: самоуверенность — нежелание как-либо анализировать свою работу, вера в свою непогрешимость
Признаки того, что вы в ловушке: вы не анализируете себя, не считаетесь ни с чьим мнением и не узнаёте новые методологии, коротко — не развиваетесь
Выход: анализировать результаты своей работы, хотя бы после того, как они готовы.
Как-то так.
Признаки того, что вы в ловушке: вы не анализируете себя, не считаетесь ни с чьим мнением и не узнаёте новые методологии, коротко — не развиваетесь
Выход: анализировать результаты своей работы, хотя бы после того, как они готовы.
Как-то так.
Я бы оба пункта добавил. Лично не раз видел людей, которые говорят о повышении своей эффективности, а на деле просто вместо написания кода смотрят видео на ютьюбе. Или же да, наоборот, но с правилом «Мой код не может работать неправильно. Если он работает неправильно, проверь руки».
А в общем, суть всех этих правил — не нужно доходить до фанатизма.
А в общем, суть всех этих правил — не нужно доходить до фанатизма.
По-секрету (только тссс!) скажу, что в черновом варианте статьи была ловушка №9 — гордость.
избегание ловушек — это ходьба узкой дорожке, где слева — проблемы, а справа — пути их решения, доведенные до абсурда.
отлично сказано! можно я это где-то запишу и буду цитировать?
Я как то вырабатывал критерий, когда нужно что-то рефакторить. Вышло так
1. Код не срабатывает
2. Код используется активнее, чем ожидалось (т.е. проблемы производительности очевидны)
3. Количество запросов на изменение кода больше чем ожидалось (т.е. проблемы поддержки кода очевидны)
4. Кодом нужно поделиться с большим числом разработчиков чем планировалось (т.е. проблемы читаемости кода очевидны)
Строго в этом порядке. Заодно был получен и критерий, когда нужно что-то перепроектировать
1. Код взаимодействует с большим количеством другого кода, чем ожидалось (то есть архитектура системы строилась на очевидно более простых требованиях)
2. Откладывается реализация большего количество требований, чем ожидалось (то есть гибкость решения очевидно меньше необходимой)
1. Код не срабатывает
2. Код используется активнее, чем ожидалось (т.е. проблемы производительности очевидны)
3. Количество запросов на изменение кода больше чем ожидалось (т.е. проблемы поддержки кода очевидны)
4. Кодом нужно поделиться с большим числом разработчиков чем планировалось (т.е. проблемы читаемости кода очевидны)
Строго в этом порядке. Заодно был получен и критерий, когда нужно что-то перепроектировать
1. Код взаимодействует с большим количеством другого кода, чем ожидалось (то есть архитектура системы строилась на очевидно более простых требованиях)
2. Откладывается реализация большего количество требований, чем ожидалось (то есть гибкость решения очевидно меньше необходимой)
Могу предложить Вам еще один критерий, когда поможет рефакторинг — когда вы возвращаетесь к исходному коду с целью добавить новый функционал или исправить существующий спустя некоторое время и сталкиваетесь с непониманием механизмов его работы, даже если этот код — ваш.
Одна-две итерации рефакторинга помогут намного глубже понять и восстановить в памяти суть работы класса, чем простое чтение исходного текста. А заодно в код вносятся изменения для самой цели рефакторинга — облегчить понимание на будущее.
Одна-две итерации рефакторинга помогут намного глубже понять и восстановить в памяти суть работы класса, чем простое чтение исходного текста. А заодно в код вносятся изменения для самой цели рефакторинга — облегчить понимание на будущее.
О, спасибо, потом почитаю.
Или обобщённо — избегайте любых крайностей. Если хотите работать эффективно.
Но если хотите стать великим программистом (или сойти с ума) то доходите в своей крайности до исступления, до истерики.
Однажды к великому учителю дао программирования пришёл ученик и спросил его — Что мне делать, учитель? Я достиг просветления и не попадаю ни в одну из восьми ловушек программирования. Учитель молча допил свою третью чашку кофе, потом взял старый системный блок и со всей силы ударил им ученика по спине. А потом сказал — Так пойди и придумай девятую ловушку!
Но если хотите стать великим программистом (или сойти с ума) то доходите в своей крайности до исступления, до истерики.
Однажды к великому учителю дао программирования пришёл ученик и спросил его — Что мне делать, учитель? Я достиг просветления и не попадаю ни в одну из восьми ловушек программирования. Учитель молча допил свою третью чашку кофе, потом взял старый системный блок и со всей силы ударил им ученика по спине. А потом сказал — Так пойди и придумай девятую ловушку!
Спасибо! Хорошая статья.
Как по мне так не хватает еще одной ловушки — попытка усидеть на ВСЕХ стульях сразу. Когда стараешься контролировать и проверять абсолютно все, переписываешь пусть работающие но написанные не тобой куски кода, злобная защита своих тактик и стратегий даже в ущерб движению проекта вперед.
Как по мне так не хватает еще одной ловушки — попытка усидеть на ВСЕХ стульях сразу. Когда стараешься контролировать и проверять абсолютно все, переписываешь пусть работающие но написанные не тобой куски кода, злобная защита своих тактик и стратегий даже в ущерб движению проекта вперед.
> переписываешь пусть работающие но написанные не тобой куски кода, злобная защита своих тактик и стратегий даже в ущерб движению проекта вперед.
Для этого даже придумали название — «Фатальный недостаток» или синдром «Изобретено не здесь» («Not Invented Here», «NIH»): lurkmore.to/_/18209#mws_YKMWJf/
Золотой молоток — это вредная привычка. После того, каккакой-либо метод сработал при решении нескольких задач, попавшийся в ловушку начинает использовать этот метод везде, где только можно!
Есть несколько схожих терминов — панацея, волшебная таблетка, серебряная пуля,т. е. такой метод, который всегда,в 100% случаев выполняет любую задачу. Ещё одна имеющая к этой теме поговорка — забивать гвозди микроскопом.
Золотой молоток — довольно часто встречающаяся, но совершенно непохожая на другие ловушка. Золотым молотком может быть всё что угодно,кто-то может влюбиться в ООП и писать классы на каждый чих,кто-то в паттерны проектирования и построить программу из одних лишь фабрик и синглтонов.
Для кого-то золотой молоток — это любимый язык программирования,для кого-то — любимая парадигма,для кого-то — методология разработки.
Главное, что выделяет золотой молоток — попытка использовать его всегда и везде.
Признаки того, что вы в ловушке• Использование одного языка программирования для всех задач
• Вера в то, что одна парадигма может решить все проблемы программирования (чаще всего так говорят про ООП и ФП)
• Использование для всех проектов, независимо от условий, одной методологии разработки, например бездумное использование TDD во всех проектах
• Применение какого-либо средства, предоставляемого языком для большей части задач, например:
– Передача всех аргументов только по константной ссылке
– Использование во всей программе лишь одного типа коллекций, скажем массивов (векторов)
– Использование повсюду немутабельных объектов
– Использование в похожих по синтаксису языках (например Java и C) одного стиля отступов и метода наименования сущностей
Серебряной пули не существует
Я боюсь, что эта ловушка — исключение из правил и возможно ее избежать не рискуя попасть в другую.
Это исключение из замеченной мною закономерности еще раз доказывает, что золотого молотка не существует — мой метод описания ловушки как двойственной сущности дал осечку, но я не боюсь отказаться от его использования.
Это и есть правильный путь освобождения из этой ловушки.
А по-моему, Вам просто изменила фантазия. У верующего в золотой молоток есть своя противоположность — это такой программист, который искренне верит, что для решения очередной задачи ему не достаточно просто подыскать готовую библиотеку на привычном языке программирования (а если готовой нет, то доработать одну из существующих или сочинить собственную), а обязательно придётся также:
- использовать другой язык программирования (лучше всего — не известный ему ещё позавчера);
- отказаться
от какой-нибудь хорошо работающей парадигмы — например, отказаться от ФП, а вместо ФП самостоятельно от руки записывать все циклы для обхода массивов с целью изменения (или фильтрации, или поиска, или аккумуляции) элементов в них;
- покрывать свой код тестами невчерашним способом — например, вместо BDD попробовать обычную TDD;
- вместе с языком (даже если в нём нет значащих пробелов, как в CoffeeScript
каком-нибудь) непременно сменить и свой стиль отступов — например, начать ставить пять пробелов вместо четырёх или добавлять по пробелу до и после каждой скобки;
- сменить IDE, VPN, операционную систему, страну проживания, вероисповедание, ориентацию.
Для себя и для проекта такой программист неудобен тем, что сам себе усложняет задачу.
На Хабрахабре такой программист неудобен тем, что кидается на людей, которые на языке X решают задачу Y вместо того, чтобы перейти на язык Z, который по мнению этого программиста является наиболее удобным (в ещё более тяжёлых случаях — единственно возможным) для решения задачи Y.
У вас слишком длинный комментарий, написанный на неудобном языке. Комментарии всегда должны быть короткими и на английском. Кто вообще использует списки в комментариях? Это же признак непрофессионализма!
Вы срочно должны перейти на английский язык и писать комментарии только на нём. И только краткие!
Вы срочно должны перейти на английский язык и писать комментарии только на нём. И только краткие!
Тоже сразу возникло возражение. Противоположность золотому молотку, это попытка взять два инструмента в одну руку.
Видел случаи, когда в одном проекте часть моделей описана классами, другая часть загружается из XML без явной на то причины, а просто «я так могу», когда половина проекта общается с базой через NHibernate, другая через Linq2Sql, ну и так далее.
Видел случаи, когда в одном проекте часть моделей описана классами, другая часть загружается из XML без явной на то причины, а просто «я так могу», когда половина проекта общается с базой через NHibernate, другая через Linq2Sql, ну и так далее.
Это Сцилла и Харибда в программировании. Либо мы уходим в одну крайность, либо в другую. Труднее всего — придерживаться золотой середины. А не держаться за золотой молоток.
В итоге всё, так или иначе, сводится к замечательной польской поговорке:
Со za nadto, to nezdrowo — Что чересчур, то не идёт на пользу
По-моему, «Золотой молоток» aka «Серебряная пуля» в списке лишний. Точнее, весь список можно свести к Золотому молотку.
Жаль только, что эта машина — не Hammer, а Hummer.
И наоборот — некоторые программисты пишут софт, который запустится только на той-же ОС, что и у автора, более того, нужна точно такая-же мышь, клавиатура и шлем виртуальной реальности.
Автор из будущего.
А есть похожая статья на английском, очень хочу коллегам показать?
Стремление к совершенству
По этой теме все было разжевано и до меня, однако я хочу быть последовательным, поэтому также разберу по косточкам и эту ловушку.
По этой теме все было разжевано и до меня, однако я стремлюсь к совершенству, поэтому также разберу по косточкам и эту ловушку.
Вы это подразумевали? :)
Глава об абстракционизме была бы не полной без знаменитой теоремы.
Доказательства не помню :)
Почти любую проблему в коде можно решить ведением дополнительного уровня абстракции. Исключение составляет проблема слишком большого количества уровней абстракции.
Доказательства не помню :)
Так можно очень много ловушек придумать.
1. Менеджмент. Крайности: пытаемся следить за каждым шагом подчиненных (микроменеджмент), не следим за программистом вообще (do whatever)
2. Логи. Крайности: либо логируем всё (каждый вызов метода, каждый переданный параметр), либо логируем вообще ничего
3. Классы. Крайности: god-классы со 100500 методами, все классы мелкие (один метод максимум, на каждый чих создаётся класс)
4. Интерфейсы. Крайности: выделять всё что можно в интерфейс, не пользоваться интерфейсами вообще
5. Форматирование кода. Крайности: всё строго по спецификации (даже если смотрится некрасиво), отсутствие форматирования (в коде каша, табы перемешаны с пробелами и т.д.)
и т.д. и т.п. насколько хватит фантазии…
1. Менеджмент. Крайности: пытаемся следить за каждым шагом подчиненных (микроменеджмент), не следим за программистом вообще (do whatever)
2. Логи. Крайности: либо логируем всё (каждый вызов метода, каждый переданный параметр), либо логируем вообще ничего
3. Классы. Крайности: god-классы со 100500 методами, все классы мелкие (один метод максимум, на каждый чих создаётся класс)
4. Интерфейсы. Крайности: выделять всё что можно в интерфейс, не пользоваться интерфейсами вообще
5. Форматирование кода. Крайности: всё строго по спецификации (даже если смотрится некрасиво), отсутствие форматирования (в коде каша, табы перемешаны с пробелами и т.д.)
и т.д. и т.п. насколько хватит фантазии…
Вера в то, что O(n) вместо O(n^{2}) или замена всех операций умножения на 2 на побитовый сдвиг сделают из программы конфетку
Мне кажется, что по поводу O(n) против O(n^2) вы все таки утрируете. Как только количество элементов чего-либо перевалит за 10000 (а это 100% случится благодаря Мерфи), то O(n^2) вылезут даже не боком, а более жестко )
Конкретно в этом примере, такие «узкие» места всегда должны подвергаться оптимизации и сразу. Одна из основ теории алгоритмов — избегать O(n^2) любыми способами.
А вот по поводу умножения на 2 — вполне согласен.
Тут ключевые слова — «сделают из программы конфетку».
Никто не спорит, что сложность алгоритмов очень важна и я согласен с Вами, насчет О(n) против O(n^2).
Но это не самое главное в программировании. И использовать лучшие алгоритмы недостаточно для написания хорошего продукта.
Никто не спорит, что сложность алгоритмов очень важна и я согласен с Вами, насчет О(n) против O(n^2).
Но это не самое главное в программировании. И использовать лучшие алгоритмы недостаточно для написания хорошего продукта.
Получается вы попадаете в свою же ловушку, если будете пропускать даже O(n^2), то есть в «запоздалую оптимизацию» следуя вашей терминологии. Конфетку, конечно же O(n^2) не сделает, но в то же время может превратить ваше детище в шлак.
Есть вещи, которые все таки нельзя нарушать, ну к примеру тот же $i <= array.count() прямо в цикле. Они являются признаками плохого кода.
Для меня главный посыл статьи = не заморачиваться ни в одну, ни в другую сторону. Как говорил Гай Кавасаки: продукт должен быть good enough. То есть не идеальным, но и не черти чем.
Дело в том, что кто-то после прочтения об O(n^2) может подумать, мол а меня-то в универе за это гоняли и я-то дурак заморачивался, а оказывается можно и так. И эти семена взойдут в нехороший урожай)
В общем, я все таки против O(n^2) — и не в «конфетке» все таки дело.
Есть вещи, которые все таки нельзя нарушать, ну к примеру тот же $i <= array.count() прямо в цикле. Они являются признаками плохого кода.
Для меня главный посыл статьи = не заморачиваться ни в одну, ни в другую сторону. Как говорил Гай Кавасаки: продукт должен быть good enough. То есть не идеальным, но и не черти чем.
Дело в том, что кто-то после прочтения об O(n^2) может подумать, мол а меня-то в универе за это гоняли и я-то дурак заморачивался, а оказывается можно и так. И эти семена взойдут в нехороший урожай)
В общем, я все таки против O(n^2) — и не в «конфетке» все таки дело.
Проблема вычислительной сложности алгоритма, это не проблема программирования.
Оптимизировать необходимо алгоритм.Если ДОКАЗАНО, что для задачи не может быть построен алгоритм быстрее чем O(n^5), то так тому и быть. Но зачастую есть выбор между O(n^2) без дополнительной памяти и O(n*Ln(n)) с использованием копии данных в памяти. Этот выбор необходимо осмысленно сделать. Это делается до программирования. Вообще говоря, до выбора инструмента.
А вторая ловушка, про абстракцию — это про еще более ранний этап. Про постановку задачи.
Грубо говоря, если от вас конкретно потребовали вычислить 2+2, то нужно понять, писать ли 2+2 или универсальное сложение. Или калькулятор? Или программируемый калькулятор?
Где граница разумного увеличения возможностей без значительного увеличения трудоемкости? Будет ли востребовано это расширение возможностей?
Оптимизировать необходимо алгоритм.Если ДОКАЗАНО, что для задачи не может быть построен алгоритм быстрее чем O(n^5), то так тому и быть. Но зачастую есть выбор между O(n^2) без дополнительной памяти и O(n*Ln(n)) с использованием копии данных в памяти. Этот выбор необходимо осмысленно сделать. Это делается до программирования. Вообще говоря, до выбора инструмента.
А вторая ловушка, про абстракцию — это про еще более ранний этап. Про постановку задачи.
Грубо говоря, если от вас конкретно потребовали вычислить 2+2, то нужно понять, писать ли 2+2 или универсальное сложение. Или калькулятор? Или программируемый калькулятор?
Где граница разумного увеличения возможностей без значительного увеличения трудоемкости? Будет ли востребовано это расширение возможностей?
По поводу оптимизации: разумеется побитовый сдвиг и вставки ассемблера — это оверкилл. Но пример со сложностью алгоритма O(n) vs O(n^2) неудачный, если мы говорил об обработки большого кол-ва данных. Я бы сказал, что допущение субоптимального алгоритма возможно только если оптимальный алгоритм либо гипер-сложен, либо нечитаемый (при условии, что общее время его выполнения остаётся приемлимым). Я не согласен с тем, что только академикам это надо :)
Писал лет 20 назад шифрование по ГОСТ82. На Дельфи. Скорость шифрования 20Кб/сек. Заказчику требовалось на порядок быстрее. При помощи ассемблерных вставок быстродействие удалось довести до 2Мб/сек. Там обработка 64-битными блоками и использование 32-х разрядных регистров с множеством специальных операций идеально легло в алгоритм.
Любой инструмент хорош, если используется в меру
Любой инструмент хорош, если используется в меру
По поводу перфекционизма:
• Вера в то, что главное в коде — красота, читаемость и поддерживаемость
Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности), т.к. если мы говорил о долгосрочных Agile-проектах, где классы не пишутся один раз и навсегда, кол-во затраченных часов на определённую модификацию (а значит и затраченные деньги) зависят как раз от этого.
• Поиск недостатков в любом коде
Я обычно делюсь всеми найденными недостатками с коллегами. Это уроки, которые должны делать каждый следующий кусок кода лучше. Разумеется, мы не говорим о крайности, когда человек только ищет недостатки вместо выполнения своей работы.
• Вера в то, что возможно написать идеальный код за разумное время
Неидеальный, но близкий к идеальному код можно написать за разумное время. Тут важен систематический подход. У многих код получается некачественным из-за того, что вместо того, чтоб начать с высокоуровневого дизайна, они начинают клепать прототипчики с костылями, допиливают его до работоспобного состояния и далее, устав, оставляют свою поделку на века долгие.
Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода, а не круглосуточному изучению каждого коммита в code-base.
• Вера в то, что главное в коде — красота, читаемость и поддерживаемость
Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности), т.к. если мы говорил о долгосрочных Agile-проектах, где классы не пишутся один раз и навсегда, кол-во затраченных часов на определённую модификацию (а значит и затраченные деньги) зависят как раз от этого.
• Поиск недостатков в любом коде
Я обычно делюсь всеми найденными недостатками с коллегами. Это уроки, которые должны делать каждый следующий кусок кода лучше. Разумеется, мы не говорим о крайности, когда человек только ищет недостатки вместо выполнения своей работы.
• Вера в то, что возможно написать идеальный код за разумное время
Неидеальный, но близкий к идеальному код можно написать за разумное время. Тут важен систематический подход. У многих код получается некачественным из-за того, что вместо того, чтоб начать с высокоуровневого дизайна, они начинают клепать прототипчики с костылями, допиливают его до работоспобного состояния и далее, устав, оставляют свою поделку на века долгие.
Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода, а не круглосуточному изучению каждого коммита в code-base.
Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности)
Вот вы и сами написали, что главное — работоспособность. Нерабочий чистый код никому не нужен.
Поиск недостатков в любом коде
Иногда, согласитесь, нужно мириться с недостатками, особенно, если код чужой, тем более, что кажется одному хорошо, другому — недостатком (как пример я работаю в паре с одним программистом, ему кажется, что мутабельные объекты это нормально, а мне кажется, что это недостаток (когда можно без них)).
Неидеальный, но близкий к идеальному код можно написать за разумное время.
Значит идеальный нельзя таки.
Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода
Да, Вы меня правильно поняли.
Спасибо за Ваше мнение, я обязательно учту Ваши пожелания при написании следующей статьи.
Хочу добавить по поводу недостатков.
Есть спорные ситуации, где имеют место быть разные мнения и предпочтения, например те же маркер-интерфейсы — кто-то их любит, я считаю их исторической издержкой в случае языка с поддержкой аннотаций или «аттрибутов» в терминологии .NET. Есть правда у них некоторые технические ограничения связанные с наследованием, но суть не в этом.
А есть объективно неверные решения. Примеры, которые я часто встречаю в своём проекте:
код выполняется много раз повторно без причины
метод Initialize написан с кучей всяких ненужных проверок как будто инициализацию собираются делать много раз, но это не так
полный хаос с модификаторами доступа, одни паблики кругом. И всё это вынесено в интерфейс
Есть много других примеров.
Я всегда стараюсь допускать альтернативные точки зрения в области разработки, но эта точка зрения должна быть обоснована. Если аргументы за отсутствуют (недостаточно продебагили, копи-пасты кода или просто непонимание элементарных принципов ООП), то это недостаток и надо на них указывать. Моей мотивацией это делать не является показать своё превосходство над остальными или как-то их унизить. Всё намного проще. :) Мне потом работать с этим всем и возможно придётся долго поддерживать code-base. Поэтому я стараюсь заранее облегчить себе жизнь, ну а кому-то может будет и опыт.
Есть спорные ситуации, где имеют место быть разные мнения и предпочтения, например те же маркер-интерфейсы — кто-то их любит, я считаю их исторической издержкой в случае языка с поддержкой аннотаций или «аттрибутов» в терминологии .NET. Есть правда у них некоторые технические ограничения связанные с наследованием, но суть не в этом.
А есть объективно неверные решения. Примеры, которые я часто встречаю в своём проекте:
код выполняется много раз повторно без причины
метод Initialize написан с кучей всяких ненужных проверок как будто инициализацию собираются делать много раз, но это не так
полный хаос с модификаторами доступа, одни паблики кругом. И всё это вынесено в интерфейс
Есть много других примеров.
Я всегда стараюсь допускать альтернативные точки зрения в области разработки, но эта точка зрения должна быть обоснована. Если аргументы за отсутствуют (недостаточно продебагили, копи-пасты кода или просто непонимание элементарных принципов ООП), то это недостаток и надо на них указывать. Моей мотивацией это делать не является показать своё превосходство над остальными или как-то их унизить. Всё намного проще. :) Мне потом работать с этим всем и возможно придётся долго поддерживать code-base. Поэтому я стараюсь заранее облегчить себе жизнь, ну а кому-то может будет и опыт.
На тему преждевременной оптимизации hyoo.ru/?article=%D0%9A%D0%BE%D1%80%D0%B5%D0%BD%D1%8C+%D0%B2%D1%81%D0%B5%D1%85+%D0%B7%D0%BE%D0%BB;author=Nin+Jin
Суммируя всё вышесказанное в статье и всё ниженаписанное под ней в комментариях, можно выделить две ультра-крайности.
Параноик (Консерватор)
1. Чрезмерная оптимизация
2. Излишняя сложность абстрацкции
3. Перфекционизм
4. Злоупотребление инструментами (библиотеками/фреймворками)
5. Трудоголизм
6. Вера в «Золотой молоток»
7. Кроссплатформенность — любой ценой
8. Защитное программирование
9. Максимальная многозадачность
10. Безграничное доверие к чужому «умному» коду
11. Самопрограммирование как самоцель, непрерывное самокопание
Шизофреник (Анархист)
1. Пренебрежение оптимизацией
2. Упрощение до бесконечности
3. Путь хаоса
4. Пренебрежение инструментами (библиотеками/фреймворками)
5. Привычка всё делать спустя рукава
6. Вера в то что "Ложки Серебряной пули не существует"
7. iOS, Linux, Android? Нет, не слышал. Win32 — наше всё!
8. Беззащитное программирование
9. Хроническое откладывание на потом
10. Только «велосипеды», только хардкор
11. Уверенность в своей непогрешимости, нежелание вообще заниматься самоанализом
Параноик (Консерватор)
1. Чрезмерная оптимизация
2. Излишняя сложность абстрацкции
3. Перфекционизм
4. Злоупотребление инструментами (библиотеками/фреймворками)
5. Трудоголизм
6. Вера в «Золотой молоток»
7. Кроссплатформенность — любой ценой
8. Защитное программирование
9. Максимальная многозадачность
10. Безграничное доверие к чужому «умному» коду
11. Самопрограммирование как самоцель, непрерывное самокопание
Шизофреник (Анархист)
1. Пренебрежение оптимизацией
2. Упрощение до бесконечности
3. Путь хаоса
4. Пренебрежение инструментами (библиотеками/фреймворками)
5. Привычка всё делать спустя рукава
6. Вера в то что "
7. iOS, Linux, Android? Нет, не слышал. Win32 — наше всё!
8. Беззащитное программирование
9. Хроническое откладывание на потом
10. Только «велосипеды», только хардкор
11. Уверенность в своей непогрешимости, нежелание вообще заниматься самоанализом
Госспади! Да не дай бог такие в жизни встретятся… тем более друг другу. Они ж взаимно убьются!
Провел самоанализ — да я тогда вообще тот еще индивид.
1. Чрезмерная оптимизация
2. Порядок
3. Порядок
4. Да мне пофиг что ты там нагуглил, пока-ты ты с эти разберешся, я свое накатаю!
5. Порядок
6. Вера в то что «Ложки/Серебряной пули не существует»
7. Порядок
8. Порядок
9. Иногда
10. Вот за что я люблю велосипеды, так это за две вещи: они прокачивают тебя и позволяют решить задачу даже если хрен знает как ее и решать.
11. Порядок
1. Чрезмерная оптимизация
2. Порядок
3. Порядок
4. Да мне пофиг что ты там нагуглил, пока-ты ты с эти разберешся, я свое накатаю!
5. Порядок
6. Вера в то что «Ложки/Серебряной пули не существует»
7. Порядок
8. Порядок
9. Иногда
10. Вот за что я люблю велосипеды, так это за две вещи: они прокачивают тебя и позволяют решить задачу даже если хрен знает как ее и решать.
11. Порядок
Всё здорово, спасибо за статью, но для полного счастья не хватает ловушек, которые касаются уже не только кодирования, а к примеру документирования (тогда как оно, особенно учитывая существования автоматической генерации документации проекта по коду, имеет отношение к кодированию всё-таки) далее — манеры общения с заказчиком по ходу работы, а также разработки собственно пользовательского интерфейса, это — именно то, что в конечном счёте видит перед собой пользователь. Это то, что — в конце концов — продаётся, кормит программиста и значит его нельзя не отнести прямо к программированию.
Здесь, конечно, в конечном итоге всё также сводится к соблюдению меры, тем не менее, было бы совсем хорошо, если бы эта статья дополнилась систематизацией ловушек из упомянутых областей.
Здесь, конечно, в конечном итоге всё также сводится к соблюдению меры, тем не менее, было бы совсем хорошо, если бы эта статья дополнилась систематизацией ловушек из упомянутых областей.
Главная ловушка программирования в том, что оно довольно интересно. Поэтому вместо того, чтобы прокачивать социальные навыки и мутить денежные замуты, молодые люди погружаются в программирование с головой. А когда выныривают после 30, оказывается, что ипотека, кредитный фокус и жена-жируха вовсе не предел мечтаний. Sad but true. Минусуйте — пофигу. Я, к с частью, выбрался :)
Все эти статьи будто повторяют одно и тоже. Какие-то ощущения, что за этим всем стоит какой-то общий смысл. Программирование просто выражает его по-своему. Видимо, что-то вроде, что чем больше качества, тем дольше; чем меньше качества, тем быстрее.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
8 ловушек программирования