Улучшение влияния разработчиков | Кодементор

ВОЗДЕЙСТВИЕ на кодовую базу можно описать как то, как ваш код влияет на существующую кодовую базу. Это можно измерить количеством строк, которые вы добавили или обновили, количеством затронутых файлов и, что наиболее важно, когнитивной сложностью добавленных вами изменений. Как правило, на влияние инженеров может влиять множество внешних факторов, начиная от методов работы с программным обеспечением и заканчивая наличием блоков кода. Ниже приведены некоторые из причин отрицательного воздействия

• Переключение контекста:
  Когда задачи создаются не настолько неделимыми, насколько это возможно, это может привести к совершению ошибок, которых можно избежать, поскольку такие задачи могут иметь другой контекст, связанный с ними. Кроме того, необходимость разблокировать людей, работающих над другой задачей, в свою очередь, может заставить вас предлагать полусырые решения.
• Время:
  инженер тратит на освоение новой кодовой базы. Тем более, без хорошей документации
• Взбивание:
  В программной инженерии это количество строк кода, которые переписываются за определенный период времени. Когда отток инженера увеличивается, это в целом влияет на влияние, которое инженер оказывает на команду в целом. Ниже приведены некоторые из основных причин оттока
• Плохие бизнес-требования:
  Agile — это хорошо, но плохие бизнес-требования (BR) — это совсем другая проблема. Плохой BR заставит инженеров продолжать удалять и добавлять новый код в течение очень короткого периода времени по мере поступления новой информации.
• Неубедительные коммиты:
  постепенные коммиты — это хорошо. Инженеры должны избегать коммита кода, который не делает того, для чего заявлен. Это означает, что фиксация должна содержать работающую функциональность в зависимости от обстоятельств. Т.е. «feat(Date Parser): создать утилиту для парсинга даты» нужно коммитить только тогда, когда эта утилита работает.
• Соглашения:
  различные соглашения в нескольких командах scrum также могут привести к высокому оттоку, поскольку проверки гарантируют, что инженеры соблюдают это соглашение, таким образом, отток

Возможные решения:

Документация:

Это играет важную роль в любой кодовой базе. Иногда это может быть разницей между хорошей кодовой базой и плохой.

1. Документация должна быть частью эпопеи: Документация должна быть непрерывной задачей на любой кодовой базе и должна быть важной частью эпопеи.
2. Технические решения должны быть задокументированы

Понимание, функциональная область:

1. Инженеры должны быть более активными во время архитектуры и решения проблем
2. Инженеры должны уделять больше времени разработке решений и получению большей информации.
3. Инженеры должны запланировать еженедельный обход кода, чтобы убедиться, что каждый близок к тому, чтобы быть в курсе его или ее функциональной области.
4. Инженеры должны больше участвовать в принятии инженерных решений в команде

Требования к проекту:

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

Общий:

1. Единое соглашение по кодовой базе
2. Задачи не следует разделять на основе предполагаемой силы, и молодые инженеры должны воздерживаться от выбора слишком сложных задач.
3. Совокупное влияние инженеров не должно измеряться только строками кода.