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

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

Взгляд назад

Я работала веб-разработчиком и ранее, но в начале прошлого года поняла, что недовольна своей карьерой. Я не могла понять, почему так происходит, пока не прочитала статью Three types of programmers, которая перевернула мой взгляд:

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

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

• Если происходит сбой, его нужно исправить;
• “Нам нужно начать промоакцию в понедельник”, поэтому работать нужно все выходные;
• “Мы перенесли все на новый сервер, интеграция сработает, верно?” — “Дайте мне доступ, я проверю настройки.”

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

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

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

Новая работа

Оказалось, что этот проект начался ещё в 2014. В проекте использовались Rails 4.1 и Ruby 2.2.3, а также было много технических проблем, которые не были исправлены уже год. Ничего не тестировалось уже долгое время: в папке было только несколько тестов, и они явно были написаны на ранних стадиях проекта.

Помимо технических проблем, сложности были и с менеджментом. Процесс разработки был разделен на несколько команд, а дедлайны и требования игнорировали реальные возможности программистов. У разработчиков было время только на написание кода. Фазы размышления о стратегии, тестирования и устранения багов были оставлены в стороне. Более того, старые части кода не рефакторились, потому что на это не было времени. Такие проблемы распространены, и многие иногда с ними встречаются. Что тогда стоит делать разработчикам? Или…

Как справиться со всем этим?

Существует два уровня проблем: проблемы на уровне компании или проекта и персональные проблемы с уровнем навыков и организацией работы.

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

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

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

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

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

2. Нехватка времени на тестирование

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

3. Недостаточная спецификация задачи

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

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

4. Ревью кода в конце задачи

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

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

5. Я не вижу для себя возможности развития

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

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

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

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

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

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

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

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

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

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

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