Но всё именно так. Для написания хорошего кода нужен опыт, практика, комплексное понимание технологического стека, используемого языка, самой задачи и сути решения. Если код не нарушает принципы SOLID (и другие), это вовсе не означает сразу, что он качественный. Но их нарушение скорее всего показывает наличие проблем в коде, так называемый "запашок", который требуется устранить.
Поэтому, автор статьи пускается в крайности, и говорит, а давайте я сейчас вам покажу, как легко сделать отвратительный код следуя принципам SOLID. И когда у него это получается, вывод: принципы совсем плохие, чего вы на них молитесь (как будто кто-то молится), давайте их выкинем. При чём принципов гораздо больше, чем SOLID. Если применить и другие, например связность/связанность, выяснится, что этот "солидный" но плохой код нарушает другие принципы. И таки МОЖНО с очень хорошей оценкой выявить проблемы кода, без индивидуализма.
Этот принцип вообще не про интерфейсы (а точнее, абстракции, или контракты), которые здесь выступают именно как решение задачи инверсии зависимостей. Но не самоцель. Если человек ругает DIP, акцентируясь на интерфейсах, значит он не понимает этого принципа.
Ну как это нет, здрасьте. Т.е. взяли и на помойку выкинули весь опыт разработки. И как код ревью проводить? Может и не надо? Пусть каждый пишет вообще как хочет, потому что никаких критериев и быть не может? В общем, приехали.
Не очень понял про сову и глобус. В инверсии зависимостей абстракция это решения основной задачи: инвертировать зависимость. Принцип замечательный, и очень многое расставляет по местам, и снимает кучу проблем. Какая сова?
Очень странно конечно, что за 25 лет карьеры сложилось такое впечатление. У меня 20 лет карьеры, и тоже мог бы много чего рассказать.
Но вы не с той стороны подходите к вопросу. Вы когда-нибудь видели хоть один проект, который бы имел какой-нибудь значок типа "сделано в соответствии с принципами SOLID, DRY, KISS.. etc."? Я не видел. Хотя в рекламных буклетах каких-то проектах можно что-то подобное встретить. Но это не конкретная методология разработки, которая бы конкурировала или противопоставлялась другой. Это консолидированный совокупный опыт написания хорошего кода.
Очень многие разработчики, и даже в комментариях к этой статье, замечали, что с большим опытом разработки и с намерением писать хороший код, он итак получается SOLID-ным. Даже без цели делать его таковым. Это не методика, по которой вы пишите, как по лекалам. Это принципы, которые вы соблюдаете. Но к этом можно прийти неосознанно, или быстрее, но осознанно.
Я часто на собеседованиях задавал такой вопрос "зачем практически нужен SOLID?". Нет, я не спрашивал за каждую букву, мне хотелось услышать, зачем это нужно. Но. К сожалению, не все понимают зачем действительно нужен SOLID. "Чтоб писать хороший код"? Не совсем. Вот прям пишешь код и держишь в уме принципы SOLID? Ну нет конечно :) Или вообще заучили определения для собеседований. И только единицы осознают его применимость.
А применимость у него очень простая. На код ревью разработчики тратят значительно меньше времени, вместо долгого объяснения "на пальца", можно сказать, что вот этот код нарушает такой-то принцип, и это уже само по себе может быть плохо. Да, код не обязан строго следовать никаким принципам, он в первую очередь должен решать задачу. Но при всех равных, если нет причин ему быть другим, то нарушение принципов сигнализирует о проблемах. Это совокупный набор критериев качества, которые всеми понимаются плюс-минус одинаково, и резко сокращает время на обсуждение.
Новым разработчикам, без опыта, сложно писать сразу хороший сопровождаемый код. И принципы помогают хотя обозначить корректный путь. И да, можно искаверкать любые принципы и довести до абсурда. Что на самом деле приведёт к нарушению этих же принципов.
Может быть в вашем опыте, на ваших проектах, у вас все разработчики звёзды, вы на одной волне и все абсолютно одинаково мыслите, вы делаете всё одинаково, понимаете что значит "хороший код" одинаково, вам конечно не нужны никакие талмуды. Вам вообще ничего не нужно, вы уже программисты от бога, всё сразу пишите правильно, хорошо, эффективно, понятно и код идеально сопровождаемый. Просто потому что. Но я работал и работаю с разными людьми, и принципы очень помогают в работе. Не потому, что я на них молюсь, а потому что реально применяю их на практике в командах. И это благоприятно сказывается на разработке.
И после этого, вы заявляете "чушь собачья". Ну да, ну да. Ставим разработку на холд и топаем изучать труды по теориям типов. Потому как их толком никто не знает, а большинство и не слышало даже. Но они есть, и это замечательно. Только работают в узкой специализации.
Простите, но я так и не понял, на основе чего вы сделали вывод "чушь собачья". Если это апелляция к авторитетам, к научным лычкам и званиям, извините, этого недостаточно. Принципы это не теоремы и не законы, которые должны быть доказаны на бумаге. Это консолидация опыта. В научной среде также есть принципы, простые, лаконичные, и не требующие научных выкладок с формулами. Везде они есть. И никто в здравом уме не назовёт их "чушью собачей".
Вообще смысл есть, конечно не до фанатизма, но есть. Даже если исключения просто логируются и нет никакой специальной логики (сейчас), но в логах обычно мы выводим тип исключения в отдельном поле, и в моей практике это много раз позволяло правильно и максимально быстро провести оценку влияния и даже иногда замониторить конкретные типы. Поэтому да, всё вообще можно упростить: зачем нам это, зачем нам то, давайте всё уберём. А конь в вакууме может понадобится именно тогда, когда уже написано тонна кода и дорабатать за вменяемое время уже не получится. Принцип "лучше перебздеть, чем недобздеть" работает всегда, но и нужно соблюдать меру. Если обвес приходится обслуживать и тратить на это ресурсы, надо правильно оценить его необходимость. А если он есть не просит, в чём проблема?
Было бы интересно ознакомится с правильными принципами, правилами, методологией. Если SOLID плохой, ООП плохой, DDD плохой... всё плохое. Познакомьте с хорошим. Или вообще ничего не надо, просто пиши код, как придётся? Или "как договорится команда"? А перешёл в другую команду, там свой "талмуд", при чём даже нигде не описанный, просто на словах. Зачем вообще что-то знать? Книжки читать, так там плохому научат. Консолидированный опыт в топку.
А как должно быть? Люди в халатах с грамотами должны были выковать скрижали в жерле научной группы? Мне нравится ваша попытка обесценить опыт, под соусом "ребята собрались под пивка", но нет. В целом множество проектов, систем и прочего рождено энтузиастами, которым не всё равно.
Всё это никак не соответствует идее написания понятного, поддерживаемого и эффективного кода. То, о чём вы говорите соответствует идее: пишем так, как понравится тимлиду. Люди не склонны идти на конфликт, и без каких-то общих критериев оценки, команда разработки превращается не в команду инженеров, а в команду художников. "Я так вижу!"
У хороших правил бывают исключения. В некоторых редких случаях требования к оптимизации могут довольно сильно нарушать общие подходы точечно для решения узкоспециализированных проблем. Это не отменяет правило, но говорит о том, что случаи бывают разные и нужно чётко понимать, что и зачем делаешь. Если же отвергать правила потому что я их не понимаю, чего вы пристали, мне так не нравится.. Ну такое.
В конце концов, главная цель любого принципа проектирования — это создание понятного, поддерживаемого и эффективного кода.
Убираем все принципы на полку "какие-то там рекомендации". Озвучьте пожалуйста критерии понятного, поддерживаемого и эффективного кода. Я так понимаю, они у вас сугубо свои. Ведь все принципы это какое-то возведённые в религию зло, окей.
Как вы поймёте, что ваше решение хорошее? И что делать, если другой разработчик, конкретное ваше решение и архитектуру вообще не считает даже близко понятным, поддерживаемым и эффективным? Как вы будете решать эту проблему на одном проекте?
У правила есть такое свойство, если правило не соблюдается, значит это не правило. Принципы это правила, но достаточно абстрактные и общие, поэтому принципы. Они позволяют не только писать хороший код, но и оценивать его качество в сообществе. У каждого может быть своё мнение и взгляды, кто-то может считать, что забивать шурупы молотком это нормально, и вообще чего вы лезете со своей отвёрткой, и возводите это в религию? :)
Не очень понял как терминология влияет на качество тестов. Какую задачу это решает в принципе тоже непонятно.
Изоляция модуля в тестах нужна для того, чтобы сосредоточиться на тестировании его функциональности, без влияния. Это же нужно ещё и для рефакторинга, так тесты модуля не будут ломаться при изменениях в других модулях. Для изоляции нам нужны объекты, имитирующие зависимости. Какая именно имитация нужна? Создаётся мок-объект и настраивается. Какая разница как это называется, Spy, Fake,...etc.? Это для чего нужно?
Ещё раз, всё описанное в статье обычно используется. Но оно именно так не называется, так как часто границы пересекаются. Тот же Moq по сути делает Spy-объекты, потому как считает количество вызовов как минимум. Легко можно настроить и запоминание входных данных вместе с этим.
Сам вопрос какой-то странный. "Если вам нужно 2-4-5..25 инструментария", мне нужны все. Но возможности. А не отдельные какие-то сущности со сложной таксономией.
Не вижу никакого смысла плодить сущности и увеличивать терминологическую сложность на ровном месте без какого-либо выхлопа. Тем более, когда границы у терминов размыты и это создаёт ещё один повод для паралитического тупика: это что? это мок? это спай? это спай-мок? стаб-дамми-спай? Для чего эти заморочки нужны? Ни для чего.
Достаточно банального разделения на стабы и моки. Стаб просто статичная заглушка входных данных, мок имитация поведения, которая может сопровождаться проверкой фактов вызова, а может и нет. Совершенно не принципиально как реализован мок: с помощью библиотечной генерации, собственной реализацией, или их комбинации. С ассертом вызова с данными, или накоплением данных и последующей проверкой, или ещё как-то, при подаче данных, проверке их наличия, сравнения содержимого, количество вызовов, вариаций масса. При желании можно ещё десяток терминов наплодить, но зачем?
Вместо борьбы со сложностью, мы её зачем-то создаём.
Понятно, что это ньюанс, о котором надо знать и помнить, но не хотелось бы погрязнуть в этих ньюансах. Строгая типизация от этого всего защищает. Имея объект типа "словарь", вы никогда не получите из него случайно массив, даже пустой, при любой сериализации, потому что массив это совершенно другой тип, и семантически и физически. Из той же оперы, я бы не хотел даже оказаться в ситуации, когда мне легко удастся сравнить строку и число, хочу стабильную ошибку компиляции в этом месте. Но если сравнение происходит через приведение к общему типу, то результат сравнения должен быть всегда false, независимо от значений. И без знания всяких ньюансов :) Поэтому для меня это немного дико, хотя ньюансы есть везде и порой забористые.
Не фанат PHP, но есть проекты на PHP и хотелось бы решить вот такую серьёзнейшую проблему. Может подскажете? Во всех наших приложениях на .NET, если клиент отвалился, то обработка запроса моментально прекращается. Что бы там не происходило, если был запрос в БД, то он немедленно прерывается, результата не ждём. Если был запрос к другому сервису по HTTP, то он сразу закрывается. Что угодно, везде действует асинхронная кооперативная отмена всей операции, на всех уровнях.
Но в приложениях на PHP имеем такую проблему, когда клиент отваливается (сам, или прокси рубит), PHP продолжает работать и готовить ответ клиенту, который уже давно ушёл. Это забирает драгоценный рабочий процесс (воркер), и провоцирует лавинообразную деградацию, если запросов в один момент было сделано много, из-за интеграций, которые порой затягиваются, или запросов в БД, которая начала подтупливать. В итоге имеем периодическую полную неработоспособность приложения, восстанавливается когда кубер грохает контейнер из-за не отвечающей пробы php fpm. Конечно, мы масштабируем, но эта мера не устраняет проблему, а только уменьшает и откладывает последствия, которые неизбежно настигают. Слишком увлекаться репликами не можем, решение становится очень дорогостоящим по ТСО. Наши разработчики PHP разводят руками, проблема не решаема.
Но всё именно так. Для написания хорошего кода нужен опыт, практика, комплексное понимание технологического стека, используемого языка, самой задачи и сути решения. Если код не нарушает принципы SOLID (и другие), это вовсе не означает сразу, что он качественный. Но их нарушение скорее всего показывает наличие проблем в коде, так называемый "запашок", который требуется устранить.
Поэтому, автор статьи пускается в крайности, и говорит, а давайте я сейчас вам покажу, как легко сделать отвратительный код следуя принципам SOLID. И когда у него это получается, вывод: принципы совсем плохие, чего вы на них молитесь (как будто кто-то молится), давайте их выкинем. При чём принципов гораздо больше, чем SOLID. Если применить и другие, например связность/связанность, выяснится, что этот "солидный" но плохой код нарушает другие принципы. И таки МОЖНО с очень хорошей оценкой выявить проблемы кода, без индивидуализма.
Этот принцип вообще не про интерфейсы (а точнее, абстракции, или контракты), которые здесь выступают именно как решение задачи инверсии зависимостей. Но не самоцель. Если человек ругает DIP, акцентируясь на интерфейсах, значит он не понимает этого принципа.
Ну как это нет, здрасьте. Т.е. взяли и на помойку выкинули весь опыт разработки. И как код ревью проводить? Может и не надо? Пусть каждый пишет вообще как хочет, потому что никаких критериев и быть не может? В общем, приехали.
Не очень понял про сову и глобус. В инверсии зависимостей абстракция это решения основной задачи: инвертировать зависимость. Принцип замечательный, и очень многое расставляет по местам, и снимает кучу проблем. Какая сова?
Очень странно конечно, что за 25 лет карьеры сложилось такое впечатление. У меня 20 лет карьеры, и тоже мог бы много чего рассказать.
Но вы не с той стороны подходите к вопросу. Вы когда-нибудь видели хоть один проект, который бы имел какой-нибудь значок типа "сделано в соответствии с принципами SOLID, DRY, KISS.. etc."? Я не видел. Хотя в рекламных буклетах каких-то проектах можно что-то подобное встретить. Но это не конкретная методология разработки, которая бы конкурировала или противопоставлялась другой. Это консолидированный совокупный опыт написания хорошего кода.
Очень многие разработчики, и даже в комментариях к этой статье, замечали, что с большим опытом разработки и с намерением писать хороший код, он итак получается SOLID-ным. Даже без цели делать его таковым. Это не методика, по которой вы пишите, как по лекалам. Это принципы, которые вы соблюдаете. Но к этом можно прийти неосознанно, или быстрее, но осознанно.
Я часто на собеседованиях задавал такой вопрос "зачем практически нужен SOLID?". Нет, я не спрашивал за каждую букву, мне хотелось услышать, зачем это нужно. Но. К сожалению, не все понимают зачем действительно нужен SOLID. "Чтоб писать хороший код"? Не совсем. Вот прям пишешь код и держишь в уме принципы SOLID? Ну нет конечно :) Или вообще заучили определения для собеседований. И только единицы осознают его применимость.
А применимость у него очень простая. На код ревью разработчики тратят значительно меньше времени, вместо долгого объяснения "на пальца", можно сказать, что вот этот код нарушает такой-то принцип, и это уже само по себе может быть плохо. Да, код не обязан строго следовать никаким принципам, он в первую очередь должен решать задачу. Но при всех равных, если нет причин ему быть другим, то нарушение принципов сигнализирует о проблемах. Это совокупный набор критериев качества, которые всеми понимаются плюс-минус одинаково, и резко сокращает время на обсуждение.
Новым разработчикам, без опыта, сложно писать сразу хороший сопровождаемый код. И принципы помогают хотя обозначить корректный путь. И да, можно искаверкать любые принципы и довести до абсурда. Что на самом деле приведёт к нарушению этих же принципов.
Может быть в вашем опыте, на ваших проектах, у вас все разработчики звёзды, вы на одной волне и все абсолютно одинаково мыслите, вы делаете всё одинаково, понимаете что значит "хороший код" одинаково, вам конечно не нужны никакие талмуды. Вам вообще ничего не нужно, вы уже программисты от бога, всё сразу пишите правильно, хорошо, эффективно, понятно и код идеально сопровождаемый. Просто потому что. Но я работал и работаю с разными людьми, и принципы очень помогают в работе. Не потому, что я на них молюсь, а потому что реально применяю их на практике в командах. И это благоприятно сказывается на разработке.
И после этого, вы заявляете "чушь собачья". Ну да, ну да. Ставим разработку на холд и топаем изучать труды по теориям типов. Потому как их толком никто не знает, а большинство и не слышало даже. Но они есть, и это замечательно. Только работают в узкой специализации.
Простите, но я так и не понял, на основе чего вы сделали вывод "чушь собачья". Если это апелляция к авторитетам, к научным лычкам и званиям, извините, этого недостаточно. Принципы это не теоремы и не законы, которые должны быть доказаны на бумаге. Это консолидация опыта. В научной среде также есть принципы, простые, лаконичные, и не требующие научных выкладок с формулами. Везде они есть. И никто в здравом уме не назовёт их "чушью собачей".
Вообще смысл есть, конечно не до фанатизма, но есть. Даже если исключения просто логируются и нет никакой специальной логики (сейчас), но в логах обычно мы выводим тип исключения в отдельном поле, и в моей практике это много раз позволяло правильно и максимально быстро провести оценку влияния и даже иногда замониторить конкретные типы. Поэтому да, всё вообще можно упростить: зачем нам это, зачем нам то, давайте всё уберём. А конь в вакууме может понадобится именно тогда, когда уже написано тонна кода и дорабатать за вменяемое время уже не получится. Принцип "лучше перебздеть, чем недобздеть" работает всегда, но и нужно соблюдать меру. Если обвес приходится обслуживать и тратить на это ресурсы, надо правильно оценить его необходимость. А если он есть не просит, в чём проблема?
Было бы интересно ознакомится с правильными принципами, правилами, методологией. Если SOLID плохой, ООП плохой, DDD плохой... всё плохое. Познакомьте с хорошим. Или вообще ничего не надо, просто пиши код, как придётся? Или "как договорится команда"? А перешёл в другую команду, там свой "талмуд", при чём даже нигде не описанный, просто на словах. Зачем вообще что-то знать? Книжки читать, так там плохому научат. Консолидированный опыт в топку.
А как должно быть? Люди в халатах с грамотами должны были выковать скрижали в жерле научной группы? Мне нравится ваша попытка обесценить опыт, под соусом "ребята собрались под пивка", но нет. В целом множество проектов, систем и прочего рождено энтузиастами, которым не всё равно.
Всё это никак не соответствует идее написания понятного, поддерживаемого и эффективного кода. То, о чём вы говорите соответствует идее: пишем так, как понравится тимлиду. Люди не склонны идти на конфликт, и без каких-то общих критериев оценки, команда разработки превращается не в команду инженеров, а в команду художников. "Я так вижу!"
Так речь не идёт о красоте. Нравится это понятие сугубо индивидуальное.
У хороших правил бывают исключения. В некоторых редких случаях требования к оптимизации могут довольно сильно нарушать общие подходы точечно для решения узкоспециализированных проблем. Это не отменяет правило, но говорит о том, что случаи бывают разные и нужно чётко понимать, что и зачем делаешь. Если же отвергать правила потому что я их не понимаю, чего вы пристали, мне так не нравится.. Ну такое.
У меня вопрос к автору:
Убираем все принципы на полку "какие-то там рекомендации". Озвучьте пожалуйста критерии понятного, поддерживаемого и эффективного кода. Я так понимаю, они у вас сугубо свои. Ведь все принципы это какое-то возведённые в религию зло, окей.
Как вы поймёте, что ваше решение хорошее? И что делать, если другой разработчик, конкретное ваше решение и архитектуру вообще не считает даже близко понятным, поддерживаемым и эффективным? Как вы будете решать эту проблему на одном проекте?
DIP один из важнейших и полезных принципов. Отрицание, банально, один из признаков не понимания.
У правила есть такое свойство, если правило не соблюдается, значит это не правило. Принципы это правила, но достаточно абстрактные и общие, поэтому принципы. Они позволяют не только писать хороший код, но и оценивать его качество в сообществе. У каждого может быть своё мнение и взгляды, кто-то может считать, что забивать шурупы молотком это нормально, и вообще чего вы лезете со своей отвёрткой, и возводите это в религию? :)
Не очень понял как терминология влияет на качество тестов. Какую задачу это решает в принципе тоже непонятно.
Изоляция модуля в тестах нужна для того, чтобы сосредоточиться на тестировании его функциональности, без влияния. Это же нужно ещё и для рефакторинга, так тесты модуля не будут ломаться при изменениях в других модулях. Для изоляции нам нужны объекты, имитирующие зависимости. Какая именно имитация нужна? Создаётся мок-объект и настраивается. Какая разница как это называется, Spy, Fake,...etc.? Это для чего нужно?
Ещё раз, всё описанное в статье обычно используется. Но оно именно так не называется, так как часто границы пересекаются. Тот же Moq по сути делает Spy-объекты, потому как считает количество вызовов как минимум. Легко можно настроить и запоминание входных данных вместе с этим.
Сам вопрос какой-то странный. "Если вам нужно 2-4-5..25 инструментария", мне нужны все. Но возможности. А не отдельные какие-то сущности со сложной таксономией.
Не вижу никакого смысла плодить сущности и увеличивать терминологическую сложность на ровном месте без какого-либо выхлопа. Тем более, когда границы у терминов размыты и это создаёт ещё один повод для паралитического тупика: это что? это мок? это спай? это спай-мок? стаб-дамми-спай? Для чего эти заморочки нужны? Ни для чего.
Достаточно банального разделения на стабы и моки. Стаб просто статичная заглушка входных данных, мок имитация поведения, которая может сопровождаться проверкой фактов вызова, а может и нет. Совершенно не принципиально как реализован мок: с помощью библиотечной генерации, собственной реализацией, или их комбинации. С ассертом вызова с данными, или накоплением данных и последующей проверкой, или ещё как-то, при подаче данных, проверке их наличия, сравнения содержимого, количество вызовов, вариаций масса. При желании можно ещё десяток терминов наплодить, но зачем?
Вместо борьбы со сложностью, мы её зачем-то создаём.
Понятно, что это ньюанс, о котором надо знать и помнить, но не хотелось бы погрязнуть в этих ньюансах. Строгая типизация от этого всего защищает. Имея объект типа "словарь", вы никогда не получите из него случайно массив, даже пустой, при любой сериализации, потому что массив это совершенно другой тип, и семантически и физически. Из той же оперы, я бы не хотел даже оказаться в ситуации, когда мне легко удастся сравнить строку и число, хочу стабильную ошибку компиляции в этом месте. Но если сравнение происходит через приведение к общему типу, то результат сравнения должен быть всегда false, независимо от значений. И без знания всяких ньюансов :) Поэтому для меня это немного дико, хотя ньюансы есть везде и порой забористые.
curl и запросы в бд тоже прерывает? Не нашёл информации об этом.
upd. Спасибо!
Не фанат PHP, но есть проекты на PHP и хотелось бы решить вот такую серьёзнейшую проблему. Может подскажете? Во всех наших приложениях на .NET, если клиент отвалился, то обработка запроса моментально прекращается. Что бы там не происходило, если был запрос в БД, то он немедленно прерывается, результата не ждём. Если был запрос к другому сервису по HTTP, то он сразу закрывается. Что угодно, везде действует асинхронная кооперативная отмена всей операции, на всех уровнях.
Но в приложениях на PHP имеем такую проблему, когда клиент отваливается (сам, или прокси рубит), PHP продолжает работать и готовить ответ клиенту, который уже давно ушёл. Это забирает драгоценный рабочий процесс (воркер), и провоцирует лавинообразную деградацию, если запросов в один момент было сделано много, из-за интеграций, которые порой затягиваются, или запросов в БД, которая начала подтупливать. В итоге имеем периодическую полную неработоспособность приложения, восстанавливается когда кубер грохает контейнер из-за не отвечающей пробы php fpm. Конечно, мы масштабируем, но эта мера не устраняет проблему, а только уменьшает и откладывает последствия, которые неизбежно настигают. Слишком увлекаться репликами не можем, решение становится очень дорогостоящим по ТСО. Наши разработчики PHP разводят руками, проблема не решаема.
Есть какое-то решение? У нас Yii2. Спасибо!