Пользователь
0,0
рейтинг
8 апреля 2014 в 02:36

Разработка → 8 ловушек программирования



Эта статья содержит те ловушки программирования, в которые я попадал сам, продолжаю попадать и возможно никогда не прекращу, а также те, в которых я находил своих товарищей.

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

Краткое введение


Представьте, что вы попали в яму. Пусть она будет глубиной 3 метра. Вы начнете из нее выбираться, карабкаться, цепляться, не знаю, что вы там еще придумаете, но скорее всего вы выберетесь.

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

Как думаете, долго вы пробудете в такой яме?

Скорее всего до тех пор, пока вас кто-нибудь там не найдет!

Но это не такая уж большая проблема, из каждой ловушки программирования можно выбраться своими силами и почти без посторонних усилий — нужно всего-то знать три вещи: в какой вы ловушке, как вы туда попали и где “потайная дверь” — выход.

Есть одна удивительная вещь в ловушках программирования — почти каждая ловушка это приверженность одной из двух противоположных крайностей, а выбраться из ловушки — значит умело балансировать между ними.

Можно сказать, что избегание ловушек — это ходьба узкой дорожке, где слева — проблемы, а справа — пути их решения, доведенные до абсурда.

Ладно, все равно введение никто не читает, так что поехали!


Ловушка №1: Оптимизация




Как и писал Кнут, преждевременная оптимизация — корень всех зол. Многие знают это правило, некоторые ему не следуют, некоторые возводят его в абсолют, но немногие знают, что запоздалая оптимизация еще хуже!

Слишком большое внимание оптимизации


Часто этим грешит такой тип программистов как “Олимпиадник”. Знание эффективных алгоритмов или внутреннего устройства процессора заставляет их думать, что код должен быть максимально эффективен.

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

Признаки того, что вы в ловушке
• Попытка сразу писать быстрый/нетребовательный к ресурсам код
• Желание выжать из кода все, в ущерб остальным показателям
• Вера в то, что O(n) вместо O(n^{2}) или замена всех операций умножения на 2 на побитовый сдвиг сделают из программы конфетку


Слишком маленькое внимание оптимизации


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

Сейчас, когда готово уже более половины я понял — пытаясь избежать одной ловушки я попал в противоположную!

Теперь для того, чтобы улучшить производительность до приемлемого уровня, нужно не просто прогнать пару раз профайлер и исправить пару изолированных в функции алгоритмов, нужно переписать как минимум треть уже написанного кода!

Эта ловушка называется — запоздалая оптимизация, если вы не предусматриваете возможность оптимизации заранее, будьте готовы к тому, что значительную часть вашего красивого и понятного кода придется выкинуть!

Признаки того, что вы в ловушке
• Искренняя вера в то, что любая оптимизация — преждевременная
• Откладывание оптимизации на заключительную часть проекта
• Отказ предусмотреть некоторые небольшие архитектурные решения для будущей оптимизации


Выход

• Не пытайтесь оптимизировать код сразу — создавайте возможности для будущей оптимизации
• Не откладывайте оптимизацию без причины
• Правило 20/80: тратьте свое время на те 20% кода, что дадут 80% результата (да, используйте профилировщик)



Ловушка №2: Абстракция




Абстракция в программировании пожалуй самая хорошая штука. Сначала были двоичные коды, затем мнемоники команд процессора, затем императивное программирование — состояние и операции (утверждения), далее структурное, процедурное, модульное, объектно-ориентированное, функциональное программирование.

Представьте себе, что вам все еще нужно использовать goto, чтобы организовать цикл.

Представьте себе, что вам все еще нужно плодить одинаковые функции, отличающиеся лишь типом данных (вместо использования преимуществ динамической типизации и шаблонов/генериков).

Представьте себе, что вы не можете просто так взять и изменить размер коллекции — нужно выделить новый участок памяти, скопировать туда старую коллекцию, добавить новый элемент, освободить не использующуюся память.

Излишняя сложность


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

Нагромоздить 20 классов, использовать 12 разных паттернов, реализовать свой DSL для парсинга другого DSL, создать кроссплатформенный фреймворк для визуализации циклических графов для создания очередного тетриса — это про “поборников абстракции”.

Признаки того, что вы в ловушке
• Написание универсального фреймворка перед реализацией основной функциональности, причем использоваться будет от силы 30% написанного кода
• Вера в то, что из любой проблемы лучший выход — использовать какой-либо паттерн
• Написание максимально обобщенной, принимающей все на свете и выдающей корректные результаты для любых входных значений функции, вместо специализированной, даже если ее функционал никогда не будет использован


Упрощение до бесконечности


Признаки “поборников абстракции” чаще встречаются у более опытных программистов. Игнорирование абстракций — у новичков. Лучшие опять балансируют где-то между этими крайностями.

Новички часто еще не знают, что за абстракции есть в программировании вообще и в используемом ими языке в частности. Из-за этого они часто пишут невыразительный код — такой, который можно было бы переписать, используя встроенные языковые средства или сторонние библиотеки/фреймворки сделав его короче, понятнее и, чаще всего, эффективнее.

Признаки того, что вы в ловушке

Для этого пункта довольно сложно подобрать общие признаки — все зависит от языка, задачи и кучи других факторов, но все же:
• Игнорирование абстракций, которые могли бы объективно улучшить код (например, итераторов в C++, монад в Haskell (я имею ввиду отказ от написания своей монады, там где это имеет смысл), генераторов в Python, интерфейсов в Java и т.д.)
• При переходе на новый язык программирования — отказ от изучения его абстракций, в виду того, что и без них жилось неплохо (опять же пример — при переходе с C на C++ — отказ от изучения итераторов, при переходе с императивного языка на Haskell — отказ от изучения монад)
• Вера в то, что те возможности языка, которые вы не используете на самом деле лишние (не касается программистов на C++; шутка конечно, но как известно в каждой шутке...)


Выход

