Очень много посдвечено проблем, но не решений этих проблем. Спикер создал впечатление человека, который любит заниматься микроменеджментом. Даже были пункты противоречащие друг другу - код ревью не должен быть долгим и не должен форсится. Т.е. весь доклад можно уместить "Код ревью - это хорошо. Не делайте плохо, а делайте хорошо."
Анализ проблем code review очень скудный, о них можно писать бесконечно. Многие проблемы, которые якобы решает CR, гораздо эффективнее решаются другими способами. Тот же дизайн фичи можно обсудить и согласовать заранее, тогда не нужно будет ничего переделывать. Моё мнение, что CR обязателен при онбординге, а дальше должен быть минимизирован. И то, что на CR нет замечаний, это хорошо (если в коде действительно нет проблем). К сожалению, внедряющие код ревью наоборот начинают расширять его бесконечно, делать из него карго-культ, выдумывать горы формальных правил, и использовать, как инструмент микроменеджмента (с замыканием всех CR на одном человеке и соответствующими нерешаемыми проблемами)
Плюсую, технический анализ фичи(или дизайн ревью как его еще называют) + нормальные тесты + грамотно настроеный линтер\сонаркуб\whatever отлавливают проблемы в коде лучше любого код ревью, оставляя его только для отдельных сложных кейсов(к примеру посмотреть sql запрос, что он базу не положит в проде или что-то в этом духе). Но это требует чуть больше усилий и поэтому куча народа тащит по инерции код ревью, т.к. там все понятно, "посмотрел, чет написал, галочку поставил".
Очень много посдвечено проблем, но не решений этих проблем. Спикер создал впечатление человека, который любит заниматься микроменеджментом. Даже были пункты противоречащие друг другу - код ревью не должен быть долгим и не должен форсится.
Т.е. весь доклад можно уместить "Код ревью - это хорошо. Не делайте плохо, а делайте хорошо."
А в C# декораторы есть? Вообще думаю, что предъяв к коду должно быть больше, чем самого кода
Докладчик имел ввиду в качестве паттерна проектирования а не какой-то особенности языка.
55 минут демагогии о ценности код-ревью
0 полезных советов, как улучшить процесс код-ревью
Анализ проблем code review очень скудный, о них можно писать бесконечно.
Многие проблемы, которые якобы решает CR, гораздо эффективнее решаются другими способами. Тот же дизайн фичи можно обсудить и согласовать заранее, тогда не нужно будет ничего переделывать.
Моё мнение, что CR обязателен при онбординге, а дальше должен быть минимизирован. И то, что на CR нет замечаний, это хорошо (если в коде действительно нет проблем).
К сожалению, внедряющие код ревью наоборот начинают расширять его бесконечно, делать из него карго-культ, выдумывать горы формальных правил, и использовать, как инструмент микроменеджмента (с замыканием всех CR на одном человеке и соответствующими нерешаемыми проблемами)
Плюсую, технический анализ фичи(или дизайн ревью как его еще называют) + нормальные тесты + грамотно настроеный линтер\сонаркуб\whatever отлавливают проблемы в коде лучше любого код ревью, оставляя его только для отдельных сложных кейсов(к примеру посмотреть sql запрос, что он базу не положит в проде или что-то в этом духе). Но это требует чуть больше усилий и поэтому куча народа тащит по инерции код ревью, т.к. там все понятно, "посмотрел, чет написал, галочку поставил".
Пример на 30 минуте - один сплошной баг