Все мы хотим оказаться в идеальной рабочей ситуации: хорошая стабильная компания, высокая зарплата, интересный проект, плавное продвижение в полном соответствии с какой-то методологией разработки… И вдобавок чтобы мы как программисты с каждым днем все больше росли над собой.
На практике такое случается редко и относится скорее к категории случайностей. В каких-то аспектах приходится идти на компромиссы и чем-то компенсировать недостатки. Например, искать фирму «по себе», перебирая по одной. Или, если фирма и зарплата устраивают, но задачи отличаются однообразием, – искать отдушину в личных, сторонних проектах или хобби.
Особняком стоит проблема саморазвития. Как это ни странно, иногда на работе можно даже деградировать.
Скажем, вы новичок, вдохновившийся творением Стива Макконнела и совершенно искренне желающий писать совершенный, чистый код. Вы приходите в компанию и оказывается, что чистота кода вообще не стоит в списке приоритетов. Клиенту важно, чтобы программа работала без сбоев, была привлекательной для потенциальных пользователей и была готова завтра, а лучше вчера.
Поскольку компания старается в первую очередь максимально удовлетворить заказчика, ставятся нереальные сроки, убираются «ненужные» этапы вроде тестирования и бесконечно вносятся изменения в ТЗ, а значит, и правки в пишущийся или уже почти написанный код.
Разделение труда между отдельными командами приводит к тому, что кто-то вынужден простаивать в ожидании результатов труда коллег, а потом стараться самому успеть к дедлайну.
Нехватка времени не позволяет переписывать старые части кода: их просто «латают». Особенно это заметно в проектах, начатых еще несколько лет назад.
Отношение к развитию разработчиков
Как нужно организовать процесс, чтобы разработчики постоянно развивались, – важный вопрос, не имеющий однозначного ответа.
Прежде всего, все люди разные. Кто-то обладает развитыми софт-скиллами и будет учиться, выпытывая информацию у коллег. Кто-то будет искать поддержки во всяческих сообществах в интернете. А кто-то вообще не станет этим заниматься, так и будет плыть по течению.
Поэтому в идеале фирма, где вы работаете, должна принимать активное участие в процессе.
В принципе, компании должны быть заинтересованы в обучении и совершенствовании своих сотрудников. На деле этого часто не происходит. Обучают только новичков на самых начальных этапах, ровно настолько, чтобы могли справляться с задачами. В дальнейшем увеличивают эффективность за счет роста количества сотрудников.
В результате все отвечают за свой кусочек работы, зачастую выполняя рутинные задачи. Это снижает общий уровень мотивации у людей, а вместе с этим и качество кода.
Как не стать говнокодером?
Можно выделить пять основных проблем, с которыми вы можете столкнуться в ходе работы и которые могут существенно ухудшить ваши шансы научиться писать хороший код.
1. Вы работаете с крупным проектом «с историей»
Если вы — новичок, а проект как раз скорее «старожил», естественно ожидать, что вам придется потратить много времени на его изучение. А это означает глубокое погружение в чужой код.
Если текущая задача требует работы с таким кодом, лучше сразу обратиться за помощью к старшим и более опытным товарищам. Например, узнать у них, какой части интерфейса соответствует этот код, или уточнить что-то, касающееся логики процессов. Конечно, с подобными вопросами нужно подходить к тем, кто сам в этом давно разобрался или (если повезет) вообще стоял у истоков.
Но если ситуация не «горящая», лучше заранее потратить некоторое время на освоение с предметной областью: составить для себя основной набор часто встречающихся терминов, найти им соответствие среди моделей и таблиц в базе данных, а также понять, как они связаны между собой.
2. Тестирование не предусмотрено
Очень часто (если не всегда) встречаются ситуации, когда сроки поджимают, и именно этот момент больше всего волнует заказчика. Руководство вашей конторы при этом хочет максимально удовлетворить ожидания клиента, а поскольку он все время говорит о сроках, то и заботиться будут именно о них. А качество? А что качество? Писать нужно сразу правильно, чтоб не пришлось тратить время на исправления!
Но факт остается фактом: продукты нужно тестировать, а тесты требуют времени. Поэтому старайтесь все же его находить. Не считаем это правильным, но тоже вариант: некоторые разработчики хитрят, изначально при планировании сроков закладывая и время на тесты, но не сообщая об их проведении, т. е., все кругом думают, что все это время – на написание самого кода.
3. «Семь раз отмерь» или что делать с бесконечными уточнениями ТЗ
Бесконечное внесение правок не лучшим образом сказывается на качестве кода. Можно ли этого избежать?
Во-первых, от уточнений ТЗ в процессе работы никто не застрахован. Во-вторых, риск больших несостыковок лучше снизить сразу. Часто бывает так, что причиной последующих претензий к срокам является недопонимание на этапе составления ТЗ. Например, менеджеру видится, что какая-то часть интерфейса реализуется быстро и легко, а это не соответствует действительности.
Также лучше заранее уточнить, всё ли есть для выполнения поставленной задачи. Если ваше задание – часть проекта, а другие части пишут другие команды, скорость вашего продвижения может зависеть и от них.
4. Обзоры кода
Обзоры кода после выполнения задачи – распространенная практика. В плане обучения это в любом случае хорошо, но в плане работы над ошибками – не совсем, ведь если ошибка вкралась где-то в начале, то придется слишком много исправлять. А если еще и сроки поджимают (как это обычно бывает), то не остается времени на обсуждение.
Поэтому лучше (по возможности) просить коллег делать ревью вашего кода частями. Это имеет особенно большое значение, если вы еще джуниор. Поступая так, вы подойдете к дедлайну в большей уверенности, что с вашим кодом все в порядке.
5. Отсутствие стратегии развития
Если в компании не уделяется должного внимания развитию сотрудников, вы можете оказаться в ситуации, когда все силы будут уходить на попытки просто оставаться на плаву. Причем, если все сотрудники находятся в такой же ситуации, вам даже не с кого будет брать пример.
Вы можете попробовать поговорить об этом со своим менеджером или, как вариант, изначально подыскивать себе компанию, где занимаются совершенствованием своих разработчиков.
Но если ваша компания к этой теме безразлична, а в целом вам там нравится и уходить вы не собираетесь, нужно начинать работать над собой самостоятельно.
Для начала составьте план своего развития. Хорошо, если ваши рабочие проекты в этот план прекрасно вписались. Таким образом вы будете уделять достаточно времени изучаемым темам и оттачивать навыки на практике. Если так не получается, придется продвигаться по своему плану в нерабочее время, а его зачастую не хватает. К тому же, тренировка на учебном проекте не заменит применение знаний в рабочих условиях.
Кроме четкого плана очень желательно иметь также и наставника. Причем коллеги на эту роль подходят плохо. Во-первых, они больше заинтересованы в ускорении процесса, чем в вашем развитии, во-вторых, у них и самих есть чем заняться в рамках этого же проекта.
Где найти себе наставника – вопрос куда более сложный (ведь мало кто горит желанием делиться с новичками своим опытом и тратить на это свое время) и решается у всех индивидуально.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]