• Не используйте абстракции ради абстракций
• Используйте известные/доступные вам абстракции там где им место и не используйте их там, где им места нет
• Изучите абстракции, которые предоставляет ваш язык программирования
• Перед реализацией какой-либо функциональности, подумайте — действительно ли она вам нужна (принцип YAGNI)
• Где возможно без особых потерь обойтись без абстракций — обходитесь без них (принцип KISS)



Ловушка №3: Перфекционизм




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

Стремление к совершенству


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

Признаки того, что вы в ловушке
• Вера в то, что главное в коде — красота, читаемость и поддерживаемость
• Непрекращающийся рефакторинг и переписывание даже приемлемого кода
• Поиск недостатков в любом коде
• Вера в то, что возможно написать идеальный код за разумное время
• Повышенное внимание к мелочам
• Попытки достичь максимально возможного результата
• Длительное обдумывание архитектуры даже простейших частей проекта


Путь хаоса


Из предыдущего списка видно, что перфекционизм — опасная ловушка, может отказаться от него совсем?

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

Поэтому полный отказ от своего стремления к совершенству загонит вас в полностью противоположную ловушку.

Признаки того, что вы в ловушке
• Вера в то, что читаемость и расширяемость кода не важна
• Отсутствие критического мышления, особенно по отношению к своему коду
• Довольствование даже минимально приемлемым результатом, или неприемлемым вовсе
• Полный отказ от рефакторинга
• Отказ от обдумывания сложных частей архитектуры
• Непринятие возможности переписать проект или его часть с нуля


Выход


Как всегда где-то посередине:
• Примите, что важна и красота кода и достижение результата, порой второе даже важнее
• Считайте, что переписывание с нуля — крайняя мера, но смиритесь с тем, что это может быть необходимо
• Выделите себе максимальное время, которое вы можете тратить на рефакторинг. Это может быть 20, 50, даже 80% от всего рабочего времени, главное — никогда его не превышайте, чтобы не застрять
• Когда вы обнаруживаете недостаток — подумайте, настолько ли он силен, чтобы тратить время на его исправление
• Используйте правило 20/80 — старайтесь в первую очередь делать те 20% работы, которые принесут 80% результата


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


Ловушка №4: Технологии и инструменты


image

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

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

Лень


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

Подключение одновременно boost, Qt и активное использование STL при написании Hello World — не лучшая идея, но иногда похожие вещи случаются и это — очередная ловушка.

Признаки того, что вы в ловушке
• Подключение библиотеки на 30+ мегабайт, ради Вихря Мерсена
• Вера в то, что все, что нужно уже было написано
• Непринятие того, что велосипед может оказаться лучше
• Невозможность написать и строчки кода без автодополнения в IDE
• Активное использование инструментов, без понимания принципов их работы. Например, частое использование инструментов для визуального редактирования GUI (вроде Qt Creator, CodeGear Rad Studio, MS Visual Studio) и, при этом, отказ от попытки разобраться в их устройстве


Трудоголизм


Значит ли это, что я призываю всех отказываться от использования всех инструментов и библиотек, призываю писать голый код со своими велосипедами в nano (или еще хуже — на папирусе)?

Отнюдь. Наоборот, как вы увидите, полное игнорирование нашего программистского наследования — еще худший порок. И наверное самая опасная ловушка для программистов.

Признаки того, что вы в ловушке
• Регулярное написание все новых и новых велосипедов, без веских причин для этого
• Вера в то, что возможностей языка и стандартной библиотеки должно хватать для всего
• Вера в то, что автодополнение (не как в Sublime Text, а как в IDE) — для склеротиков
• Написание своей билиотеки, пусть и монструозной, но даже не приближающейся по функциональности к существующим аналогам
• Заявления о том, что отладчики и профилировщики нужны тем, кто не понимает как работает собственный код


Выход

• Познакомьтесь с доступными вам инструментами, но не пытайтесь применять их где попало
• Тщательно взвесьте все за и против, перед тем как выбирать между использованием сторонней библиотеки и написанием велосипеда
• Старайтесь улучшить свою продуктивность используя современные инструменты, в тоже время не зависьте от них
• Примите то, что в учебных/тестовых проектах можно делать исключения из этих правил



Ловушка №5: Золотой молоток




Еще один пункт в нашем хит-параде ловушек — золотой молоток.

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

Есть несколько схожих терминов — панацея, волшебная таблетка, серебряная пуля, т.е. такой метод, который всегда, в 100% случаев выполняет любую задачу. Еще одна имеющая к этой теме поговорка — забивать гвозди микроскопом.

Золотой молоток — довольно часто встречающаяся, но совершенно непохожая на другие ловушка. Золотым молотком может быть все что угодно, кто-то может влюбиться в ООП и писать классы на каждый чих, кто-то в паттерны проектирования и построить программу из одних лишь фабрик и синглтонов.

Для кого-то золотой молоток — это любимый язык программирования, для кого-то — любимая парадигма, для кого-то — методология разработки.

Главное, что выделяет золотой молоток — попытка использовать его всегда и везде.

Признаки того, что вы в ловушке
• Использование одного языка программирования для всех задач
• Вера в то, что одна парадигма может решить все проблемы программирования (чаще всего так говорят про ООП и ФП)
• Использование для всех проектов, независимо от условий одной методологии разработки, например, бездумное использование TDD во всех проектах
• Применение какого-либо средства, предоставляемого языком для большей части задач, например:
– Передача всех аргументов только по константной ссылке
– Использование во всей программе лишь одного типа коллекций, скажем массивов (векторов)
– Использование повсюду немутабельных объектов
– Использование в похожих по синтаксису языках (например, Java и C)
одного стиля отступов и метода наименования сущностей


Серебряной пули не существует


Я боюсь, что эта ловушка — исключение из правил и возможно ее избежать не рискуя попасть в другую.

Это исключение из замеченной мною закономерности еще раз доказывает, что золотого молотка не существует — мой метод описания ловушки как двойственной сущности дал осечку, но я не боюсь отказаться от его использования.

Это и есть правильный путь освобождения из этой ловушки.

Выход

