Мне нравится идея Т-образного разработчика: того, кто хорошо разбирается в своих областях, но при этом имеет общее представление о связанных темах. Когда я присоединился к ReviewTrackers в качестве старшего инженера переднего плана, я сразу взялся за дело и раздавил заявки, ориентированные на интерфейс. В конце концов, у меня появилась возможность расширить свой набор инструментов, поработав над некоторыми внутренними технологиями ReviewTrackers.
Я не мог упустить этот шанс. Узнав больше о нашей серверной технологии, я получил шанс улучшить свой Т-образный набор навыков, но это также дало мне несколько ценных уроков.
Так каково писать SQL вместо CSS?
Но почему ширина?
Приятно возвращаться к основам инженерии, потому что это новое введение в написание качественного кода. Когда язык или структура незнакомы, вам нужно больше обдумать подход. Я высушил это? Правильно ли я обрабатываю ошибки? Могу ли я сделать эту модель данных полиморфной? Потратив дополнительное время на размышления, прежде чем писать какой-либо код в новых технологиях, я лучше осведомился об этих методах при решении проблем внешнего интерфейса.
Погружение в базу нашего внутреннего кода также дало мне более целостное представление о решении. Вместо того, чтобы просто использовать API, я начал их писать. Он показал мне мир, в котором логика может быть перенесена на серверную часть, а структуры данных могут быть обновлены, чтобы лучше обслуживать интерфейсную часть. Взаимодействие между интерфейсными и внутренними интерфейсами помогает построить более эффективное решение благодаря лучшему пониманию потребностей обеих кодовых баз.
Практический опыт, который я получил за это время, был невероятным. Всего за шесть месяцев я оценил свой первый план запроса, улучшил свои SQL-запросы и спроектировал, добавил и отредактировал новую схему. Разнообразие задач дало мне новые уроки, которые я мог изучить, избежать выгорания и даже больше разговоров, чтобы моя жена до смерти утомляла мою жену.
Мой набег на бэкэнд-разработку предоставил множество возможностей, и в конце концов я чувствую себя лучшим инженером, который вносит свой вклад в наши решения.
Вы боитесь сломать вещи?
Неа.
Переход к незнакомой базе кода может вызвать стресс. Как снова отобразить массив? Это лучшая практика в Ruby? Подождите, в Голанге нет дженериков? Тонны вопросов могут подорвать уверенность при реализации функций. Однако сильная культура создания поддерживаемых решений в ReviewTrackers помогла облегчить эту боль. Также в Голанге нет оператора Элвиса :(
База кода в ReviewTrackers использует преимущества общих библиотек и фреймворков с открытым исходным кодом. Это значительно упрощает понимание того, как выполнять работу. Можно следовать примеру из базы кода, можно использовать документацию, примеры или учебные пособия, поддерживаемые сообществом. Кроме того, общая архитектура основана на шаблонах проектирования, основанных на здравом смысле. Мысль, заложенная в общую картину, позволяет легко узнать, где следует ввести новые функции и как они будут взаимодействовать с остальной частью решения. Отсутствие необходимости тратить время на раскручивание глупой проприетарной логики дает мне больше времени на изучение синтаксиса, лучших практик и нюансов новых языков.
Код на ReviewTrackers очень хорошо протестирован. Это приносит мне двоякую пользу. Я могу внести изменения и повторно запустить тесты, чтобы убедиться, что я ничего не сломал. Они также передают цель охваченного кода. А это значит, что я могу быть более уверенным в том, что понимаю, что происходит, и буду лучше подходить к этому вопросу.
В конце концов, мне все еще нужно иметь возможность предоставлять новые функции высокого качества. Хорошая архитектура и тесты значительно упрощают эту задачу.
Значит, вы никогда ничего не ломаете?
ржу не могу
Каждый попадает в тупик и вводит ошибки. В таких случаях хорошо иметь других, к кому можно обратиться за помощью. Быстрое обсуждение может прояснить ситуацию намного быстрее и гораздо менее утомительно, чем потратить несколько часов на изучение StackOverflow. Все инженеры ReviewTracker готовы потратить время на то, чтобы решить проблему, помочь с новой концепцией или изобразить резинового утенка.
Когда я отправляю PR, всегда получаю ценные отзывы, чтобы убедиться, что я следую лучшим практикам или указываю на лучший подход. Одна из моих стратегий заключалась в том, чтобы погрузиться в PR других бэкендов, чтобы увидеть, как другие инженеры решают аналогичные проблемы. Видеть разные стили и задавать вопросы помогли мне соединить точки.
Для принятия более важных решений, касающихся новых функций или архитектуры, я могу запускать свои идеи группой бэкэнд-инженеров с еженедельной синхронизацией. Мы обсудим достоинства подхода и альтернативы. Эти встречи дали мне возможность принять решение и быть очень уверенным в своем подходе.
И да, я кое-что сломал. Несмотря на все мои усилия и процесс, который у нас есть в отношении качества кода, иногда ошибки проходят. В разгар моей легкой паники все готовы сплотиться, чтобы помочь решить проблему. Более серьезные проблемы обсуждаются в еженедельных ретроспективах, где мы пытаемся выяснить, как предотвратить повторение ситуации. Весь процесс кажется очень продуктивным.
Я всегда сторонник возможностей расшириться как разработчик. Это освежает и сложно. Я получил эту возможность в ReviewTrackers, а также помогал создавать новые функции продукта, которые продвигают бизнес вперед. Я обнаружил, что отбор, присоединение и объединение очень полезны.
