Cоветы в целом полезные, я бы примеры поправил на более показательные.
Сгруппировал по степени принятия
Категория "мегаимбовая гиперзачетная убербаза"
Не надо пробрасывать в классы весь контейнер целиком
Не мутировать объекты переданные в метод/функцию
Тестируем поведение, а не детали реализации
Композиция, а не наследование
Соблюдаем закон Деметры
Чем меньше методов в интерфейсе, тем лучше (Только это не про SRP, а про Interface Segregation)
Unit тесты всегда
Категория "Чую, куда ветер дует"
Максимально строгая типизация
Заполнение DTO через конструктор с именованными аргументами, readonly свойствами, без get/set методов
По умолчанию указываем final для классов
Не работаем с ассоциативными массивами, только с объектами
Категория "Благие намерения"
В DI подставляем реализации, а не интерфейсы
В интерфейсах указываем какие exception могут быть выброшены
Минимальная цикломатическая сложность
Количество аргументов в функции максимум 3
Категория "Автор что-то имел сказать"
Зависимости в di указываем явно. Явные зависимости в конструкторе класса, autowiring не разу не создавал проблем. Хочу конкретный пример, который убедит меня использовать искусственный идентификатор app.services.my_service в замен натуральному
Каждый класс закрывается интерфейсом Смущает слово "каждый". Это как делать настоящий самолет из лего - мы выкидываем жёсткую связь даже там, где она, прикиньте, бывает полезна.
Разбиваем большие классы и методы По моему опыту, 150 строк на класс в большинстве случаев мало. Конечно, большие классы и методы это хороший признак плохих решений в коде, но делать из него правило с конкретными цифрами, которое надо учитывать при разработке немного сомнительно.
Флаги в аргументах функций Смысл есть, но пример с всего лишь 1 флагом не вдохновляет на подвиги. Также как пример про большие классы - негуманно делать из этого правила (то что соблюдают?), это скорее небольшой notice на будущее.
Преимущество нетипизированых ЯП не в том, что можно не писать типы, а в том, что можно самому решать, когда они нужны, а когда нет.
Есть понятие контрактов - на их уровне типизация крайне полезна. В остальных местах менее важна и во многом зависит от предпочтений разработчиков.
Очевидно, типы увеличивают предсказуемость кода. Не сколько для непосредственно программистов (если они привыкли писать без типов, для них типы реально выглядят как гемор, ну ок), сколько для стат. анализа. А если и стат.анализ не использовать - ну извините, вы просто выбрали нишу разработки, где качество не сильно важно, такое бывает.
Не увидел в примерах пять поколений и перегрузки интерфейсами. И вообще не видел в реальности таких примеров, кроме специально надуманных fuzzBuzz-ов, которыми детей пугают. Что не так с читаемостью? Думаю, важно что php тут не выбран, а является данным контекстом. + php гораздо больше ориентирован на ООП чем на функциональщину, вот и всё
Я предполагаю что кейс такой. Когда вы собираете образ для своего сервиса и этот сервис использует курл как зависимость, вы можете вытянуть бинарник курла в свой образ при сборке, прописав в dockerfile что то вроде
А что такое реальный проект? Очень наивно полагать, что всё IT - это галеры, стартапы и бешеная гонка только за быстрой прибылью. Представьте, что нет nginx, postgres, linux, да и ЯП самих (их вообще пишут больные ублюдки оторванные от реальности). Много ваш бизнес денег заработает?
Опоздали с созданием протоколов безопасности. Похоже на то, как Тим Бернерс-Ли сейчас пытается направить web в "правильное русло", хотя это уже давно информационный Левиафан. Возможно не все это заметили, но ИИ уже слился с интернетом - посредством пользователей ChatGPT, Midjourney, etc.
Не соглашусь. Телега, если присмотреться, не про программистов вообще, а про заказчиков. Тут перечислен набор этических правил, следуя которым заказчик будет восприниматься профессионалом и отношение к нему будет соответствующее. Справедливости ради, у программистов тоже есть свой набор этических правил, которые еще пoжёcтчe будут. Например моё любимое:
"Я всегда буду давать точную и честную оценку. Я не буду давать обещания, которые не могу гарантированно выполнить" (Роберт Мартин "Идеальная работа")
Конечно, это все эти "высокопарности" необязательны, и никто не уволит вас если вы им не следуете. Однако задумайтесь - откуда оно вообще взялось? Уж не от желания ли повышать культуру разработки и качество работы?
У генераторов есть еще одна, менее очевидная область использования - генератор создает корутину, отдельный (но не параллельный) поток выполнения. Эта фича была основой асинхронного програмирования на php почти 10 лет. Сейчас вроде как файберы могу забрать на себя эту функцию, но раз уж завели разговор про то, чем полезны генераторы, упомянуть стоит
Блин, а я думал в статье будут конкретные примеры, очень интересно как эти принципы будут реализованы в процедурном стиле. В идеале - по мотивам https://github.com/torvalds/linux, который как раз представляет собой гигантский проект с приемлемым качеством и реализованный в полностью процедурном стиле. Это было бы гораздо убедительнее.
Пример кода, приведенный как иллюстрация "явности"
public class Foo{
public bool IsValid(int id){
if(id > 10000)
return false;
return true;
}
}
Точно может быть более явным )
public class Foo{
public bool IsValid(int id) {
return id <= 10000;
}
}
Общий посыл статьи мне нравится, но подход "извратить изначальное понимание, напилить странных примеров на основе этого извращенного понимания, а затем доблестно это всё побороть" уже несколько приелся
Да нет, все верно. Имеется в виду, что есть сервер (демон докера, который рулит контейнерами) и клиент (консольная утилита, которая по сокету может передать на сервер команды и получить результат их выполнения). Они могут быть на разных машинах. Более того, один сервер может обслуживать множество клиентов. Все вполне классически )
А мне понравилось. Хорошо поданы самые важные моменты, менее важные - упомянуты и гуглятся в два клика. Из десятка статей по самым основам докера, которые мне попадались на хабре - эта пока в топе
Таким образом, получаем полностью сконфигурированную шину сообщений. Очень просто, не правда ли?
Как раз этот блок конфигураций не сказать что очевидный, особенно тому, кто только начал разбираться.
Разжевали бы, что именно там происходит — полезность статьи сильно бы повысилась.
Вопрос по поводу именования шины ('message-bus').
Имеет ли смысл именовать класс, у которого по определению уже есть имя, причем уникальное?
Иначе говоря, зачем писать
$bus = $this->container->get('message-bus');
если можно
$bus = $this->container->get(MessageBus::class);
плюсы
1) в любой IDE переходим в определение класса по ctrl+ПКМ
2) опять же, при случае, переименовать класс в IDE гораздо удобнее, чем реплейсить строку 'message-bus'
Если вы подразумеваете под архитектурой принцип, по которому файлы
раскидываются по папочкам — да, есть такая тенденция, что фреймворки
это регламентируют все меньше. Как минимум, есть 2 фундаментальных принципа —
разложить по типам (контролеры / вьюшки / исключения и пр.) или же
разложить по фичам (например, есть папка User, в которой все что связано с юзером).
Эта неопределенность действительно немного усложняет вхождение в проект,
но при четком следовании заложенным изначально принципам (которые по хорошему
нужно первый пунктом описать в документации проекта) это не большая проблема.
Под архитектурой проекта можно понимать и логическое деление на компоненты,
а также регламент их взаимодействия. Например, в каком порядке выполняются обработчики запроса или как приложение обрабатывает исключительные ситуации. Это уже завязано на поток выполнения, который контролирует сам фреймворк, и именно это отличает фреймворк от библиотеки. Эти составляющие неизменны и именно их понимание определяет умение разработчика работать с фреймворком.
отличный вариант с весьма низким порогом вхождения, огромным кол-вом гайдов на любые темы и живым комьюнити
Я и про CakePHP это же могу сказать. Symfony c 4 версии например вообще как микрофреймворк позиционируется, простой как 5 копеек. По количеству гайдов и комьюнити с мейнстримом вообще смешно сравнивать.
Понимаете ли в чем дело, Perl тоже хороший язык. Но я бы не рекомендовал начинать сейчас с Perl только потому что он хороший и мне нравится
Cоветы в целом полезные, я бы примеры поправил на более показательные.
Сгруппировал по степени принятия
Категория "мегаимбовая гиперзачетная убербаза"
Не надо пробрасывать в классы весь контейнер целиком
Не мутировать объекты переданные в метод/функцию
Тестируем поведение, а не детали реализации
Композиция, а не наследование
Соблюдаем закон Деметры
Чем меньше методов в интерфейсе, тем лучше (Только это не про SRP, а про Interface Segregation)
Unit тесты всегда
Категория "Чую, куда ветер дует"
Максимально строгая типизация
Заполнение DTO через конструктор с именованными аргументами, readonly свойствами, без get/set методов
По умолчанию указываем final для классов
Не работаем с ассоциативными массивами, только с объектами
Категория "Благие намерения"
В DI подставляем реализации, а не интерфейсы
В интерфейсах указываем какие exception могут быть выброшены
Минимальная цикломатическая сложность
Количество аргументов в функции максимум 3
Категория "Автор что-то имел сказать"
Зависимости в di указываем явно.
Явные зависимости в конструкторе класса, autowiring не разу не создавал проблем.
Хочу конкретный пример, который убедит меня использовать искусственный идентификатор
app.services.my_serviceв замен натуральномуКаждый класс закрывается интерфейсом
Смущает слово "каждый". Это как делать настоящий самолет из лего -
мы выкидываем жёсткую связь даже там, где она, прикиньте, бывает полезна.
Разбиваем большие классы и методы
По моему опыту, 150 строк на класс в большинстве случаев мало. Конечно, большие классы и методы это хороший признак плохих решений в коде, но делать из него правило с конкретными цифрами, которое надо учитывать при разработке немного сомнительно.
Флаги в аргументах функций
Смысл есть, но пример с всего лишь 1 флагом не вдохновляет на подвиги. Также как пример про большие классы - негуманно делать из этого правила (то что соблюдают?), это скорее небольшой notice на будущее.
С какой бы стороны я её не имаджинировал, хоть от меня, хоть ко мне, хвостик всегда справа. Что я делаю не так?
Преимущество нетипизированых ЯП не в том, что можно не писать типы, а в том, что можно самому решать, когда они нужны, а когда нет.
Есть понятие контрактов - на их уровне типизация крайне полезна. В остальных местах менее важна и во многом зависит от предпочтений разработчиков.
Очевидно, типы увеличивают предсказуемость кода. Не сколько для непосредственно программистов (если они привыкли писать без типов, для них типы реально выглядят как гемор, ну ок), сколько для стат. анализа. А если и стат.анализ не использовать - ну извините, вы просто выбрали нишу разработки, где качество не сильно важно, такое бывает.
Не увидел в примерах пять поколений и перегрузки интерфейсами. И вообще не видел в реальности таких примеров, кроме специально надуманных fuzzBuzz-ов, которыми детей пугают.
Что не так с читаемостью? Думаю, важно что php тут не выбран, а является данным контекстом. + php гораздо больше ориентирован на ООП чем на функциональщину, вот и всё
Я предполагаю что кейс такой. Когда вы собираете образ для своего сервиса и этот сервис использует курл как зависимость, вы можете вытянуть бинарник курла в свой образ при сборке, прописав в dockerfile что то вроде
Не берусь судить, насколько это феншуй, но для маленькой утилиты как раз удобно
Афтор, пиши ищо =) Ну или... "ChatGPT, перепиши весь habr в стиле статьи этого чувака"
А что такое реальный проект?
Очень наивно полагать, что всё IT - это галеры, стартапы и бешеная гонка только за быстрой прибылью.
Представьте, что нет nginx, postgres, linux, да и ЯП самих (их вообще пишут больные ублюдки оторванные от реальности). Много ваш бизнес денег заработает?
Опоздали с созданием протоколов безопасности. Похоже на то, как Тим Бернерс-Ли сейчас пытается направить web в "правильное русло", хотя это уже давно информационный Левиафан. Возможно не все это заметили, но ИИ уже слился с интернетом - посредством пользователей ChatGPT, Midjourney, etc.
Не соглашусь. Телега, если присмотреться, не про программистов вообще, а про заказчиков. Тут перечислен набор этических правил, следуя которым заказчик будет восприниматься профессионалом и отношение к нему будет соответствующее. Справедливости ради, у программистов тоже есть свой набор этических правил, которые еще пoжёcтчe будут. Например моё любимое:
"Я всегда буду давать точную и честную оценку. Я не буду давать обещания, которые не могу гарантированно выполнить" (Роберт Мартин "Идеальная работа")
Конечно, это все эти "высокопарности" необязательны, и никто не уволит вас если вы им не следуете. Однако задумайтесь - откуда оно вообще взялось? Уж не от желания ли повышать культуру разработки и качество работы?
У генераторов есть еще одна, менее очевидная область использования - генератор создает корутину, отдельный (но не параллельный) поток выполнения. Эта фича была основой асинхронного програмирования на php почти 10 лет. Сейчас вроде как файберы могу забрать на себя эту функцию, но раз уж завели разговор про то, чем полезны генераторы, упомянуть стоит
ДОС, чёрной пеленой экран заполнил чистый DOS...
Блин, а я думал в статье будут конкретные примеры, очень интересно как эти принципы будут реализованы в процедурном стиле. В идеале - по мотивам https://github.com/torvalds/linux, который как раз представляет собой гигантский проект с приемлемым качеством и реализованный в полностью процедурном стиле. Это было бы гораздо убедительнее.
Пример кода, приведенный как иллюстрация "явности"
Точно может быть более явным )
Общий посыл статьи мне нравится, но подход "извратить изначальное понимание, напилить странных примеров на основе этого извращенного понимания, а затем доблестно это всё побороть" уже несколько приелся
Друг интересуется - творчество порноактрисы по её фото сервис сможет найти?
Да нет, все верно. Имеется в виду, что есть сервер (демон докера, который рулит контейнерами) и клиент (консольная утилита, которая по сокету может передать на сервер команды и получить результат их выполнения). Они могут быть на разных машинах. Более того, один сервер может обслуживать множество клиентов. Все вполне классически )
А мне понравилось. Хорошо поданы самые важные моменты, менее важные - упомянуты и гуглятся в два клика. Из десятка статей по самым основам докера, которые мне попадались на хабре - эта пока в топе
Ну да, например CommandBus, RequestBus, EventBus, отдельные классы выглядят логично
Так или иначе, это строка, и он по этой строке вытаскивает зависимость из контейнера, так что разницы никакой
Как раз этот блок конфигураций не сказать что очевидный, особенно тому, кто только начал разбираться.
Разжевали бы, что именно там происходит — полезность статьи сильно бы повысилась.
Вопрос по поводу именования шины ('message-bus').
Имеет ли смысл именовать класс, у которого по определению уже есть имя, причем уникальное?
Иначе говоря, зачем писать
если можно
плюсы
1) в любой IDE переходим в определение класса по ctrl+ПКМ
2) опять же, при случае, переименовать класс в IDE гораздо удобнее, чем реплейсить строку 'message-bus'
Если вы подразумеваете под архитектурой принцип, по которому файлы
раскидываются по папочкам — да, есть такая тенденция, что фреймворки
это регламентируют все меньше. Как минимум, есть 2 фундаментальных принципа —
разложить по типам (контролеры / вьюшки / исключения и пр.) или же
разложить по фичам (например, есть папка User, в которой все что связано с юзером).
Эта неопределенность действительно немного усложняет вхождение в проект,
но при четком следовании заложенным изначально принципам (которые по хорошему
нужно первый пунктом описать в документации проекта) это не большая проблема.
Под архитектурой проекта можно понимать и логическое деление на компоненты,
а также регламент их взаимодействия. Например, в каком порядке выполняются обработчики запроса или как приложение обрабатывает исключительные ситуации. Это уже завязано на поток выполнения, который контролирует сам фреймворк, и именно это отличает фреймворк от библиотеки. Эти составляющие неизменны и именно их понимание определяет умение разработчика работать с фреймворком.
Я и про CakePHP это же могу сказать. Symfony c 4 версии например вообще как микрофреймворк позиционируется, простой как 5 копеек. По количеству гайдов и комьюнити с мейнстримом вообще смешно сравнивать.
Понимаете ли в чем дело, Perl тоже хороший язык. Но я бы не рекомендовал начинать сейчас с Perl только потому что он хороший и мне нравится