J>Как вежливо попросить что-то переписать, потому что код выглядит не очень?
Сильно зависит от компании, и от твоей в ней позиции.
В идеале со ссылками на guidelines — "здесь мы используем исключения, а не return codes", и т.п..
Здравствуйте, SkyDance, Вы писали:
SD>Сильно зависит от компании, и от твоей в ней позиции.
То есть джуны и мидлы к код ревью не подпускаются? Чтобы не дай бог не нашли баг в коде помидора?
SD>В идеале со ссылками на guidelines — "здесь мы используем исключения, а не return codes", и т.п..
+1, хороший подход, спорить с докой врятли кто будет, ничего личного вообщем
Здравствуйте, Antidote, Вы писали:
A>Здравствуйте, SkyDance, Вы писали:
SD>>Сильно зависит от компании, и от твоей в ней позиции.
A>То есть джуны и мидлы к код ревью не подпускаются? Чтобы не дай бог не нашли баг в коде помидора?
Да пускают наверное, просто надо же понять сколько раз Ку делать, а то вдруг мало и потом эцилопп ночью изобьет?
Здравствуйте, Тёмчик, Вы писали:
Тё>IMHO принцип Лискова- элементарно обобщение рациональности. Если до чела не доходит, что у него дизайн классов это какой-то понос, можно рубануть принципом лискова, и закончить спор в свою пользу.
Совершенно точно, но как и любое обобщение, ему не хватает конкретики, поэтому увязать в голове обобщенный принцип и свою конкретную ситуацию в своем конкретном коде бывает тяжело, особенно как нет практики, а в описании принципа нет ни конкретики (на взгляд начинающего программиста-практика), ни набора хороших примеров его нарушений и соблюдений:
Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.
Охрененно понятная и практичная формулировка, просто верх рациональности))
Роберт Мартин конечно как всегда приходит на выручку, но его формулировка тоже не верх практичности.
J>как вежливо делать замечания по коду, желательно с примерами на англ.
Вообще, всем по большому счету пофигу на эту вежливость. Главное не цепляйся к мелочам (я конечно понимаю, что для одного это мелочь а для другого смысл всей жизни, но все-таки...), если критикуешь, предлагай, как сделать лучше.
Ну и еще, старайся находить реальные проблемы, а не высасывать их из пальца, и будет тебе счастье.
В обоих случаях, важно не приказывать и не требовать, надо предлагать как сделать лучше, ну и вообще круто, если это неочевидно объяснять почему так лучше.
SD>>Сильно зависит от компании, и от твоей в ней позиции. A>То есть джуны и мидлы к код ревью не подпускаются? Чтобы не дай бог не нашли баг в коде помидора?
Позиция определяет уровень комментариев. На определенных позициях комментарии будут "зачем вообще этот дифф выслан" или "предоставьте доку, что вы вообще делаете такое".
На других — "это неканонично для языка, писать if length(Var) == length("false")."
А баги бывают в любом коде, даже у помидоров. Просто чем помидорнее, тем баги забористее.
Здравствуйте, IT, Вы писали:
IT>Когда возможно нарушение этого принципа? Например, в случае если у нас имеется иерархия объектов с развесистым и запутанным интерфейсом наследования.
Да в принципе, стоит только переопределить неабстрактный метод, и получаем нарушение LSP.
Здравствуйте, SkyDance, Вы писали:
SD>>>Сильно зависит от компании, и от твоей в ней позиции. A>>То есть джуны и мидлы к код ревью не подпускаются? Чтобы не дай бог не нашли баг в коде помидора?
SD>Позиция определяет уровень комментариев. На определенных позициях комментарии будут "зачем вообще этот дифф выслан" или "предоставьте доку, что вы вообще делаете такое". SD>На других — "это неканонично для языка, писать if length(Var) == length("false")."
SD>А баги бывают в любом коде, даже у помидоров. Просто чем помидорнее, тем баги забористее.
Все как раз наоборот.
Чем помидорнее, тем проще все должно искаться и правиться, т.к. есть навык написания робастного (устойчивого) кода.
А вот джуны могут так накосячить, что помидорам за ними месяцами не разобраться.
sts>Чем помидорнее, тем проще все должно искаться и правиться, т.к. есть навык написания робастного (устойчивого) кода.
Именно поэтому если в коде таки есть баг, он очень, очень ОЧЕНЬ неочевиден и требует нетривиальных умений.
Иными словами, чтобы найти (и тем более исправить) баг в коде сеньора, нужен... еще более сеньор.
