5 советов, как сохранять качество кода и развиваться, когда всем вокруг плевать

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

Немного ретроспективы

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

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

Язык программирования (а точнее язык + инструменты + инфраструктура + сообщество) навязывает способ мышления, и удовольствие разработчика от работы и его продуктивность сильно связаны с тем, насколько способ мышления разработчика соответствует способу мышления языка программирования и экосистемы, с которыми ему приходится работать.

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

Но когда я вышла на работу, красота ушла в тень. Оказалось, что заказчику не важно, за счёт чего работает система. Вместо этого ему надо:

1. Чтобы работало правильно;
2. Чтобы было сдано в срок (часто это означает "ещё вчера");
3. Чтобы было красиво снаружи (интерфейс).

Вместо радости от создания красивых текстов и совершенного кода — рутина и тлен. Так и живём:

• Упало — поднимаешь;
• "У нас акция стартует в понедельник" — сидишь на выходных, доделываешь;
• "Мы тут на новый сервер переехали, интеграция же будет работать?" — "Давайте доступы, буду все настройки проверять".

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

Хочу стать Rails разработчиком!

И вот, вдохновившись статьёй Виктора, я начала осваивать Ruby. Он вернул мне радость от программирования.

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

Я укрепилась в своём решении перейти с PHP на Rails. Можно сказать — начать свой путь программиста с чистого листа. Наконец перестать жертвовать качеством кода из-за жестких требований бизнеса. Переходя на новый язык, я решила приучить себя использовать best practices. Это значило всегда тестировать свой код, выделять себе достаточное время на обдумывание решения, пользоваться передовыми технологиями. Таким образом я перестану быть чернорабочим, я буду оттачивать мастерство. А с ростом мастерства будет расти моя радость и моя ценность. Таков был мой план.

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

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

В среду вечером я пришла на собеседование, а в четверг в 10 утра меня ждали в офисе с ноутбуком. Сказав, что знания у меня “чуть-чуть не дотягиваешь до джуниора”, меня взяли на проект, добавив, что "у нас не хватает рук" и "будет классно, если ты справишься".

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

Трудовые будни

Первый рабочий день был полон неприятных сюрпризов. Оказалось, что проект, на который меня позвали, начался аж в 2014 году. Думаете, это означает, что он большой и сложный? Правильно думаете. А ещё он старый. Я открыла код проекта и обнаружила там Rails 4.1 и Ruby 2.2.3.

Моё знакомство с проектом началась с создания пустой базы данных. Но попытка прогнать миграции завершилась ошибкой. Когда база была залита из дампа, я попыталась установить gems. И снова провал. В Gemfile есть ссылки на конкретный коммит на гитхабе с пометкой “поправить, когда зальют этот коммит в основную версию”. Коммит уже год как залили, но никто так не поправил. А заглянув в папку с тестами, я поняла, что тестированием тут уже давно никто не занимается. Тесты есть, но их мало и видно, что их писали в самом начале проекта.

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

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

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

Как в этом выжить и не превратиться в говнокодера?

Очевидно, у нас есть два уровня проблем:

1. Проблемы на уровне фирмы/проекта;
2. Личные проблемы на уровне навыков и организации собственного рабочего процесса.

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

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

Даже вариант писать качественный код для себя, а на работе “закрывать задачи” ведёт туда же: к формированию устойчивого плохого шаблона поведения. Ведь количество рабочих часов, как ни крути, превышает количество часов, когда программируешь для себя. А значит нужно что-то решать.

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

1. Большой незнакомый проект

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

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

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

2. Мало времени на тестирование

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

3. Неполное ТЗ

Часто случается так, что некоторые требования к задаче выясняются уже на этапе разработки. Помимо этого, есть пропасть в понимании между тем, как выглядит интерфейс и тем, как всё это на самом деле работает. Когда менеджер не осознаёт величину этой пропасти, он ставит невыполнимые задачи, либо негодует “почему эта мелочь заняла так много времени”. Меня это раздражает.

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

4. Код-ревью в конце задачи

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

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

5. Нет понятного пути развития меня как программиста

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

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

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

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

Для себя же я решила так: мне нужен ментор, чтобы повышать эффективность в работе. Вы можете спросить: у тебя же куча коллег вокруг, почему именно ментор? Дело в том, что коллеги часто настолько заняты своими задачами, что им просто некогда. Кроме того, ментор может решить стратегические задачи вашего развития. Тогда как соседи по рабочему столу подсказывают как сделать, чтобы работало.

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

Проблемы на уровне фирмы

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

Я пока ещё не руководитель и сужу, скорее всего, с дилетантской позиции, но на мой взгляд любой фирме, связанной с разработкой, в первую очередь стоит уделять внимание следующим моментам:

• Растить кадры на регулярной основе;
• Определить понятный и работнику, и работодателю путь профессионального развития внутри компании (и речь не только о карьерной лестница, но и о качестве навыков) ;
• Не оставлять ответственность за проблемные проекты только на плечах разработчиков.

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

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

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

Дело в том, что нет универсального ответа на вопрос: “Что сделать, чтобы специалист рос?”. Кто-то прекрасно учится через коммуникацию с другими: пришёл в фирму и достаёт всех вопросами днём и ночью. И этого ему будет достаточно, чтобы вырасти. Бывает, не всегда есть возможность много спрашивать у коллег, они заняты или банально работают на другом проекте, а вопрос специфический. Если человек упёртый, он погуглит, спросит знакомых, перероет весь гитхаб, но решит проблему сам.

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

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

На ком лежит ответственность

Я думаю, что как и в любых отношениях — “всегда виноваты оба”. Но при этом, нужно смотреть на уровень сознательности обеих сторон. Приходя работать в коллектив, очень хочется попасть в тепличные условия. Где тебя лелеют, вовремя мотивируют и ты сам собой развиваешься. Это наивная и достаточно детская позиция. В то же время, если я всё буду делать сама, то зачем мне наши рабочие отношения? Есть варианты работать самой на себя, но для чего-то ведь мы собираемся в команды? И во многом — затем, чтобы не протухнуть сидя дома, делая какие-то однообразные задачки с фриланс-биржи.

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

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

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