Здравствуйте, fmiracle, Вы писали:

J>>>>Как вежливо попросить что-то переписать, потому что код выглядит не очень?
F>>>Указать конкретные проблемы в чем "не очень", если они требуют переписывания.
F>>>Не забывай, что все эти переписывания — это время и силы. Их нужно тратить, если от этого улучшается код и не нужно иначе. Соответственно — следует обосновать, зачем человеку тратить на это силы.

G>>У команды должен быть чек-лист со сводом правил, и чтобы все разрабы были с ним согласны. Например, правило: применяем SOLID. Или: применяем clean code мартина и макконнела. Или: применяем GoF при необходимости. Испольщуем полиморфизм вместо switch в бизнес-логике. Работам по контрактоному варианту. Применяем DDD или же просто анемичную модель. И т.д. и т.п. Этот лист должен постоянно дополняться, чтобы отражать консенсус всей команды. В этом случае не придется постоянно дискутировать и аргументировать свою позицию, будет достаточно дать ссылку на нарушенное в чек-листе правило, а не писать мини-лекции в каждом замечании.

F>0. Я полностью тут с тобой согласен
F>при этом
F>1. обращение к справочнику проблем и практик — это тоже вариант обоснования же
F>2. и оно все равно может порождать споры есть тут нарушение или нет и требовать прояснения ПОЧЕМУ тут на твой взгляд происходит нарушение. Ну, в смысле если принято писать в SOLID и автор знает, что так принято, и написал иначе — то значит или он вредитель или он считает что написал правильно и просто сказать "у тебя тут нарушение SOLID" без пояснений — мало что даст же

SOLID — достаточно объективный набор принципов. Их нарушения в 90% видны объективно. Проблемы с SOLID и споры обычно бывают из-за того, что кто-то не совсем корректно понимаем некоторые принципы. Поэтому да, часто приходится не просто указывать на нарушение SOLID, но и читать мини-лекцию. Это обычно для джунов и мидлов делается и является неплохим вариантом их обучения "на реальных примерах", и такие временные издержки должны конечно же закладываться в оценку сроков.

Здравствуйте, fmiracle, Вы писали:

J>>>>Как вежливо попросить что-то переписать, потому что код выглядит не очень?
F>>>Указать конкретные проблемы в чем "не очень", если они требуют переписывания.
F>>>Не забывай, что все эти переписывания — это время и силы. Их нужно тратить, если от этого улучшается код и не нужно иначе. Соответственно — следует обосновать, зачем человеку тратить на это силы.

G>>У команды должен быть чек-лист со сводом правил, и чтобы все разрабы были с ним согласны. Например, правило: применяем SOLID. Или: применяем clean code мартина и макконнела. Или: применяем GoF при необходимости. Испольщуем полиморфизм вместо switch в бизнес-логике. Работам по контрактоному варианту. Применяем DDD или же просто анемичную модель. И т.д. и т.п. Этот лист должен постоянно дополняться, чтобы отражать консенсус всей команды. В этом случае не придется постоянно дискутировать и аргументировать свою позицию, будет достаточно дать ссылку на нарушенное в чек-листе правило, а не писать мини-лекции в каждом замечании.

F>0. Я полностью тут с тобой согласен
F>при этом
F>1. обращение к справочнику проблем и практик — это тоже вариант обоснования же
F>2. и оно все равно может порождать споры есть тут нарушение или нет и требовать прояснения ПОЧЕМУ тут на твой взгляд происходит нарушение. Ну, в смысле если принято писать в SOLID и автор знает, что так принято, и написал иначе — то значит или он вредитель или он считает что написал правильно и просто сказать "у тебя тут нарушение SOLID" без пояснений — мало что даст же

SOLID — достаточно объективный набор принципов. Их нарушения в 90% видны объективно. Проблемы с SOLID и споры обычно бывают из-за того, что кто-то не совсем корректно понимаем некоторые принципы. Поэтому да, часто приходится не просто указывать на нарушение SOLID, но и читать мини-лекцию. Это обычно для джунов и мидлов делается и является неплохим вариантом их обучения "на реальных примерах", и такие временные издержки должны конечно же закладываться в оценку сроков и эта практика должна являться явной и "официальной" частью культуры разработки, а не делаться изподтишка или абы как.