Сообщение Re[22]: Как вежливо ревьювить код? от 21.04.2021 18:54
Изменено 21.04.2021 19:07 gyraboo
Re[22]: Как вежливо ревьювить код?
Здравствуйте, IT, Вы писали:
G>>Я уверен, что соблюдение SOLID, паттернов, элементов DDD, контрактное программирование, проверка инвариантов, практики Clean code дают выигрыш в затратах на сопровождение кода — т.к. багов меньше, код — надежнее.
IT>Вот здесь
Совершенно согласен с этой статьей, я её даже читал уже.
Хотя добавил бы, что код ревью часто все же немного упрощает сложность. Потому что на мой взгляд первичные коммиты по таску — это результат наслоения инженерного поиска, без упрощающего рефакторинга, т.к. во-первых у разраба глаз уже замылен его задачей, во-вторых, ему в лом без пинка что-то в коде упрощать, в-третьих, свежий взгляд со стороны часто видит излишнюю сложность кода, которую можно и нужно упростить, в том числе с помощью этих правил.
IT>Проблема SRP (впрочем как и всех других принципов) в том, что они предписывают делать или не делать нечто, но не задают рамки своей применимости, оставляя это на откуп здравому смыслу. А с последним могут возникнуть проблемы, если желанию следовать какому-либо принципу присваивается наивысший приоритет.
Именно поэтому кроме SOLID в моем чек-листе (говорю только за себя), есть правила, "ограничивающие" их применение и остужающие пыл больных "паттерной лихорадкой" (хотя таких вроде уже почти не осталось, потому что сейчас каждый второй джун, а благодаря книгам Сиерры и Швеца и каждый второй заинтересованный школьник) знают про паттерны и SOLID. Это было откровением может только в начале 2000-х, когда все о них говорили но мало кто понимал что это такое и как это правильно применять, сейчас же — GRAPS/SOLID/паттерны — это просто часть всеобщей грамотности и единого мета-языка, а не Откровение Для Вчерашних Эникейщиков. Да, опыта в их реальном применении у начинающих коммерческих разрабов мало, но от зубов эта теория отскакивает будь здоров.
Упомянутые "ограничивающие" правила — это например KISS, напоминание про оверинжиниринг. Да и сами SOLID в моём чек-листе например стоят лишь на 40-м месте.
Как тут в соседней ветке про религиозные секты верно отметили, сейчас Великим Но Непонятным Чудом и Волшебной Таблеткой, Решающей Все Проблемы, является DDD, ну и наверное функциональщина с реактивщиной. Ну и конечно мантра "распилить монолит".
G>>Я уверен, что соблюдение SOLID, паттернов, элементов DDD, контрактное программирование, проверка инвариантов, практики Clean code дают выигрыш в затратах на сопровождение кода — т.к. багов меньше, код — надежнее.
IT>Вот здесь
Автор(ы): Игорь Ткачёв
Дата: 06.12.2002
давным давно я приводил пример, когда не работает SRP.Дата: 06.12.2002
Совершенно согласен с этой статьей, я её даже читал уже.
Хотя добавил бы, что код ревью часто все же немного упрощает сложность. Потому что на мой взгляд первичные коммиты по таску — это результат наслоения инженерного поиска, без упрощающего рефакторинга, т.к. во-первых у разраба глаз уже замылен его задачей, во-вторых, ему в лом без пинка что-то в коде упрощать, в-третьих, свежий взгляд со стороны часто видит излишнюю сложность кода, которую можно и нужно упростить, в том числе с помощью этих правил.
IT>Проблема SRP (впрочем как и всех других принципов) в том, что они предписывают делать или не делать нечто, но не задают рамки своей применимости, оставляя это на откуп здравому смыслу. А с последним могут возникнуть проблемы, если желанию следовать какому-либо принципу присваивается наивысший приоритет.
Именно поэтому кроме SOLID в моем чек-листе (говорю только за себя), есть правила, "ограничивающие" их применение и остужающие пыл больных "паттерной лихорадкой" (хотя таких вроде уже почти не осталось, потому что сейчас каждый второй джун, а благодаря книгам Сиерры и Швеца и каждый второй заинтересованный школьник) знают про паттерны и SOLID. Это было откровением может только в начале 2000-х, когда все о них говорили но мало кто понимал что это такое и как это правильно применять, сейчас же — GRAPS/SOLID/паттерны — это просто часть всеобщей грамотности и единого мета-языка, а не Откровение Для Вчерашних Эникейщиков. Да, опыта в их реальном применении у начинающих коммерческих разрабов мало, но от зубов эта теория отскакивает будь здоров.
Упомянутые "ограничивающие" правила — это например KISS, напоминание про оверинжиниринг. Да и сами SOLID в моём чек-листе например стоят лишь на 40-м месте.
Как тут в соседней ветке про религиозные секты верно отметили, сейчас Великим Но Непонятным Чудом и Волшебной Таблеткой, Решающей Все Проблемы, является DDD, ну и наверное функциональщина с реактивщиной. Ну и конечно мантра "распилить монолит".
Re[22]: Как вежливо ревьювить код?
Здравствуйте, IT, Вы писали:
G>>Я уверен, что соблюдение SOLID, паттернов, элементов DDD, контрактное программирование, проверка инвариантов, практики Clean code дают выигрыш в затратах на сопровождение кода — т.к. багов меньше, код — надежнее.
IT>Вот здесь
Совершенно согласен с этой статьей, я её даже читал уже.
Хотя добавил бы, что код ревью часто все же немного упрощает сложность. Потому что на мой взгляд первичные коммиты по таску — это результат наслоения инженерного поиска, без упрощающего рефакторинга, т.к. во-первых у разраба глаз уже замылен его задачей, во-вторых, ему в лом без пинка что-то в коде упрощать, в-третьих, свежий взгляд со стороны часто видит излишнюю сложность кода, которую можно и нужно упростить, в том числе с помощью этих правил.
Ну и ещё часто невозможно собрать супер-team с мега-крутыми мозгами, в энтерпрайзе часто работают средние по уровню команды, и правила и дисциплинируют, и повышают качество, доводя его до приемлимо промышленного уровня, но не до того совершенства простоты, о котором ты говоришь.
IT>Проблема SRP (впрочем как и всех других принципов) в том, что они предписывают делать или не делать нечто, но не задают рамки своей применимости, оставляя это на откуп здравому смыслу. А с последним могут возникнуть проблемы, если желанию следовать какому-либо принципу присваивается наивысший приоритет.
Именно поэтому кроме SOLID в моем чек-листе (говорю только за себя), есть правила, "ограничивающие" их применение и остужающие пыл больных "паттерной лихорадкой" (хотя таких вроде уже почти не осталось, потому что сейчас каждый второй джун, а благодаря книгам Сиерры и Швеца и каждый второй заинтересованный школьник) знают про паттерны и SOLID. Это было откровением может только в начале 2000-х, когда все о них говорили но мало кто понимал что это такое и как это правильно применять, сейчас же — GRAPS/SOLID/паттерны — это просто часть всеобщей грамотности и единого мета-языка, а не Откровение Для Вчерашних Эникейщиков. Да, опыта в их реальном применении у начинающих коммерческих разрабов мало, но от зубов эта теория отскакивает будь здоров.
Упомянутые "ограничивающие" правила — это например KISS, напоминание про оверинжиниринг. Да и сами SOLID в моём чек-листе например стоят лишь на 40-м месте.
Как тут в соседней ветке про религиозные секты верно отметили, сейчас Великим Но Непонятным Чудом и Волшебной Таблеткой, Решающей Все Проблемы, является DDD, ну и наверное функциональщина с реактивщиной. Ну и конечно мантра "распилить монолит".
G>>Я уверен, что соблюдение SOLID, паттернов, элементов DDD, контрактное программирование, проверка инвариантов, практики Clean code дают выигрыш в затратах на сопровождение кода — т.к. багов меньше, код — надежнее.
IT>Вот здесь
Автор(ы): Игорь Ткачёв
Дата: 06.12.2002
давным давно я приводил пример, когда не работает SRP.Дата: 06.12.2002
Совершенно согласен с этой статьей, я её даже читал уже.
Хотя добавил бы, что код ревью часто все же немного упрощает сложность. Потому что на мой взгляд первичные коммиты по таску — это результат наслоения инженерного поиска, без упрощающего рефакторинга, т.к. во-первых у разраба глаз уже замылен его задачей, во-вторых, ему в лом без пинка что-то в коде упрощать, в-третьих, свежий взгляд со стороны часто видит излишнюю сложность кода, которую можно и нужно упростить, в том числе с помощью этих правил.
Ну и ещё часто невозможно собрать супер-team с мега-крутыми мозгами, в энтерпрайзе часто работают средние по уровню команды, и правила и дисциплинируют, и повышают качество, доводя его до приемлимо промышленного уровня, но не до того совершенства простоты, о котором ты говоришь.
IT>Проблема SRP (впрочем как и всех других принципов) в том, что они предписывают делать или не делать нечто, но не задают рамки своей применимости, оставляя это на откуп здравому смыслу. А с последним могут возникнуть проблемы, если желанию следовать какому-либо принципу присваивается наивысший приоритет.
Именно поэтому кроме SOLID в моем чек-листе (говорю только за себя), есть правила, "ограничивающие" их применение и остужающие пыл больных "паттерной лихорадкой" (хотя таких вроде уже почти не осталось, потому что сейчас каждый второй джун, а благодаря книгам Сиерры и Швеца и каждый второй заинтересованный школьник) знают про паттерны и SOLID. Это было откровением может только в начале 2000-х, когда все о них говорили но мало кто понимал что это такое и как это правильно применять, сейчас же — GRAPS/SOLID/паттерны — это просто часть всеобщей грамотности и единого мета-языка, а не Откровение Для Вчерашних Эникейщиков. Да, опыта в их реальном применении у начинающих коммерческих разрабов мало, но от зубов эта теория отскакивает будь здоров.
Упомянутые "ограничивающие" правила — это например KISS, напоминание про оверинжиниринг. Да и сами SOLID в моём чек-листе например стоят лишь на 40-м месте.
Как тут в соседней ветке про религиозные секты верно отметили, сейчас Великим Но Непонятным Чудом и Волшебной Таблеткой, Решающей Все Проблемы, является DDD, ну и наверное функциональщина с реактивщиной. Ну и конечно мантра "распилить монолит".