Code review: вредные советы для контрибьютера и ревьювера

[red_perez]

Если вы захотели реализовать новую фичу, ни в коем случае ни с кем не обсуждайте свою доработку.

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

[NorthDragon]

Согласен.

Технический дизайн, proof of concept, mvp и т.д. стадии на которые стоит разбивать доработку.
Также хорошо работают макеты интерфейса.
Особенно, если нужность доработки обсуждаешь с представителями бизнеса.

[JustDont]

Yep. Есть очень много вещей, которые люди (в том числе люди со значимым фидбеком, клиенты, и т. д.) просто не понимают, пока им не разжуёшь всё тщательнейшим образом, а часто это означает, что нужно именно показать какой-то рабочий прототип — и только тогда будет фидбек.

[NorthDragon]

К счастью, в системных проектах, к которым относится Ignite такого нет :)
Хотя, при предложении сложных доработок(MVCC транзакции, TDE и других) без прототипа public api, use-case'ов и другого не обойтись.