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

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

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

Время развивает обучение

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

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

Знание того, что реальные пользователи зависят от системы, быстро изменило мою точку зрения и сконцентрировало мое обучение.

Форкнуть или не форкнуть

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

Это также может изменить вашу оценку перед использованием библиотеки. Кто публикует эту библиотеку с открытым исходным кодом? Есть ли у него поддержка в обществе? Хорошо ли он построен с использованием тестов?

Даже если вы решили, что добавить новую библиотеку — это хорошая идея, вам также необходимо подумать о том, какой рефакторинг или другая очистка должны быть выполнены в первую очередь. Например, если вы замените свою систему сетки на такой инструмент, как Bootstrap, вы подумаете о преобразовании всего приложения и удалении старого мертвого кода. В то время, когда вы вводите новый инструмент, у вас есть больше всего информации о том, чем отличаются оба подхода. Тщательно проведите рефакторинг, и ваше будущее «я» скажет вам спасибо.

Избегайте введения случайной сложности

Еще один принцип, который я усвоил, заключается в том, что чем меньше кода (и движущихся частей) у вас в системе, тем легче будет ее изменять и обновлять в будущем. Это заставляет вас задавать такие вопросы, как: «Действительно ли этому приложению нужен внешний интерфейс JavaScript или будет достаточно статических страниц, отображаемых на сервере?»

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

Стремитесь понять всю окружающую среду

Это также означает изучение полного «стека» или среды, в которой выполняется развертывание. Не только языковой стек, но и серверная и сетевая инфраструктура.

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

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

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

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

Производительность измеряется в масштабе

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

Всегда учитесь

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

  1. Зная то, что я знаю сейчас, подошел бы я к проблеме по-другому?
  2. Чего не хватало в нашем мониторинге или регистрации, чтобы обнаружить эту проблему?
  3. Является ли это аномалией, но все же полезной для моего обучения?

Когда вы найдете что-то конкретное, поделитесь тем, что вы узнали. Наша команда использует Slack-канал #til (Сегодня я узнал), чтобы записывать эти маленькие самородки обучения. Также может быть полезно зафиксировать полученные знания в файле README проекта для будущих разработчиков.

Измерение возможности поддержки

Команда RoleModel хотела создать общее понимание того, что облегчает поддержку проекта. Мы создали систему показателей поддержки и используем ее в каждом проекте.

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

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