Как разработчику справиться с проектом в одиночку. Советы из опыта

Привет! Меня зовут Юлия Дон, я работаю .NET-разработчиком более трех лет, и недавно мне выпала возможность стать единственным девелопером на проекте. Опыт получился интересный, и я решила поделиться им с вами.

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

Иллюстрация Алины Самолюк

Начало карьеры

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

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

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

Мы занимались этим проектом несколько лет и, когда на определенном этапе поняли, что в продукт добавить больше нечего, отправились работать в большие украинские ІТ-компании.

Я устроилась в Customertimes на крупный проект по разработке ПО для документооборота и торговли сырьем на бирже. Для меня это была совершенно новая сфера, о которой я раньше знала поверхностно. Именно это делало для меня проект невероятно увлекательным. Нас было пятеро разработчиков на проекте: я — Middle и четыре Senior.

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

Я один на один с проектом

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

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

Этот путь оказался непростым. У меня на тот момент не было опыта веб-разработки, я занималась только десктоп-приложениями и бэкенд-разработкой. Поэтому поначалу мне приходилось сражаться с JavaScript (какое-то время он побеждал, но со Stack Overflow и документацией в союзниках я потихоньку стала получать преимущество).

Сперва я выполняла задачи по исправлению багов, что помогло понять структуру проекта и вникнуть в его особенности. В ходе работы я разобралась не только с архитектурными особенностями приложения, но и с сопутствующими технологиями, такими как Angular, jQuery, MongoDB, AWS, с каждой из которых мне приходилось работать впервые.

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

Кроме того, на проекте использовалась база данных MongoDB, которая местами существенно отличается от привычной мне MS SQL. Запросы пишутся иначе, и при каждой малейшей правке в базе необходимо было обращаться к документации. Так как разработчика БД на проекте не было, правки в базе, в том числе на проде, были на мне.

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

Мне также пришлось разобраться с инструментами AWS и TeamCity. Раньше я решала несколько незначительных задач по CI/CD, но на тот момент работала с коллегами, которые были готовы помочь и подсказать то, что непонятно. В этом же случае мы остались с деплоем один на один. Однако благодаря использованию TeamCity с особыми сложностями я не столкнулась. Все, что мне нужно было сделать, оказалось простым в изучении.

Ответственность за весь проект

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

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

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

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

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

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

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

Самостоятельное решение проблем

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

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

Понимание всего проекта

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

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

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

Отсутствие код-ревью

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

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

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

Отсутствие митингов

На моем проекте совещаний не было вообще. У меня в команде был PМ, с которым мы переписывались, DevOps, который занимался в основном другим проектом — с ним мы созванивались за четыре месяца примерно три раза по 10 минут, и тестировщик, вопросы с которым тоже можно было успешно решить в переписке.

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

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

Гибкий график

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

Несколько советов

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

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

Сохранять доступы к инструментам, которые используются для разработки и деплоя (например, сервер, TeamCity, БД) и особенности развертывания приложения локально. При ознакомлении с проектом мне приходилось обращаться к заказчику, чтобы он уточнял креды у предыдущих разработчиков. Затем в ходе работы появились частности, известные только мне. Не стоит надеяться, что вы все удержите в голове. Лучше перестраховаться и записать их. Это существенно упростит передачу дел при расширении команды или при уходе с проекта.

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

Выводы

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

Я брала на себя роли веб-разработчика, разработчика баз данных, тестировщика и DevOps. Но со временем могут возникнуть риски торможения в развитии своих навыков. Очень динамический рост происходит вначале в силу незнакомого проекта и, как в моем случае, незнакомых технологий. Но при построении архитектуры приложения отсутствует критический взгляд других разработчиков. Даже если ты Senior с опытом разработки 10+ лет, твой опыт все равно не покрывает весь спектр существующих технологий, которые можно было бы применить в рамках разработки нового функционала.

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

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU