Ошибки разработчика. Кейсы, как делать не надо

Меня зовут Павел, я сооснователь компании Stan’s Assets from KAPPS, и уже более 5 лет я работаю с Unity-проектами. За свою карьеру мы все совершаем много ошибок в своей работе, и часто многие разработчики их повторяют.

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

Неправильная эстимация задач

Казалось бы, это очевидная вещь, но почти у каждого второго разработчика даже Senior-уровня есть проблемы с эстимацией задач. Хочу в пример привести небольшую историю. Однажды мы нашли неплохого разработчика для нового проекта. Но в какой-то момент начали замечать, что человек не справляется, буквально «андерстимейтит» (то есть недооценивает сложность задачи и затягивает сроки). Мы видели, что для него это стресс, и пытались разобраться, в чем же проблема.

В какой-то момент услышали фразу, что вследствие стала нашим корпоративным мемом: «Я чувствую, что на меня оказывают моральное давление, потому что эстимейт нужно предоставить в часах». Разработчик предложил делать его в уточках, звездочках, либо же сердечках :) Да, история похожа на анекдот. Но она иллюстрирует то, как сложно иногда бывает оценить время работы и результата выполненных тасков. И когда задачи становятся более сложными, то оценки работ становятся куда более нетривиальными.

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

И чем более эти задачи атомарные, разбитые на какие-то неделимые участки, тем точнее вы сможете дать по каждому из них эстимацию. А соответственно общая эстимация будет суммой всех этих эстимаций. Мы описали подход, который называется WBS (work breakdown structure).

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

Преждевременная оптимизация кода

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

И представьте себе ситуацию, когда я объявляю 3-5 переменных (bool-флаги, integer-счетчики) очень высоко, потом у меня идет код, потом цикл for. При чтении такого кода потерять из контекста все эти переменные очень легко еще до момента, когда доскролил до самого цикла.

Такая рьяная позиция нашего разработчика была обусловлена тем, что он не совсем понимал, как работает компилятор того же C#. То есть до конца не осознавал, что фактически на устройстве выполняется не совсем тот код, который был написан нами на C#. Это значит, что если мы объявляем переменную внутри цикла for, то это не значит, что компилятор представит ее в том же виде после компиляции в IL (intermediate language) или C++ код (при использовании IL2CPP scripting backend).

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

Почему moonwalk — это плохо

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

Хочу поделиться опытом знакомого, который рассказывал о забавном случае. Однажды в его команде работал девелопер, который начал часто пропадать и объяснять свои пропажи разными причинами: то он ушел лечить зубы, то проспал, то опоздал и т.д. А потом он и вовсе исчез: перестал появляться в рабочих чатах, соцсетях, переписках. Очевидно, что парень просто в какой-то момент сделал выбор между двумя работами и выбрал другую компанию.

Если говорить на чистоту, то совмещать несколько full-time работ — это тяжело, и точно нерабочая история на длинной дистанции. Таких разработчиков называют moonwalkers. И помимо последствий для проектов скорее всего они встречаются с внутренним выгоранием и убивают свою же продуктивность на месяцы, может и годы. А всплывает это очень быстро. И хотя в краткосрочной перспективе это кажется заманчивым — получить не одну зарплату, а две — это быстро закончится, а вот последствия как для карьеры, так и для собственного состояния придется разгребать еще долго.

Почему фейлятся билды

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

Вспомним проект Ori WotW. Репозиторий проекта находился на SVN, и это накладывало множество ограничений на удобства пользования. Особенно работа в различных ветках. То есть если разработчик работал над какой-то фичей, то ему приходилось коммитить код напрямую в главную ветку develop (в которой одновременно «живет» множество артистов, дизайнеров и других разработчиков), что подвергало опасности рабоспособность текущей ветки и команды в целом. Это замедляло или даже приостанавливало работу команды до момента исправления проблемы.

Поэтому очень часто происходило так, что люди могли сломать билд по той или иной причине. В данном случае мы хотели сделать акцент не на том, как минимизировать поломки и «научить» себя коммитить код, который не сломает ветку, а, скорее, как вовремя диагностировать проблему. Существует множество разных систем для CI/CD: Jenkins, Team City, GitHub Actions и другие. Такие решения помогают автоматизировать и стабилизировать процесс сборки билдов и поступление «новых» изменений в главную ветку разработки. Ревью кода, автоматические билды, автоматические тесты и QA — это как раз те подходы, которые призваны «помешать» разработчикам сломать проект и зафейлить билд. Не забывайте об этом и тогда ваша разработка будет происходить максимально гладко!

Дизайн архитектуры проекта

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

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

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

Чем это хорошо и зачем это все нужно?

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

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

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

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

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.