Сколько раз при написании кода вам приходилось начинать все сначала? Сколько раз вы делали рефакторинг, пересматривали или переписывали ту единственную функцию, которая каждые пять минут ломалась? Технический директор Infinum Желько Плесац рассказывает на портале TechBeacon о важности чтения кода, написании документации и других деталях, которые упрощают разработку ПО.

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

1. Придумывание на ходу

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

2. Беглое изучение документации

Алгоритмы, э-письма, README, отчеты по проекту — всего этого может быть слишком много. Вы просто хотите писать код! Но документация вашего проекта — это не место для легкомыслия. Известно, что разработчики плохо читают код; исследования показывают, что читать код гораздо труднее, чем писать его. Поэтому, если есть хоть малейший шанс, что кто-нибудь увидит, использует или отладит ваш код в ближайшие 10 лет, напишите документацию. Это займет у вас не так много времени, но оно того стоит. Распространенная ошибка программистов — подключить зависимость или библиотеку, не удосужившись прочитать документацию. Stack Overflow и MDN Web Docs — чрезвычайно полезные ресурсы, но девять разработчиков из десяти найдут все, что им нужно, прямо в документации.

3. Излишняя привязанность к продукту

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

4. Неправильные коммуникации

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

5. Поручение всей работы зависимостям

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

6. Попытка изобрести колесо

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

Замедление приводит к ускорению

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