Практики, которые приносят радость по мере роста и масштабирования программных проектов

Если вам посчастливилось работать со мной, вы заметите одну вещь: у меня обычно больше вопросов, чем ответов. Последние несколько месяцев меня не отпускали по ночам несколько вопросов.

  • Почему многие программисты слишком усложняют вещи?
  • Почему бы нам больше не сосредоточиться на упрощении наших программных проектов?
  • Какие объективные метрики можно использовать для измерения простоты программных проектов?
  • Что заставляет набирать обороты лучшие проекты с открытым исходным кодом?
  • Почему так сложно заниматься спортом и правильно питаться? (Шутка ... это тема для другого дня и публикации!)

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

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

Предыстория

Я работаю в небольшой scrum-команде, которой принадлежит около 6+ микросервисов. Одна вещь, которую я заметил, - это то, что есть некоторые услуги, к которым никто из команды не хочет прикасаться. Первоначально я думал, что это произошло только потому, что не у всех был большой опыт работы с этими базами кода, но я заметил, что даже мои коллеги с большим опытом не хотели трогать эти службы. Что на самом деле было не так в этих проектах? Ответ - плохой опыт разработчика! Вот несколько вещей, которые, я думаю, мы можем сделать как одна команда, чтобы эти услуги снова стали отличными. (Ну, если бы они были когда-нибудь великолепны).

Пора запускать или запускать приложение локально

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

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

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

  • Убедитесь, что работают сценарии запуска и сборки по умолчанию: для узлового приложения это сценарий запуска npm, а для приложения Java это может быть команда Maven run или Gradle run.
  • Настраиваемые сценарии оболочки для настройки и сборки в среде разработки: некоторые проекты могут иметь настраиваемые этапы сборки. Их можно абстрагировать, имея сценарий оболочки для построения зависимостей и настройки переменных среды.
  • Используйте SDK и инструменты управления версиями. Для некоторых проектов может потребоваться более старая версия языка или платформы. Использование таких инструментов, как SDKMan и NVM, упрощает управление этими различиями требований зависимостей.

Легко доступная документация

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

  • Минимальная языковая версия и системные требования для запуска проекта.
  • Внешние зависимости, необходимые для проекта (если он не может быть автоматизирован).
  • Где найти или добавить учетные данные для некоторых внешних зависимостей.
  • Часто возникающие ошибки и как их исправить.
  • Удобные приемы отладки.

Упростите отладку или воспользуйтесь простыми инструментами отладки

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

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

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

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

Значимое тестирование

Откуда вы знаете, что не нарушили существующую функциональность проекта, если все компилируется и приложение запускается? С осмысленными тестами! Без значимых тестов лучший способ выяснить это - в продакшене. Разработчики не решаются вносить изменения в проект, если не уверены в текущих тестах.

Если вы уверены в автоматизированных тестах, которые есть в проекте, у вас, вероятно, будет больше уверенности в экспериментах и ​​добавлении изменений в базу кода. Вы знаете, что тесты будут кричать на вас, когда вы ошибаетесь. Звучит как отличный опыт разработчика!

Заключение

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