Если сообщество или команда переведёт и будет поддерживать — будет. Так-то я за, но самостоятельно перевод и его поддержку не втащу. Я пишу исходную документацию на английском. Некоторые члены команды, на русском. В этом случае она доступна сразу: https://github.com/yiisoft/yii-cycle/tree/master/docs
Ничего не мешает одновременно и шарить и рассказывать всё-таки основы. Если в приложении полно тривиальных XSS (а это в каждом первом где в команде нет того, кто хоть что-то понимает по теме), то смысла искать и фиксить там 0day никакого.
Пакеты, по идее, всегда должны общаться с другими пакетами через контракт-интерфейс. У Мартина обычно это подразумевается и говоря об изменениях он чаще всего имеет ввиду изменение реализации без изменения контракта. То есть чтобы меняя алгоритм работы не пришлось менять интерфейс и использующие его пакеты.
На самом деле SOLID и пакетные принципы довольно расплывчаты на тему определений и их трактования. На данный момент я думаю что понял их правильно, но если нет — поправьте.
Относительно кода самих библиотек да, невелик. Но сам по себе значителен и, чаще всего, не документирован и просит поддержки. То есть тратим время на дополнительную документацию, на вот этот код, на его поддержку (ту же безопасность поддерживать), на обучение ему новых сотрудников. А плюсы где?
Если сообщество или команда переведёт и будет поддерживать — будет. Так-то я за, но самостоятельно перевод и его поддержку не втащу. Я пишу исходную документацию на английском. Некоторые члены команды, на русском. В этом случае она доступна сразу: https://github.com/yiisoft/yii-cycle/tree/master/docs
Хороший вопрос. https://rmcreative.ru/blog/post/yii-3-i-psr
Кому?
Для участников уже есть. В паблике пока нет.
На месте.
Не должно. Никто не хочет в Битрикс :)
Machine Learning исключите.
Она, в принципе, не очень простая.
OneDrive по соотношеню цена-качество хорош. В отличие от Яндекс.Диска не режет скорость при работе с файлами через API.
Не привязываемся к конкретной ORM.
ActiveRecord будет, но опционально. Тоже отдельный пакет.
По Yii 2 план поддерживать около 5 лет после релиза Yii 3. Это как минимум.
Какие-такие проблемы?
Ничего не мешает одновременно и шарить и рассказывать всё-таки основы. Если в приложении полно тривиальных XSS (а это в каждом первом где в команде нет того, кто хоть что-то понимает по теме), то смысла искать и фиксить там 0day никакого.
У нас выглядит не крайне костыльно. Но да, большая часть фич специфичных просто теряется.
Нормальная история. Фреймворк всё-таки подразумевает что знакомство с основами пройдено.
Пакеты, по идее, всегда должны общаться с другими пакетами через контракт-интерфейс. У Мартина обычно это подразумевается и говоря об изменениях он чаще всего имеет ввиду изменение реализации без изменения контракта. То есть чтобы меняя алгоритм работы не пришлось менять интерфейс и использующие его пакеты.
На самом деле SOLID и пакетные принципы довольно расплывчаты на тему определений и их трактования. На данный момент я думаю что понял их правильно, но если нет — поправьте.
Я бы так не сказал. Тот же Android SDK без документации было бы очень неприятно использовать.
Относительно кода самих библиотек да, невелик. Но сам по себе значителен и, чаще всего, не документирован и просит поддержки. То есть тратим время на дополнительную документацию, на вот этот код, на его поддержку (ту же безопасность поддерживать), на обучение ему новых сотрудников. А плюсы где?
Даже с фреймворком clean code никто не отменял. Накидывайте вопросов, отвечу на все.
Нужен если у вас нет тучи времени и желания собирать свой, писать к нему документацию и поддерживать его. Если есть — тут уже вопрос. Нужно считать.
Тут на вкус и цвет и под задачу. Лучше на конкретном примере.
А как же отсутствие желания писать документацию, учить новых членов команды, тратить время чтобы нормально собрать вместе N библиотек?
Можно и так, но долго.