Code review Терминатор. Ревью, за которое вам скажут спасибо

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

Code review Терминатор. Ревью, за которое вам скажут спасибо

В статье есть важная фраза:

Обычно ревью проводят асинхронно.

и это действительно стало практически промышленным стандартом (причины — распределенная команда, разные часовые пояса и прочее). Как и классическая ситуация с огромным количеством изменений в долгоживущей (в которой разработка велась больше 2-х дней) feature ветке, которую ревьювят в пять раундов (либо смотрят поверхностно и не дают дельных замечаний в 2 раунда) — это может длиться неделю с перерывами из-за прокрастинации обоих участников (которая понятна — вся энергия итак потрачена на чтение кода для решения текущей задачи и переключаться на чужие или свои недельные простыни кода уже тяжело) и неважных споров по мелочам.

Для меня было глотком свежего воздуха попробовать синхронное ревью, которое выглядит следующим образом:
ш.1 коллега сбрасывает ссылку на merge request (в нем есть ссылка на задачу)
ш.2 я с задеркжой 0-5-30 (если обед, созвон и проч) минут смотрю код и оставляю замечания — могу часть в личные сообщения, часть в сам merge request. Коллега к новой задаче НЕ приступает (не увеличивает незавершенное производство, нацелен на решение и продвижение текущей задачи)
ш.3 (опционально) — мы созваниваемся с коллегой и проходимся по коду устно. Если есть возможность смержить код (несмотря на замечания) — он мержится (код закрыт feature toggle либо KeystoneInterface — подробнее у Martin Fowler). В любом случае если есть замечания — приступаем к следующем этапу
ш.4 (опционально) коллега правит замечания, я в это время возвращаюсь к своей задаче (я НЕ увеличиваю количество незавершенное работы — так как я уже работал над текущей задаче перед ревью). Но я могу и подождать коллегу и не переключаться
ш.5 возвращаемся к ш.2

Важные условия:
— размер merge request, у нас это ограниение заложено в рамках pipeline — <= 150 строк нового кода
— continious integration. У нас строгий пайплайн и мы часто мержимся
— коллега готов работать в таком режиме. То есть периодически переключаться на то чтобы посмотреть мелкие изменения (оказывается, переключаться чаще на небольшие изменения проще, чем редко на очень больше — также в этой технике не находится места прокрастинации). Обычно МР в этом случае проходит максимум в два раунда и ветка не живет больше 1-2 дней (ci/trunk based development)
— в команде также практикуется парное программирование и парная спецификация задач (ревьювер и автор merge request находятся глубоко в одном контексте)

В нашей команде 2 программиста, но говорят twitter.com/jezhumble/status/1260973883697401856 это масштабируется и на большие команды, тем более если можно дробить команды на более мелкие

Конечно, синхронное ревью (как и парное программирование) звучит очень контринтуитивно в наше время прославления асинхронного общения. Но если есть возможность попробовать и у вас приятные и профессиональные коллеги — почему нет?

Настоящее и будущее безопасной работы с null и undefined в JavaScript

Код с прокси не очень корректный. Если, например, требуемое конечное значение — объект, то у нас вернется проксированный вариант, возвращающий дефолтное значение в случае отсутствия свойства

...
const obj = {
  items: [{ someObj: {} }]
};

const someObj = optional(obj, target => target.items[0].someObj, "def");
console.log(someObj.someProp) // "def"

ну и вызов proxify со вторым аргументом не нужен — proxify принимает один аргумент

Функциональные компоненты

Ещё желательно преодолеть коннектобоязнь — не тащить все свойства через родительские компоненты, а применять connect() для дочерних компонентов по мере использования свойств.

А если это не «коннектобоязнь», а желание максимально снизить зависимость от redux, чтобы его замену на что-то другое произошла максимально безболезненно?

Если работать в парадигме «умных» и «глупых» компонентов, то ваши коннекторы просто заменятся на другие «умные» компоненты в mobX и проч. Это всегда лучше, чем прокидывать миллиард пропсов из верхнеуровнего компонента (SomePage и проч.) — это всегда превращается в {...this.props} на каждый дочерний компонент и потом сложно отследить и отладить, откуда все взялось, плюс лишние пропсы попадают.
Коннектор это просто обертка, чаще всего ему и разметка не нужна:

export default connect(mapStateToProps, mapDispatchToProps, mergeProps)(MyDumbCompoent)