10 привычек программистов, которые тратят ваше время

Эффективность – ключевая характеристика действительно хорошего программиста. Но некоторые привычки и распространенные практики безжалостно “съедают” львиную долю вашего рабочего времени — они не приносят пользы, а иногда заставляют просто все переделывать.

Как избежать таких ловушек, тратящих время, рассказал разработчик Арслан Мирза в блоге на Medium. Публикуем адаптацию текста.

Представьте себе, что, будь программирование магическим заклинанием, а программисты были бы волшебниками-колдунами, а баги были бы теми непослушными чертами, которые пытаются опустошить наш цифровой Шангри-Ла. Но, к сожалению, программирование — это не магия (или так?). Это увлекательное ремесло – коктейль логики, креативности и настойчивости.

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

I: Комментарии к коду — Непонятный монстр

Комментирование кода, да? На бумаге это прям Гендальф кодирования, ведущий нас через темные копи Мории. Однако чрезмерное или некорректное комментирование больше похоже на то, как Гендальф вводит нас в Балрог (т.е. в какую-то ср*ку).

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

Многие комментарии могут отвлечь внимание и запутать. Нужно ли комментировать каждую строку кода как диктор спортивного матча? Абсолютно нет! Код должен быть написан так, чтобы он говорил сам за себя.Чрезмерное комментирование может являться признаком плохо структурированного кода, который труднее понять.

Запомните: комментарии должны прибавлять ценность, придавать контекст и объяснять «почему», а не только «что» код делает. Соблюдение правильного баланса здесь – это большее искусство, чем наука.

II: Перфекционизм — Иллюзионист

Стремление к совершенству может показаться благородным, почти как попытка поймать золотого снитча в Квиддиче с высокими ставками. Но, как и неуловимый крылатый мяч, совершенство кода часто является иллюзией. Это нормально, если ваш код не выглядит так, как будто его написал сам Господь. Важно, чтобы он был читабельным, пригодным для обслуживания и эффективным.

Чрезмерная оптимизация – еще один волшебный зверь из того же семейства. Вы, вероятно, слышали о преждевременной оптимизации — и да, это не просто миф. Это все равно, что пытаться зачаровать метлу, чтобы она двигалась быстрее, когда у вас даже нет свободного пути для полета. Сначала сосредоточьтесь на правильном функционировании, а затем оптимизируйте, если необходимо.

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

III: Игнорирование маглов (непрограммистов)

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

Относитесь к тем, кто не программист, как к своим товарищам по колдовству, а не как к маглу, который ничего не знает о магии.

Найдите общий язык, объясните ограничение вашего кода или почему реализация определенной функции может занять больше времени, используя метафоры или примеры, понятные специалистам-непрограммистам. Это все равно что объяснять, как работает сеть Floo, кому-то, кто пользовался только Knight Bus.

Убедитесь, что эффективная коммуникация заключается не в применении заклинаний Confundus Charm, а в том, чтобы все были на одной магической карте. Чем больше ясности, тем более плавным будет ваше программирование.

IV: Неиспользование магических инструментов (библиотеки и фреймворки)

Зачем пытаться сварить сложное зелье с нуля, если в вашем распоряжении готовое? Подобным образом кодировка каждой функции с нуля – это все равно, что пытаться изобрести новую метлу, когда в вашем шкафу есть великолепный Nimbus 2000.

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

V: Пренебрежение личной жизнью

Вы можете спросить: «Как личная жизнь попала в список практик программирования?». Но волшебный мир — это не только заклинание, не правда ли? Пир в Большом зале, товарищеская игра в Квиддич и посещение Хогсмида – разве не все это часть магии?

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

Работа по ночам, пропуск приемов пищи, пренебрежение физической активностью или общением с людьми “не с IT” может показаться программистским обрядом посвящения. Однако в долгосрочной перспективе эти практики губительны.

Вы можете тратить больше времени на отладку из-за ошибок, допущенных из-за усталости или растерянности. Итак, будьте добры к себе: делайте перерывы и не забывайте о жизни вне кода.

VI: Пропуск фазы планирования

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

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

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

VII: Настройка без понимания проблемы

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

Представьте, что во время дуэли вы используете заклинание, не понимая стратегию атаки соперника. Звучит опасно, верно?

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

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

VIII: Обзор кода

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

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

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

IX: Неиспользование преимуществ автоматизации

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

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

Автоматизируя повторяющиеся задачи, вы экономите драгоценное время и уменьшаете количество ошибок, которые могут возникнуть из-за усталости человека. Инструменты автоматического тестирования, такие как JUnit или Selenium, инструменты CI/CD, такие как Jenkins или Travis CI и инструменты форматирования кода, такие как Prettier или ESLint, являются примерами ваших преданных домашних эльфов. Используйте их с умом и увидите, как ваша производительность вырастет.

X: Многозадачность и переключение контекста

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

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

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

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