• Если вы знаете лишь один язык программирования — выучите еще один, или два (можно и больше, но в разумных пределах)
• Если вы знаете несколько языков программирования, но у вас есть очевидный любимчик, попробуйте чаще использовать остальные языки
• Если вы программировали только придерживаясь императивного или объектно-ориентированного программирования, попробуйте функциональное
• Если вы постоянно используете какую-либо одну методологию разработки, попробуйте что-нибудь новое
• Перед тем как принимать решения по инерции (и применять свой золотой молоток) — подумайте о возможных альтернативных решениях



Ловушка №6: Кроссплатформенность




Кроссплатформенные приложения — те, что запускаются на нескольких ОС и/или на нескольких платформах.

И тут опять есть две крайности — некоторые разработчики пытаются написать приложение так, чтобы оно работало на всех возможных ОС и одинаково хорошо подходило и для ПК и для планшета и для смартфона.

Для всех и каждого


Часто люди хотят достичь просто невероятной степени кроссплатформенности.

В итоге у них получается, что ни на одной ОС приложение не работает полностью корректно и его одинаково неудобно использовать и на ПК и на планшете и на смартфоне!

Они попали в ловушку излишней кроссплатформенности!

Признаки того, что вы в ловушке
• Вера в то, что можно написать такой код, который выдавал бы приемлемые результаты на всех целевых платформах, без изменений
• Попытки охватить как можно больше операционных систем и платформ, при этом не желая заниматься портированием и изменить хотя-бы часть кода
• Неприязнь к любому коду, предназначенному только для одной платформы


Существует только Win32


И наоборот — некоторые программисты пишут софт, который запустится только на той же ОС, что и у автора, более того, нужна точно такая же мышь, клавиатура и шлем виртуальной реальности.

Часто причина этого, просто то, что программист не задумывается о том, что существуют другие ОС и платформы, помимо тех, что использует он.

Признаки того, что вы в ловушке
• Переписывание всего (или большей части) кода приложения для каждой целевой ОС/платформы
• Написание заведомо труднопортируемого кода там, где этого можно избежать
• Использование нестандартных расширений компилятора/интерпретатора


Выход

• Осторожно определите целевые ОС/платформы
• Будьте готовы к тому, что для некоторых ОС/платформ придется изменить часть кода или даже написать отдельную версию с нуля
• Не привязывайте код к одной платформе специально
• Старайтесь охватить несколько платформ, если это усложнит разработку



Ловушка №7: Защита




(Без)защитное программирование — еще одна замечательная ловушка, в которой вы возможно увидите себя (настоящего или прошлого).

Беззащитное программирование


Беззащитное программирование — противоположность практики защитного программирования, это вера в то, что функции всегда будут переданы правильные аргументы, что побочных эффектов не существует, или они не повлияют на работу кода, что указатель никогда не будет равен null и тому подобные штуки.

Иногда это хорошо, это делает код свободным от множества проверок, однако отладка такого кода — сущий ад. Именно поэтому это ловушка.

Признаки того, что вы в ловушке
• Бесстрашность перед переполнением, делением на ноль и ошибками округления
• Вера в абсолютную непогрешимость стандартных и библиотечных функций/классов
• Вера в то, что пользователь не допустит ошибку при вводе
• Вера в то, что память никогда не закончится
• Вера в то, что все необходимые приложению файлы конфигурации существуют и к ним всегда есть доступ


Защитное программирование


Миллионы тестов для заведомо работающих частей приложения, 15 ASSERT'ов внутри каждой функции, собственная библиотека исключений, логирования, попытки уронить приложение при малейших отклонениях.

Это обратная сторона медали — ловушка защитного программирования.

Признаки того, что вы в ловушке
• Каждая функция в проекте начинается с пачки ассертов или возбуждения исключений
• Тестами покрывается абсолютно весь код, включая сторонние библиотеки
• В проекте имеется собственный класс MyProjectException и сложная иерархия как минимум 10 его наследников, смысл которых сводится к сообщению о неверных аргументах функции
• Запись в лог большей части всего того, что происходит с приложением
• Даже небольшие отклонения для вас неприемлемы и должны ронять приложение с сообщением об ошибке и автоматической отправке баг-репорта с полным дампом памяти


Выход

• Тщательно обдумывайте что стоит проверять, а что нет
• Особое внимание при проверках уделяйте пользовательскому вводу и внешним ресурсам
• По-возможности старайтесь использовать стандартные классы исключений
• Не пытайтесь проверить все
• Отделяйте критические ошибки от незначетельных, позвольте приложению работать дальше, если ничего особо страшного не произошло
• Записывайте в лог только самые важные данные, реализуйте ненавязчивую возможность отправить баг-репорт



Ловушка №8: Откладывание на потом




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

Суть ловушки в том, что часто реализуя какую-либо функциональность, мы ставим пометки — TODO, HACK, и некоторые другие.

Реализация этих задач самому себе откладывается, про TODOшки редко кто вспоминает и они долгое время так и остаются недоделанными.

Признаки того, что вы в ловушке
• Множество пометок TODO и HACK в проекте и их количество не уменьшается
• Code Review не приносит никаких результатов, кроме расстановки новых TODO и WTF
• Невозможность ненадолго отвлечься от выполняемой задачи, чтобы реализовать косвенно-связанную с ней (вместо оставления TODO) или исправить обнаруженную ошибку (вместо оставления FIX или HACK)


Многозадачные программисты


Существуют программисты, которые не могут переключиться в процессе реализации какой-либо части проекта на другую, пусть даже непосредственно с ней связанную (скажем написать класс исключения и выбросить его, вместо оставления пометки “TODO: check argument to null”).

И наоборот, существуют программисты, которые это умеют, я называю таких многозадачными программистами, но вот беда — реальной многозадачности нет и на самом деле они просто быстро переключаются с одной задачи на другую.

У этого есть свой плюс — TODO и HACK в коде не ставятся, а сразу правятся, найденные ошибки в другом коде — устраняются.

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

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

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


Выход

