Перевод статьи «Quitting my first job».
Недавно я уволился со своей первой работы. Думаю, это хороший момент, чтобы обдумать два прошедших года в роли разработчика веб- и мобильных приложений. За это время я довольно далеко продвинулся в развитии как навыков написания кода, так и навыков общения с людьми и сотрудничества. Надеюсь, мой опыт кому-нибудь пригодится.
В течение двух лет я был разработчиком-консультантом, моим основным языком программирования был JavaScript. Для фронтенда мы использовали React.JS, а для бэкенда – Node.JS.
По долгу службы я главным образом находился в компании одного из клиентов, и это было одно из лучших мест для человека, который, подобно мне, радуется нетривиальным задачам. Мы создали много классных вещей, но в этом посте речь пойдет не о них.
Навыки, связанные с написанием кода
Чистый код
Давать хорошие и понятные имена функциям и переменным может быть одной из самых сложных задач, с которыми приходится сталкиваться ежедневно. Это кажется довольно простым делом, пока вы пишете маленькое приложение, но все усложняется, когда с течением времени это приложение растет. А в отношении отдельных функций эта задача может быть сложной изначально.
Чему я научился на своей первой работе, так это тому, что если не уверен в каком-то имени, спроси, что на этот счет думает сидящий рядом коллега. Если, бегло взглянув на ваш код, он это имя не понимает, значит, и никто другой тоже не поймет. Можно обратиться к кому-нибудь за советом и извлечь уроки. Таким образом вы будете уверены, что выбрали лучшее имя, чем то, что придумали сначала.
Комментарии это еще не все
Можно написать десятки комментариев, но разве кто-то в дальнейшем будет их обновлять? Я согласен, что комментарий может помочь с реализацией какой-то функции: вы описываете свои шаги для себя и для человека, который придет на ваше место. Таким образом вы делитесь своими мыслями с человеком, которому придется, например, разбираться с каким-то багом. Но при этом вы полагаетесь на то, что следующий программист на вашем месте обновит комментарии, чтобы они отражали внесенные в код изменения. Когда подобного не происходит, комментарий еще больше запутывает читателя.
Я двумя руками выступаю за комментарии в сложных функциях, но их наличие означает, что при внесении изменений вам нужно поддерживать два места в программе (код + комментарии) вместо одного. Я хочу сказать, что для начала нужно убедиться, что все вещи в вашем коде имеют хорошие имена, а уж потом, если что-то по-прежнему непонятно, следует писать комментарий. Например, стоит комментировать бизнес-логику: это одна из тех вещей, которая приводит к сложности кода и при этом редко меняется.
Совместное программирование
Одна из вещей, от которых я научился получать наибольшее удовольствие, это совместное программирование без строгих рамок. Мне нравится, когда можно обмениваться идеями друг с другом. Первый человек говорит Х, а второй говорит Y, и вы это и испытываете на практике. Таким образом вы получаете представление о том, как другие люди занимаются отладкой и вылавливают ошибки.
У всех людей разные взгляды, и даже к такой логичной вещи как решение задач существует множество подходов. Это означает, что, работая совместно, мы можем учиться друг у друга наиболее продуктивным решениям.
Еще один положительный момент в сотрудничестве при написании кода – знакомство с той частью кодовой базы, которая иначе прошла бы мимо вас. Я сам порой сталкивался с этой проблемой. Люди, не знакомые с написанным мною крупным куском бизнес-логики, испытывали некоторое раздражение, когда им приходилось работать с этой частью кодовой базы.
Soft skills
Неверная оценка чужих знаний
Когда я только начинал работать, мне было сложно что-то объяснить товарищам по команде: я предполагал, что они знают предмет, о котором я говорю. Это одно из худших человеческих заблуждений, теперь я и сам не понимаю, как мог так ошибаться. В сфере технологий так много всего, о чем я не имею ни малейшего представления, что если кому-то случится объяснять мне что-то из этого на продвинутом уровне, я непременно «потеряюсь» в процессе.
Но подобное заблуждение не такая уж редкость. Одна из самых сложных вещей, которым мы должны научиться, это ставить себя на место собеседника. Нам нужно оценивать свою речь и свои пояснения, делая это с позиции слушающего нас человека.
Думаю, это один из самых полезных уроков, которые я для себя извлек. Благодаря этому я стал лучше писать документацию, четче выражаться и формулировать вопросы так, чтобы получать лучшие ответы.
Строгость к себе это проклятие
Я всегда многого ждал от себя, и это часто приводило к проблемам. После двух лет работы я понял, что причина этих проблем – мое собственное отношение. Не стоит думать, что окружающие ожидают от вас того же, что и вы сами от себя ждете.
Подобная проекция ожиданий может привести лишь к разочарованию и боязни задавать вопросы. А если кому-то не нравится, что вы задаете вопросы, это тревожный звоночек в плане безопасности окружения.
Сфера технологий очень широка, она выходит за рамки навыков, нужных для отдельной профессии. Поэтому люди, занятые в этой сфере, должны коммуницировать друг с другом и учиться друг у друга. Недостаток коммуникации с командой может привести, например, к тому, что другие будут работать над тем же багом, что и вы. Недостаток коммуникации с представителями бизнеса приводит к большому количеству изменений после релиза.
Agile работает
Когда я учился в колледже, я скептически относился к Agile. Но я это перерос. Agile – замечательный метод работы, гарантирующий, что клиент получает то, что хочет.
Поскольку у людей могут быть разные представления об Agile, я опишу, как мы работали. У нас были двухнедельные спринты. Каждые две недели у нас был день, посвященный демонстрации наших достижений клиенту, ретроспективе и планированию следующего спринта. Мне всегда нравились эти дни, поскольку показ демо вызывает у всей команды чувство гордости и поощряет к дальнейшей работе, а в ходе ретроспективы можно рассказать обо всем, что влияет на вашу работу.
Я считаю, что стори поинты это, в целом, не оптимальные единицы измерения. Знаю, что нам нужен способ сообщить бизнесу, какое значение имеет каждая фича, но… Это не слишком честно, когда с помощью стори поинтов мы оцениваем сложность тикетов.
Зона комфорта
Создается впечатление, что многие компании пребывают в некой зоне комфорта и не стремятся из нее выйти. Они открыты для новых вещей, но сами не спешат их внедрять и делают это лишь после долгого взвешивания плюсов и минусов. Сам я люблю новшества, способные что-то улучшить в определенных аспектах. Я их оцениваю лично и или вижу в них потенциал, или нет.
Возьмем пример. Мне очень нравится MobX, его применение повышает производительность. Но я думал: зачем новичкам беспокоиться о производительности, не лучше ли для них сначала изучить все остальное? Это оказалось плохим решением, поскольку люди не имели представления, как масштабировать MobX. Возможно, так получилось потому, что сам я мало был вовлечен в их первый проект, но я полагаю, что в этом суть консалтинга.
Проработав два года, я понял, что когда вы хотите внедрить что-то новое, оно должно быть четким и понятным. Таким образом, например, я внедрял TypeScript (да, еще до повального увлечения им). Он не заставляет разработчика менять мыслительный процесс, а просто помогает ему.
Что я хочу сказать: довольно трудно определить, что стоит внедрять, а что нет. Новшества не должны негативно отражаться на клиентах, качество программ должно оставаться неизменным, как и качество кода.
Прочее
Производительность
Об этом не все задумываются, хотя дискуссии на тему производительности ведутся постоянно. Но я уверен, что многие компании были бы в шоке, если бы узнали, сколько денег они теряют из-за того, что их приложения не оптимизированы для людей с телефонами или пользователей из стран с медленным интернетом.
Я знаю, что чтобы убедить представителей бизнеса в необходимости что-то делать, нужны цифры. Но Google Analytics и прочие подобные инструменты не учитывают людей, которые прекратили загрузку сайта из-за медленного соединения. Об этих людях забывать не следует, а потому нужно тщательно продумывать отображение информации на сайте.
Заключение
Работа это постоянный учебный процесс. Я, как разработчик, очень изменился за последние два года. Я очень благодарен за полученный опыт, рад, что познакомился со многими людьми, и жажду узнать, что ждет меня в будущем.
