Comments 8
Раскройте смысл это мантры:
>>Применяется ли модульное тестирование по возможности и интеграционное тестирование при необходимости?
Надо скинуть нашему лиду. Вдруг дойдет что код можно читать и на код стайле мир клином не сошелся. Хотя исправление комментов и переносы строк генерируют так много активности в гитхабе... Не, не дойдет ;[
Вы можете использовать автоматическое форматирование. Один раз настройте и пишите сразу с включенным автоформаттером.
На одном из проектов мы настраивали автоматическое форматирование на уровне CI.
Правила в git, подтягиваются IDE + те же правила гоняются в CI и бот сам применяет форматирование к feature ветке после чего делает git push.
Пока что ничего лучшего я не видел.
Минус - необходимость делать rebase после бота при отправке своих правок в feature ветку
Я надеялся на хорошую пирамиду. Увы, оно странное (что такое API semantics как базовый слой? А если я пишу не api сервер?).
Самые сложные вопросы ревью, ответы на которые я пытаюсь понять:
Какие связи привносятся в проект?
Конфликтует ли предложенный подход с уже существующими в проекте? Есть ли существующая подсистема, которую можно переиспользовать?
Как это будет ломаться? Будет ли ошибка локализована или заденет неожиданные компоненты?
Достаточно ли хорошо обобщена задача? Нет ли тривиальных изменений, которые бы сделали решение более универсальным без увеличения сложности?
Как называются новые сущности? Есть ли у них название? Понятно ли оно?
Пирамида инспекции кода