Кастомный тип ошибок(ака исключение нужно типа) удобен хотя бы тем что его можно сматчить, там где это необходимо. Например в тестах.
Такую конструкцию как вы указали, проверять в тестах сомнительно, ибо можно проверить только по тексту. В ином случае тоже будет кастомная ошибка и потом её враппинг с доп контекстом. Но даже при этом проверить например cityName будет сложно в тестах.
В канбане главная метрика это время прохождения задачи через всю доску, от todo до done, не важно сколько там будет статусов, важно полное время прохождения. И вот это как раз создаёт давление. Как и переключения контекста, из-за того что в todo нет фиксированного скоупа задач, он может меняться без ограничений, скачки между разными контекстами весьма вероятны. Что бы этого избежать команда должна прилагать для этого большие усилия, за счёт само организованности и понимания, что и зачем они делают. Большинство команд, на моей практике, такими качествами не обладают, особенно в начале работы. В то время как скрам, со своими "ритуалами" позволяет решать эти вопросы легче при старте новой команды. При этом впоследствии никто не мешает изменять процесс под реалии команды, её состав и внешние факторы. Для этого тоже есть "ритуал" ретроспектива. (если что в канбане без ретроспективы тоже нельзя, просто команда сама должна это понимать) Конечно, в первых спринтах может быть ворох задач, но в дальнейшем команда уже сама будет понимать, сколько она может сделать за спринт. И это зависит по сути от команды, потому что во многом скрам направлен на защиту команды, её спокойную и продуктивную работу. Есть даже график, который показывает уровень "боли" канбана и скрама, в зависимости от времени. И да у скрама "боль" приходит сразу, и потом уменьшается по мере становления процесса, у канбана чуть иначе, но в итоге всё должно прийти к уменьшению этой "боли".
Так же никто не мешает, а часто и прямо рекомендуется, устанавливать лимит задач "in work".
Для меня очевидно что смыслов в спринте много. Например, ограничить скоуп задачь, что бы команда могла спокойно заниматься понятными задачами, в идеале без большого переключения контекста. Сфокусировать усилия команды, на какой-то ограниченной области продукта. Так же, ограничить возможность различных внешних факторов влиять на задачи в спринте (менеджеров например), что бы не бегали каждый день и не меняли приоритеты, запихивали ещё задач и т.д. (если, конечно, это не действительно что-то очень важное, тогда можно и поменять всё, но это должно быть скорее исключение из правил) Так же спринты удобны и для менеджемента, ведь после некоторого времени команда выходит на понятный уровень производительности и можно легко понять, сколько примерно и за какой срок будет сделано, что очень помогает в среднесрочном планировании и не создаёт дополнительного давления на команду. И много других вещей Но ограничение поставки концом спринта, точно не его смысл.
Серебренной пули нет.
Идеально в твоём случае попасть в хорошую команду, где есть люди с понимание и опытом.
Вот я не очень люблю Yii, из за того что мне кажется он уж слишком мало пропагандирует best practics программирования, типа SOLID.
При этом я не могу сказать что, например, Symfony это прям то что нужно что бы эти практики постичь.
Идеально на мой взгляд писать код так что бы он не зависил сильно от фрэймворка. Т.е. когда вся бизнес логика заключена не в ActiveRecord модели, как часто бывает как раз в Yii, и не в контроллерах, а в отдельном месте, и уже для этой логики используется обвязка для использования фрэймвоком этого когда.
А вот как это написать, может сказать только опыт и хорошая команда, в которой такие вещи можно обсудить.
По моему игнорирование composer.lock в конечном коде, самое плохое что можно предложить.
Этот файл фиксирует точные версии всех установленных пакетов, что бы при деплое, и при разработке можно было быть уверенным что новые версии будет соответствовать тем с которыми были выполнялись тесты.
Иначе можно получить ошибки при деплое, так как версия пакета может отличаться от той с которой проводились тесты.
Разработчики на PHP будут рады узнать, что Upsource теперь поддерживает Composer и внешние зависимости.
Это точно, очень рады.
Но я с ходу не смог понять как оно работает и куда нужно эти зависимости положить. И к сожалению не смог найти инструкции по настройке.
Есть ли какое-то описание настройки этой функциональности?
Дело не в успешности, и не в том что кто-то придёт на рынок вторым.
Просто это объективно не нужные трудозатраты. Веб сервер это значительно больше чем то что есть сейчас в PHP. Это множество модулей, которые уже реализованы, и на реализацию которых потрачено множество человеко лет. Нет смысла писать это заново.
> Разработчики php не ставят задачу написать вот сервер не для разработки
Эта фраза о том что сами разработчики PHP не ставят себе задачу написать высокопроизводительный встроенный вебсервер. Так что в ближайшие 5 лет ждать координальных изменений не стоит.
Это может быть обусловлено тем что sublime создаёт всплывающие окна иными средствами, и DE не считает их окнами. По типу того как можно просто нарисовать html окно.
Я об этом написал в своем комментарии
Суть в том что при таком подходе, а он как по мне верный, отличный от отдельного класса исключения нет.
В приведенном же коде, с fmt.Errorf, проверить можно только ту ошибку что вернётся из GetPosition
Кастомный тип ошибок(ака исключение нужно типа) удобен хотя бы тем что его можно сматчить, там где это необходимо. Например в тестах.
Такую конструкцию как вы указали, проверять в тестах сомнительно, ибо можно проверить только по тексту. В ином случае тоже будет кастомная ошибка и потом её враппинг с доп контекстом. Но даже при этом проверить например cityName будет сложно в тестах.
В канбане главная метрика это время прохождения задачи через всю доску, от todo до done, не важно сколько там будет статусов, важно полное время прохождения. И вот это как раз создаёт давление.
Как и переключения контекста, из-за того что в todo нет фиксированного скоупа задач, он может меняться без ограничений, скачки между разными контекстами весьма вероятны. Что бы этого избежать команда должна прилагать для этого большие усилия, за счёт само организованности и понимания, что и зачем они делают. Большинство команд, на моей практике, такими качествами не обладают, особенно в начале работы.
В то время как скрам, со своими "ритуалами" позволяет решать эти вопросы легче при старте новой команды. При этом впоследствии никто не мешает изменять процесс под реалии команды, её состав и внешние факторы. Для этого тоже есть "ритуал" ретроспектива. (если что в канбане без ретроспективы тоже нельзя, просто команда сама должна это понимать)
Конечно, в первых спринтах может быть ворох задач, но в дальнейшем команда уже сама будет понимать, сколько она может сделать за спринт. И это зависит по сути от команды, потому что во многом скрам направлен на защиту команды, её спокойную и продуктивную работу.
Есть даже график, который показывает уровень "боли" канбана и скрама, в зависимости от времени.
И да у скрама "боль" приходит сразу, и потом уменьшается по мере становления процесса, у канбана чуть иначе, но в итоге всё должно прийти к уменьшению этой "боли".
Так же никто не мешает, а часто и прямо рекомендуется, устанавливать лимит задач "in work".
Для меня очевидно что смыслов в спринте много.
Например, ограничить скоуп задачь, что бы команда могла спокойно заниматься понятными задачами, в идеале без большого переключения контекста.
Сфокусировать усилия команды, на какой-то ограниченной области продукта.
Так же, ограничить возможность различных внешних факторов влиять на задачи в спринте (менеджеров например), что бы не бегали каждый день и не меняли приоритеты, запихивали ещё задач и т.д. (если, конечно, это не действительно что-то очень важное, тогда можно и поменять всё, но это должно быть скорее исключение из правил)
Так же спринты удобны и для менеджемента, ведь после некоторого времени команда выходит на понятный уровень производительности и можно легко понять, сколько примерно и за какой срок будет сделано, что очень помогает в среднесрочном планировании и не создаёт дополнительного давления на команду.
И много других вещей
Но ограничение поставки концом спринта, точно не его смысл.
А что мешает релизить фичи, по мере готовности? Кто заставляет ждать конца спринта?
Мой основной посыл был именно в том что PHP сам по себе не течёт уже давно.
Хотя при желании их можно сделать самому. Но в целом сборщик мусора всё собирает нормально.
Автор предлагает написать простой ValueObject, что в целом очень удобно и даёт дополнительную проверку типов.
Идеально в твоём случае попасть в хорошую команду, где есть люди с понимание и опытом.
Вот я не очень люблю Yii, из за того что мне кажется он уж слишком мало пропагандирует best practics программирования, типа SOLID.
При этом я не могу сказать что, например, Symfony это прям то что нужно что бы эти практики постичь.
Идеально на мой взгляд писать код так что бы он не зависил сильно от фрэймворка. Т.е. когда вся бизнес логика заключена не в ActiveRecord модели, как часто бывает как раз в Yii, и не в контроллерах, а в отдельном месте, и уже для этой логики используется обвязка для использования фрэймвоком этого когда.
А вот как это написать, может сказать только опыт и хорошая команда, в которой такие вещи можно обсудить.
Этот файл фиксирует точные версии всех установленных пакетов, что бы при деплое, и при разработке можно было быть уверенным что новые версии будет соответствовать тем с которыми были выполнялись тесты.
Иначе можно получить ошибки при деплое, так как версия пакета может отличаться от той с которой проводились тесты.
Это точно, очень рады.
Но я с ходу не смог понять как оно работает и куда нужно эти зависимости положить. И к сожалению не смог найти инструкции по настройке.
Есть ли какое-то описание настройки этой функциональности?
Просто это объективно не нужные трудозатраты. Веб сервер это значительно больше чем то что есть сейчас в PHP. Это множество модулей, которые уже реализованы, и на реализацию которых потрачено множество человеко лет. Нет смысла писать это заново.
> Разработчики php не ставят задачу написать вот сервер не для разработки
Эта фраза о том что сами разработчики PHP не ставят себе задачу написать высокопроизводительный встроенный вебсервер. Так что в ближайшие 5 лет ждать координальных изменений не стоит.