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

Оглавление

Никогда не предполагать

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

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

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

Это, наверное, самый важный урок, который я усвоил, и его можно применить во многих ситуациях, а не только в коде. Вот несколько:

  1. Никогда не предполагайте, что кто-то сделает что-то только потому, что вы попросили. Всегда получайте четкое согласие. Не получили ответа от кого-то, кого вы просили что-то проверить? Отправить продолжение. Если что-то важно, это достаточно важно, чтобы продолжить.
  2. Никогда не предполагайте, что кто-то понимает то, что вы им сказали, даже если они говорят, что понимают. Это то, что я узнал после того, как продвинулся в своей карьере до точки, когда я помогал наставлять более молодых разработчиков. Я обнаружил, что буду копаться в инструкциях, а на следующий день выясню, что данный разработчик не добился большого прогресса, даже несмотря на то, что они сказали, что прекрасно понимают, что требуется. Вместо этого попросите человека дать вам пошаговое руководство по обсуждению, чтобы вы могли быть уверены, что он понимает. Это касается не только наставничества разработчиков, например, объяснения чего-либо BA / QA и т. Д.
  3. Никогда не предполагайте, что другая сторона ошибается. Я думаю, что разработчики склонны обвинять всех остальных в том, что их код не работает. Вы начинаете защищать код, который пишете, до такой степени, что убеждены, что он не может быть неправильным. Если QA сообщает вам, что у них возникла проблема, у них есть для этого причина. Вам не будет стоить много денег, чтобы дать им возможность выразить свои сомнения, и они оценят это больше, чем то, что их закрыли.

Нетехнические проблемы - самые сложные

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

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

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

Сначала думай, потом кодируй

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

Знакомо, правда? Разработчики, в том числе и я, любят автоматизированные решения.

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

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

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

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

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

Каждая роль одинаково важна

Я уже упоминал, как важно не предполагать автоматически, что все, кто не является разработчиком, ошибаются. Кроме того, я узнал, что каждый член вашей команды (BA, QA, менеджер проекта, другие заинтересованные стороны и т. Д.) Так же важен, как и любой разработчик.

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

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

Заключение

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

Спасибо за прочтение!