• Перед тем как отложить задачу и поставить TODO подумайте, может реализовать ее можно быстро
• Не бойтесь отвлекаться от основной задачи, но не делайте это слишком часто и на долго
• Осматривая код, исправляйте найденные ошибки сразу
• Откладывайте несвязанный с текущей задачей большой функционал — оставляйте TODO
• Программируя в паре, избегайте переключений вообще, откладывайте все посторонние задачи



Ссылки



AlenaC++: Кому на самом деле принадлежит цитата о преждевременной оптимизации
Wordpresse: Защитное программирование

Habrahabr: Запоздалая оптимизация
Habrahabr: 5 стадий некомпетентности программиста
Habrahabr: Эти бесчисленные парадигмы, концепции, инструменты и фреймворки
Habrahabr: Паралич анализа: вы знаете слишком много, чтобы просто писать код
Habrahabr: Три ключевых принципа ПО, которые вы должны понимать
Habrahabr: Кроссплатформенность — это круто
Habrahabr: Аппаратная кроссплатформенность: есть ли выход?
Habrahabr: Защитное программирование

Wikipedia: KISS
Wikipedia: YAGNY
Wikipedia: DRY
Wikipedia: Перфекционизм
Wikipedia: Золотой молоток
Wikipedia: Прокрастинация

Вместо заключения


