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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выход

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

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

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

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

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

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

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

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

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

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

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

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

Для этого пункта довольно сложно подобрать общие признаки — все зависит от языка, задачи и кучи других факторов, но все же:

 Выход

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

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

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

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

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

Путь хаоса

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

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

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

Выход

Как всегда где-то посередине:

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

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

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

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

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

Лень

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

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

Трудоголизм

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

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

Выход

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

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

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

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

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

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

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

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

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

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

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

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

Выход

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

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

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

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

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

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

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

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

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

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

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

Выход

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

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

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

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

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

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

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

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

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

Выход

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

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

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

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

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

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

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

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

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

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

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

Выход

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

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

Всем удачи в ходьбе по канату!