Когда разработчик начинает кодировать фичу, результат кодирования обычно доступен в обзоре кода через N часов. Это когда команда разработчиков впервые сталкивается с получившимся кодом. Полученный код содержит выбранные способы и подходы для достижения требуемой функции.
Проблема сложности
Независимо от количества полученного кода в код-ревью, оживитель имеет дело с некоторыми конкретными изменениями (добавлениями и удалениями). Некоторые изменения сосредоточены на конкретных действиях, но размывают полученную структуру кода, отношения между объектами, жизненные циклы, последовательности действий и вызовы. Также требуется работа по отслеживанию окончательной структуры проекта после всех манипуляций с файлами и директориями.
Тем не менее, это та работа, которую команда разработчиков выполняет при каждой проверке кода для достижения общей цели проверки не отдельных изменений по отдельности, а всего решения как такового и того, как система будет работать с этими изменениями. Это довольно кропотливая работа, чтобы увидеть набор изменений как единое целое, особенно когда вам нужно больше контекста о проверяемой функции. Наиболее информированным членом команды в этой ситуации является автор фичи. Эта проблема сложности для остальной части команды может быть решена в основном путем обмена знаниями о результирующей структуре кода, поведении и т. д. Это даст возможность сосредоточиться на решении в целом, прежде чем углубляться в конкретные изменения. Использование диаграмм UML — один из наиболее подходящих способов кратко и ясно представить эту информацию посредством визуализации.
Проблема качества
Самые важные ресурсы каждого разработчика — это внимание и время. В случае отсутствия подробной информации, предоставленной автором, у рецензента может не хватить времени, внимания или опыта, чтобы объединить всю общую информацию о коде с изменениями. Это означает, что результат и качество код-ревью будут различаться в зависимости от уровня погружения рецензента. Уровень погружения членов команды крайне непредсказуем, но его значение по умолчанию можно увеличить.
Независимо от того, сколько проблем со стилем кода вы обнаружите, самые важные проблемы по-прежнему будут мешать вам завтра. Пока рецензент не сможет быстро уловить контекст и сосредоточиться на решении, прежде чем углубляться в конкретные изменения, качество и уровень выявленных проблем в ходе проверки кода не смогут значительно улучшить результирующую кодовую базу. Контекст — это тот же набор диаграмм и заметок UML, которыми пользуется автор.
Проблема с поздней проверкой качества
Рецензент может обнаружить первые проблемы до просмотра реального кода, исследуя диаграммы UML как часть контекста. Например, на диаграмме объектов UML отображаются отношения объектов, которые на самом деле не соответствуют правильной ожидаемой реализации. Это одна из наших целей, чтобы найти эту проблему как можно скорее. Но можно задать следующие основные вопросы. Почему мы обнаружили эту проблему спустя N часов разработки? У нас есть время для доработки решения? Это типичная ситуация, потому что времени на доработку практически нет. По крайней мере, это приведет к увеличению технического долга, но это все равно изменит планы команды.
Каждая фича перед кодированием проходит несколько этапов. Когда разработчик оценивает фичу, у него уже может быть план и видение результата. Настал момент, когда UML-диаграммы в процессе проектирования могут представлять первоначальные планы реализации. В процессе проектирования не всегда возможно нарисовать точные диаграммы UML, которые будут реализованы на 100% в том виде, в котором они есть. Процесс разработки всегда вносит коррективы, но уже на этом этапе можно легко выделить и подтвердить наиболее важные части.