Всем удачи в ходьбе по канату!
@domu
карма
50,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +7
    Ох, эта 8 ловушка! Спасибо за статью, будем выбираться из ям.
    • +2
      Конечно будем выбираться. Вон, даже Патрик сделал все, что запланировал в отличие от меня.

      Большое спасибо за статью.
      • +4
        TODO: перестать откладывать на потом
        • +1
          И заламинировать.
          • 0
            И на стенку в рамочку)
            • 0
              И рядом с монитором… :)
        • +2
          556 человек так и сделали.
    • +1
      Обязательно будем, но оставим это на потом)
  • +3
    Использование в похожих по синтаксису языках (например Java и C)
    одного стиля отступов и метода наименования сущностей


    А тут что плохого? Если компилятору это не мешает, то это чисто вопрос личных привычек и предпочтений.
    • +2
      Я бы еще дополнил это простым примечанием и пожеланием для разработчиков современных IDE. Я считаю, что форматирование может быть выполнено IDE так, как нравится конкретному человеку. Лично я категорически против определенных стилей форматирования и у меня свои заморочки. И так у каждого. Код, в конце концов может быть обработан в соотвествии с правилами настроенными по вкусу разработчика. Благо, уже сейчас есть IDE, которые неплохо с этим справляются и даже умеют автоматически форматировать код перед отправкой в VCS.

      А по поводу статьи — все, как говорится, хорошо в меру. Именно поэтому в команды программистов стараются набирать людей с определенными склонностями. И разнообразие может приводить как к плачевным, так и к великолепным результатам. Тут уже все зависит от лида или менеджера проекта. Кроме того, немаловажно значение амбиций и пристрастий, да и с возрастом понимаешь, что все люди разные, что каждый по-своему на все смотрит. Учишься уважать мнение других людей, учитывать чужие и свои ошибки. Главное, не быть заложником своих идей, быть открытым всему новому и способным изменить (не предать!) свою точку зрения.
      • 0
        >>пожеланием для разработчиков современных IDE
        Я у себя в NetBeans настраиваю так как удобно мне. Т.е. меняю дефолтовое форматирование
        • 0
          А я вот как-то привык сам форматировать во время написания. Недавно пришлось немного в консоле пописать код, так никаких проблем — все красиво и понятно. Закомплилиось, правда, со второго раза, но это уже совсем другая история…
      • +4
        Во всех крупных компаниях стиль форматирования — как футбольная форма. Единый для всей команды. И это правильно. Любители индивидуальных отступов либо переучиваются, либо их увольняют.
        • 0
          Либо во время обсуждения стиля под столом показывают сжатый кулак лоббируют свои интересы.
    • +3
      Это — показатель того, что вы, возможно, в ловушке золотого молотка. Не факт, просто повод задуматься.

      Компилятору не мешает — очень плохой аргумент. Компилятору не мешает код в одну строку (если это не строчно-ориентированный язык), не мешают имена переменных в одну букву, не мешает отсутствие (или огромное количество) комментариев.

      Код-стайл — он для людей, а не для компиляторов.
      Если вы применяете один и тот-же код-стайл в нескольких разных языках — возможно этот код-стайл для вас — золотой молоток. (подчеркиваю — возможно)
  • +6
    Я считаю, что необходимо появление психологов, специализирующихся на программистах и их «болезнях». Потому что от некоторым самостоятельно исцелиться крайне сложно.

    Соответственно при устройстве в крупную фирму, бесплатный абонемент к такому специалисту, входящий в «соц. пакет», может быть серьёзным подспорьем в выборе фирмы. Работодатели, ау!
    • 0
      И не забыть вакцины от перфекционизма!
  • +5
    Тестами покрывается абсолютно весь код, включая сторонние библиотеки

    Особое внимание при проверках уделяйте пользовательскому вводу и внешним ресурсам

    Я бы как раз особое внимание выделила тестам сторонних библиотек и сервисов, особенно если они обновляются.
    • 0
      Вы, возможно в ловушке защитного программирования.

      А может и нет. Признаки того, что вы в ловушке созданы для того, чтобы подумать, не доходите ли вы до крайности. Если нет — все хорошо, независимо от того, тестируете ли вы встроенную функцию max или нет.
      • 0
        А мне кажется, что вы в ловушке пытаетесь каждого определить в какую-нибудь ловушку из вашей системы.
      • +1
        А ещё вы попали в ловушку выканья в вашем тексте 88 (восемьдесят восемь) раз встречается слово «вы», по шесть раз слова «вам» и «вас», а также четыре раза слово «ваш». А текст-то небольшой.

        Вы не подумайте, ваш пост имеет рациональное ядро, и его смысл мне понравился и показался полезным, но от такого количества (больше ста!) словоформ личного местоимения второго лица множественного числа у меня при прочтении текста аж язык сковало.
        • +1
          88 — это очень хорошо. Если учесть что в статье ~3200 слов, то «вы» встречается с частотой в 0.0275%.
          И 15 из них можно вычесть, т.к. они часть шаблонной фразы «Признаки того, что вы в ловушке».

          Ну а если серьезно, спасибо за замечание. Проанализирую ситуацию, если это плохо, буду исправляться.
    • +1
      Обычно, выпуская что-то в продакшн, версии сторонних библиотек морозят намертво. Поэтому написание тестов — лишняя трата времени, лучше уж сразу использовать те библиотеки, которые изначально покрыты тестами их авторами.
      • 0
        Проблема в том, что бага в сторонней библиотеке часто выявляется именно уже «в продакшне». И когда автор библиотеки эту багу починит, надо будет забрать у него обновлённую версию… с кучей других баг, созданных им за это время.
    • +1
      Кстати, к перечисленным в статье когнитивным искажениям можно добавить еще пару противоположных друг другу:

      1. Беззаветное доверие любому «чужому» коду (обычно свойственно наивным новичкам, которые считают, что библиотеки пишут «умные дяди», которые никогда не ошибаются). Крушение надежд обычно очень болезненно и иногда приводит даже к провалу проекта (если приходится сидеть в отладке чужого, непонятного кода, вместо того, чтобы писать свой.

      2. Хроническое недоверие ко всем сторонним решениям — часто приводит к проблеме «велосипедов». В лучшем случае человек обкладывает чужой код кучей тестов, в худшем рассуждает так: нафиг эти чужие глючные вещи, напишу своё. Простое, работающее, годящееся в моей задаче.
  • +3
    Нагромоздить 20 классов, использовать 12 разных паттернов, реализовать свой DSL для парсинга другого DSL, создать кроссплатформенный фреймворк для визуализации циклических графов для создания очередного тетриса — это про “поборников абстракции”.

    Однако именно из такого (или примерно такого) подхода рождаются фреймворки, новые языки, новые СУБД и т.д. Не стоит забывать, что для многих программирование это не только кратчайшее решение поставленной задачи по ТЗ, но и творчество и научные изыскания в процессе.
    • +7
      Безусловно, существует вероятность, что при таком подходе программист создаст новую крутую библиотеку, которая сэкономит сотни тысяч человеко-часов для всего мира. Но вероятность того, что такая библиотека уже есть, а из вновь написанной будет использоваться в текущем проекте не больше 10%, намного выше. В словах автора главное, я думаю, «для создания очередного тетриса». То есть, если задача тривиальна, надо ее просто решать наиболее быстрым способом. Писать фреймворки стоит в тех случаях, когда существующие решения объективно не очень хороши.
      • 0
        Больше библииотек и языков — хорошо. Естественный отбор может работать только на дастаточно больших популяуиях.
        Проблемы не в количестве библиотек, а в сложности их инвентаризации. Если бы большенство библиотек были бы описаны в системах, подобных Hoogle, Scalex, Clojure Atlas, «слздавать тертисы» было бы приятнее и интереснее.
        • 0
          Возможно, вы правы. Но, по-моему, 99% таких библиотек, созданных только ради того, чтобы написать очередной тетрис, так и останутся лежать на винчетсерах их создателей. И для следующего своего проекта такой разработчик будет с нуля писать очередной велосипед.
      • +1
        Что хочется добавить:

        Дело в том, что порой нужно написать велосипед, чтобы понять, «как всё работает». Думаю, не секрет, что копание в чужом коде и написание своего — совершенно разные по фану вещи. Это как с играми — через них всё познаётся проще и порой быстрее.
        Тут, создавая свой велосипед, натыкаешься на проблемы, о которых возможно даже и не задумаешься, используя сторонний продукт.

        Т.е., подводя итог, если относиться к созданию велосипеда как к игре, то в этом нет ничего плохого. Главное, не заиграться.
  • +29
    (далее следует юмор, о автор и читатели)

    Ловушка номер 9: самопрограмирование

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

    Признаки того что вы в ловушке: вы пишете статьи о повышении своей эффективности как програмиста.

    Выход: писать код

    Или как один писатель, чтобы каждый раз как он ловил себя на мысли, что говорит или думает что-то умное, хотел чтобы это сразу ложилось в книгу, и повесил на стеле плакатик с двумя словами «НА БУМАГУ»

    • +11
      Забыли про обратную сторону: самоуверенность — нежелание как-либо анализировать свою работу, вера в свою непогрешимость

      Признаки того, что вы в ловушке: вы не анализируете себя, не считаетесь ни с чьим мнением и не узнаёте новые методологии, коротко — не развиваетесь

      Выход: анализировать результаты своей работы, хотя бы после того, как они готовы.

      Как-то так.
      • 0
        Я бы оба пункта добавил. Лично не раз видел людей, которые говорят о повышении своей эффективности, а на деле просто вместо написания кода смотрят видео на ютьюбе. Или же да, наоборот, но с правилом «Мой код не может работать неправильно. Если он работает неправильно, проверь руки».
        А в общем, суть всех этих правил — не нужно доходить до фанатизма.
    • 0
      По-секрету (только тссс!) скажу, что в черновом варианте статьи была ловушка №9 — гордость.
  • 0
    избегание ловушек — это ходьба узкой дорожке, где слева — проблемы, а справа — пути их решения, доведенные до абсурда.

    отлично сказано! можно я это где-то запишу и буду цитировать?
    • 0
      Цитирование (с указанием авторства) не требует разрешения автора. По крайней мере в РФ.
      • 0
        Ах, ну что Вы так серьезно. Разрешаю даже без указания авторства.
  • +3
    Я как то вырабатывал критерий, когда нужно что-то рефакторить. Вышло так

    1. Код не срабатывает
    2. Код используется активнее, чем ожидалось (т.е. проблемы производительности очевидны)
    3. Количество запросов на изменение кода больше чем ожидалось (т.е. проблемы поддержки кода очевидны)
    4. Кодом нужно поделиться с большим числом разработчиков чем планировалось (т.е. проблемы читаемости кода очевидны)

    Строго в этом порядке. Заодно был получен и критерий, когда нужно что-то перепроектировать
    1. Код взаимодействует с большим количеством другого кода, чем ожидалось (то есть архитектура системы строилась на очевидно более простых требованиях)
    2. Откладывается реализация большего количество требований, чем ожидалось (то есть гибкость решения очевидно меньше необходимой)
    • 0
      Могу предложить Вам еще один критерий, когда поможет рефакторинг — когда вы возвращаетесь к исходному коду с целью добавить новый функционал или исправить существующий спустя некоторое время и сталкиваетесь с непониманием механизмов его работы, даже если этот код — ваш.
      Одна-две итерации рефакторинга помогут намного глубже понять и восстановить в памяти суть работы класса, чем простое чтение исходного текста. А заодно в код вносятся изменения для самой цели рефакторинга — облегчить понимание на будущее.
  • +3
    О, спасибо, потом почитаю.
    • 0
      TODO
      ловушка №8 =)))
    • –1
      Ваш комментарий он не оптимален, у него есть лишние символы. Мне обязательно нужно написать свой, с бриджем и библиотекаршами:
      Потом почитаю.
  • +3
    Или обобщённо — избегайте любых крайностей. Если хотите работать эффективно.
    Но если хотите стать великим программистом (или сойти с ума) то доходите в своей крайности до исступления, до истерики.

    Однажды к великому учителю дао программирования пришёл ученик и спросил его — Что мне делать, учитель? Я достиг просветления и не попадаю ни в одну из восьми ловушек программирования. Учитель молча допил свою третью чашку кофе, потом взял старый системный блок и со всей силы ударил им ученика по спине. А потом сказал — Так пойди и придумай девятую ловушку!
  • 0
    Спасибо! Хорошая статья.
    Как по мне так не хватает еще одной ловушки — попытка усидеть на ВСЕХ стульях сразу. Когда стараешься контролировать и проверять абсолютно все, переписываешь пусть работающие но написанные не тобой куски кода, злобная защита своих тактик и стратегий даже в ущерб движению проекта вперед.
    • +1
      > переписываешь пусть работающие но написанные не тобой куски кода, злобная защита своих тактик и стратегий даже в ущерб движению проекта вперед.


      Для этого даже придумали название — «Фатальный недостаток» или синдром «Изобретено не здесь» («Not Invented Here», «NIH»): lurkmore.to/_/18209#mws_YKMWJf/
  • +9
    Золотой молоток — это вредная привычка. После того, как какой-либо метод сработал при решении нескольких задач, попавшийся в ловушку начинает использовать этот метод везде, где только можно!

    Есть несколько схожих терминов — панацея, волшебная таблетка, серебряная пуля, т. е. такой метод, который всегда, в 100% случаев выполняет любую задачу. Ещё одна имеющая к этой теме поговорка — забивать гвозди микроскопом.

    Золотой молоток — довольно часто встречающаяся, но совершенно непохожая на другие ловушка. Золотым молотком может быть всё что угодно, кто-то может влюбиться в ООП и писать классы на каждый чих, кто-то в паттерны проектирования и построить программу из одних лишь фабрик и синглтонов.

    Для кого-то золотой молоток — это любимый язык программирования, для кого-то — любимая парадигма, для кого-то — методология разработки.

    Главное, что выделяет золотой молоток — попытка использовать его всегда и везде.

    Признаки того, что вы в ловушке
    • Использование одного языка программирования для всех задач
    • Вера в то, что одна парадигма может решить все проблемы программирования (чаще всего так говорят про ООП и ФП)
    • Использование для всех проектов, независимо от условий, одной методологии разработки, например бездумное использование TDD во всех проектах
    • Применение какого-либо средства, предоставляемого языком для большей части задач, например:
    – Передача всех аргументов только по константной ссылке
    – Использование во всей программе лишь одного типа коллекций, скажем массивов (векторов)
    – Использование повсюду немутабельных объектов
    – Использование в похожих по синтаксису языках (например Java и C) одного стиля отступов и метода наименования сущностей

    Серебряной пули не существует

    Я боюсь, что эта ловушка — исключение из правил и возможно ее избежать не рискуя попасть в другую.

    Это исключение из замеченной мною закономерности еще раз доказывает, что золотого молотка не существует — мой метод описания ловушки как двойственной сущности дал осечку, но я не боюсь отказаться от его использования.

    Это и есть правильный путь освобождения из этой ловушки.

    А по-моему, Вам просто изменила фантазия. У верующего в золотой молоток есть своя противоположность — это такой программист, который искренне верит, что для решения очередной задачи ему не достаточно просто подыскать готовую библиотеку на привычном языке программирования (а если готовой нет, то доработать одну из существующих или сочинить собственную), а обязательно придётся также:

    • использовать другой язык программирования (лучше всего — не известный ему ещё позавчера);
       
    • отказаться от какой-нибудь хорошо работающей парадигмы — например, отказаться от ФП, а вместо ФП самостоятельно от руки записывать все циклы для обхода массивов с целью изменения (или фильтрации, или поиска, или аккумуляции) элементов в них;
       
    • покрывать свой код тестами невчерашним способом — например, вместо BDD попробовать обычную TDD;
       
    • вместе с языком (даже если в нём нет значащих пробелов, как в CoffeeScript каком-нибудь) непременно сменить и свой стиль отступов — например, начать ставить пять пробелов вместо четырёх или добавлять по пробелу до и после каждой скобки;
       
    • сменить IDE, VPN, операционную систему, страну проживания, вероисповедание, ориентацию.

    Для себя и для проекта такой программист неудобен тем, что сам себе усложняет задачу.

    На Хабрахабре такой программист неудобен тем, что кидается на людей, которые на языке X решают задачу Y вместо того, чтобы перейти на язык Z, который по мнению этого программиста является наиболее удобным (в ещё более тяжёлых случаях — единственно возможным) для решения задачи Y.
    • +5
      У вас слишком длинный комментарий, написанный на неудобном языке. Комментарии всегда должны быть короткими и на английском. Кто вообще использует списки в комментариях? Это же признак непрофессионализма!

      Вы срочно должны перейти на английский язык и писать комментарии только на нём. И только краткие!
      • +14
        Рекомендовать Мицголу перейти на английский язык — за гранью добра и зла.
        • +1
          Латынь через слово будет вставлять?)
        • +2
          О боже, я так хочу это увидеть!..
    • 0
      Тоже сразу возникло возражение. Противоположность золотому молотку, это попытка взять два инструмента в одну руку.
      Видел случаи, когда в одном проекте часть моделей описана классами, другая часть загружается из XML без явной на то причины, а просто «я так могу», когда половина проекта общается с базой через NHibernate, другая через Linq2Sql, ну и так далее.
    • 0
      Это Сцилла и Харибда в программировании. Либо мы уходим в одну крайность, либо в другую. Труднее всего — придерживаться золотой середины. А не держаться за золотой молоток.
  • +1
    В итоге всё, так или иначе, сводится к замечательной польской поговорке:
    Со za nadto, to nezdrowo — Что чересчур, то не идёт на пользу
  • 0
    По-моему, «Золотой молоток» aka «Серебряная пуля» в списке лишний. Точнее, весь список можно свести к Золотому молотку.
  • +2
    Жаль только, что эта машина — не Hammer, а Hummer.
  • –2
    И наоборот — некоторые программисты пишут софт, который запустится только на той-же ОС, что и у автора, более того, нужна точно такая-же мышь, клавиатура и шлем виртуальной реальности.

    Автор из будущего.
  • 0
    А есть похожая статья на английском, очень хочу коллегам показать?
    • 0
      Нет, к сожалению на английском я пишу плохо (хуже чем на русском).

      Не буду против если кто-нибудь захочет перевести и опубликовать версию на любом другом языке.
  • +2
    Стремление к совершенству

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

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

    Вы это подразумевали? :)
  • +4
    Глава об абстракционизме была бы не полной без знаменитой теоремы.
    Почти любую проблему в коде можно решить ведением дополнительного уровня абстракции. Исключение составляет проблема слишком большого количества уровней абстракции.

    Доказательства не помню :)
  • +1
    Так можно очень много ловушек придумать.

    1. Менеджмент. Крайности: пытаемся следить за каждым шагом подчиненных (микроменеджмент), не следим за программистом вообще (do whatever)
    2. Логи. Крайности: либо логируем всё (каждый вызов метода, каждый переданный параметр), либо логируем вообще ничего
    3. Классы. Крайности: god-классы со 100500 методами, все классы мелкие (один метод максимум, на каждый чих создаётся класс)
    4. Интерфейсы. Крайности: выделять всё что можно в интерфейс, не пользоваться интерфейсами вообще
    5. Форматирование кода. Крайности: всё строго по спецификации (даже если смотрится некрасиво), отсутствие форматирования (в коде каша, табы перемешаны с пробелами и т.д.)

    и т.д. и т.п. насколько хватит фантазии…
  • +1
    Стартап копирайтера удался. Хабр, ты ослеп????..
  • +1
    Вера в то, что O(n) вместо O(n^{2}) или замена всех операций умножения на 2 на побитовый сдвиг сделают из программы конфетку

    Мне кажется, что по поводу O(n) против O(n^2) вы все таки утрируете. Как только количество элементов чего-либо перевалит за 10000 (а это 100% случится благодаря Мерфи), то O(n^2) вылезут даже не боком, а более жестко )
    Конкретно в этом примере, такие «узкие» места всегда должны подвергаться оптимизации и сразу. Одна из основ теории алгоритмов — избегать O(n^2) любыми способами.

    А вот по поводу умножения на 2 — вполне согласен.
    • 0
      Тут ключевые слова — «сделают из программы конфетку».

      Никто не спорит, что сложность алгоритмов очень важна и я согласен с Вами, насчет О(n) против O(n^2).

      Но это не самое главное в программировании. И использовать лучшие алгоритмы недостаточно для написания хорошего продукта.
      • +1
        Получается вы попадаете в свою же ловушку, если будете пропускать даже O(n^2), то есть в «запоздалую оптимизацию» следуя вашей терминологии. Конфетку, конечно же O(n^2) не сделает, но в то же время может превратить ваше детище в шлак.
        Есть вещи, которые все таки нельзя нарушать, ну к примеру тот же $i <= array.count() прямо в цикле. Они являются признаками плохого кода.

        Для меня главный посыл статьи = не заморачиваться ни в одну, ни в другую сторону. Как говорил Гай Кавасаки: продукт должен быть good enough. То есть не идеальным, но и не черти чем.

        Дело в том, что кто-то после прочтения об O(n^2) может подумать, мол а меня-то в универе за это гоняли и я-то дурак заморачивался, а оказывается можно и так. И эти семена взойдут в нехороший урожай)

        В общем, я все таки против O(n^2) — и не в «конфетке» все таки дело.
        • 0
          Да все верно. Вы не верите, что О(n^2) сведет на нет все старания, но в тоже время не оставите такую «преждевременную» оптимизацию на потом.
  • +1
    По поводу оптимизации: разумеется побитовый сдвиг и вставки ассемблера — это оверкилл. Но пример со сложностью алгоритма O(n) vs O(n^2) неудачный, если мы говорил об обработки большого кол-ва данных. Я бы сказал, что допущение субоптимального алгоритма возможно только если оптимальный алгоритм либо гипер-сложен, либо нечитаемый (при условии, что общее время его выполнения остаётся приемлимым). Я не согласен с тем, что только академикам это надо :)
  • +1
    По поводу перфекционизма:
    • Вера в то, что главное в коде — красота, читаемость и поддерживаемость
    Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности), т.к. если мы говорил о долгосрочных Agile-проектах, где классы не пишутся один раз и навсегда, кол-во затраченных часов на определённую модификацию (а значит и затраченные деньги) зависят как раз от этого.
    • Поиск недостатков в любом коде
    Я обычно делюсь всеми найденными недостатками с коллегами. Это уроки, которые должны делать каждый следующий кусок кода лучше. Разумеется, мы не говорим о крайности, когда человек только ищет недостатки вместо выполнения своей работы.
    • Вера в то, что возможно написать идеальный код за разумное время
    Неидеальный, но близкий к идеальному код можно написать за разумное время. Тут важен систематический подход. У многих код получается некачественным из-за того, что вместо того, чтоб начать с высокоуровневого дизайна, они начинают клепать прототипчики с костылями, допиливают его до работоспобного состояния и далее, устав, оставляют свою поделку на века долгие.

    Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода, а не круглосуточному изучению каждого коммита в code-base.
    • 0
      Мой опыт мне показывает, что как раз главное в коде — читаемость и поддерживаемость (при условии его работоспособности)

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

      Поиск недостатков в любом коде

      Иногда, согласитесь, нужно мириться с недостатками, особенно, если код чужой, тем более, что кажется одному хорошо, другому — недостатком (как пример я работаю в паре с одним программистом, ему кажется, что мутабельные объекты это нормально, а мне кажется, что это недостаток (когда можно без них)).

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

      Значит идеальный нельзя таки.

      Я понимаю, что автор подразумевает посвящение избыточного кол-ва времени на всё это, но перфекционизм не так плох, если это выражается в высоких требованиях к качеству кода


      Да, Вы меня правильно поняли.

      Спасибо за Ваше мнение, я обязательно учту Ваши пожелания при написании следующей статьи.
      • 0
        Хочу добавить по поводу недостатков.

        Есть спорные ситуации, где имеют место быть разные мнения и предпочтения, например те же маркер-интерфейсы — кто-то их любит, я считаю их исторической издержкой в случае языка с поддержкой аннотаций или «аттрибутов» в терминологии .NET. Есть правда у них некоторые технические ограничения связанные с наследованием, но суть не в этом.

        А есть объективно неверные решения. Примеры, которые я часто встречаю в своём проекте:
        код выполняется много раз повторно без причины
        метод Initialize написан с кучей всяких ненужных проверок как будто инициализацию собираются делать много раз, но это не так
        полный хаос с модификаторами доступа, одни паблики кругом. И всё это вынесено в интерфейс
        Есть много других примеров.

        Я всегда стараюсь допускать альтернативные точки зрения в области разработки, но эта точка зрения должна быть обоснована. Если аргументы за отсутствуют (недостаточно продебагили, копи-пасты кода или просто непонимание элементарных принципов ООП), то это недостаток и надо на них указывать. Моей мотивацией это делать не является показать своё превосходство над остальными или как-то их унизить. Всё намного проще. :) Мне потом работать с этим всем и возможно придётся долго поддерживать code-base. Поэтому я стараюсь заранее облегчить себе жизнь, ну а кому-то может будет и опыт.
  • 0
  • +1
    Суммируя всё вышесказанное в статье и всё ниженаписанное под ней в комментариях, можно выделить две ультра-крайности.

    Параноик (Консерватор)

    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. Уверенность в своей непогрешимости, нежелание вообще заниматься самоанализом
    • 0
      Госспади! Да не дай бог такие в жизни встретятся… тем более друг другу. Они ж взаимно убьются!
      • 0
        Провел самоанализ — да я тогда вообще тот еще индивид.
        1. Чрезмерная оптимизация
        2. Порядок
        3. Порядок
        4. Да мне пофиг что ты там нагуглил, пока-ты ты с эти разберешся, я свое накатаю!
        5. Порядок
        6. Вера в то что «Ложки/Серебряной пули не существует»
        7. Порядок
        8. Порядок
        9. Иногда
        10. Вот за что я люблю велосипеды, так это за две вещи: они прокачивают тебя и позволяют решить задачу даже если хрен знает как ее и решать.
        11. Порядок
        • 0
          Пункт 10 прямо в точку)

          Да, кстати, а многие эти «велосипеды» даже сломать пытаются. Наверное из зависти)
  • 0
    Всё здорово, спасибо за статью, но для полного счастья не хватает ловушек, которые касаются уже не только кодирования, а к примеру документирования (тогда как оно, особенно учитывая существования автоматической генерации документации проекта по коду, имеет отношение к кодированию всё-таки) далее — манеры общения с заказчиком по ходу работы, а также разработки собственно пользовательского интерфейса, это — именно то, что в конечном счёте видит перед собой пользователь. Это то, что — в конце концов — продаётся, кормит программиста и значит его нельзя не отнести прямо к программированию.
    Здесь, конечно, в конечном итоге всё также сводится к соблюдению меры, тем не менее, было бы совсем хорошо, если бы эта статья дополнилась систематизацией ловушек из упомянутых областей.
    • 0
      Я думал об этом, но если вы посмотрите, то статья итак довольно длинная, у меня был небольшой выбор — либо больше ловушек, но покороче, либо больше информации о каждой ловушке, но ловушек меньше.

      Я выбрал что-то среднее и в конечном итоге, последнюю запланированную ловушку даже пришлось убрать.
  • –1
    Главная ловушка программирования в том, что оно довольно интересно. Поэтому вместо того, чтобы прокачивать социальные навыки и мутить денежные замуты, молодые люди погружаются в программирование с головой. А когда выныривают после 30, оказывается, что ипотека, кредитный фокус и жена-жируха вовсе не предел мечтаний. Sad but true. Минусуйте — пофигу. Я, к с частью, выбрался :)
    • 0
      Отчасти правы, но лишь отчасти. В этом посте идет дискуссия про программирование, а не человеческие качества программиста! Безусловно программист прежде всего человек, но это тема другой дискуссии!
  • 0
    Все эти статьи будто повторяют одно и тоже. Какие-то ощущения, что за этим всем стоит какой-то общий смысл. Программирование просто выражает его по-своему. Видимо, что-то вроде, что чем больше качества, тем дольше; чем меньше качества, тем быстрее.
    • 0
      Это называется великий треугольник — производство, равно как и производимый продукт, может обладать тремя характеристиками: быстрое, качественное, дешёвое. Но можно выбрать только любые два.

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