Прикольно, инфа про json-iterator/go давно попадалась, наверное здесь же на хабре, запомнилось как что прям супер быстрое. Здесь же на уровне стандартной библиотеки. График в репозитарии показывает, разницу чуть ли не порядок. Хз когда запускали тест, но закомичен он 7 лет назад. Либо тест такой тест либо прозводительность encoding/json за это время подтянули.
С пол года назад было, беседа с командой, несколько человек было с той стороный тим лид / тех лид / продакт, точно не помню. Один из них через некоторое время достал свиток начал парить. Ну такое себе...
22й год, PHP 7.0, ZF2, PHPUnit 5, кода поменьше, % покрытия тестами примерно такой же
Обновлялись постепенно. На первом этапе относительно безболезненно сначала phpunit5 -> phpunit6, затем php7.0 -> php7.3 (макс что поддерживает phpunit6). Обновлять сразу и то и то я очканул. В коде правок не было, только тесты (phpunit переехал на неймспейсы). Затем обновление phpunit6 -> phpunit9 (исправление сигнатур унаследованных методов TestCase и того что стало deprecated типа @expectedExceptionи MockObject\Matcher ) и, судя по логу, безболезненное переключение на php 7.4. После с небольшими, но грязными правками прям в vendor, на php 8.0.
На 8.1 ZF2 сыпал тоннами ошибок ((
Через полгода после предварительной подготовки исходников ZF2 -> ZF3 -> Laminas. Тут были изменения интерфейсов фабрик и слушателей, избавление от сервислокатора в коде (оставили только в контроллерах), регистрозависимость ключей в сервис локаторе. Отдельная подстава была от zend session, который в сессии хранит \Zend\Stdlib\ArrayObject.
В начале подумал что это для DTO и все порешает кодогенерация, пока не дочитал до интерфейсов и сабслайсов ))
Простой Map со ссылками тут не обойтись, потому что слайс ссылается не на underline array, а на первый элемент. Я не смог придумать способ копирования таких массивов, который бы не тянул за собой большой оверхед. Если есть идеи — поделитесь в комментариях.
А нельзя сделать интрефейс, реализацией которого тип берет на себя ответственность копирование всякого странного?
Вы продолжаете работать над своей фичей в новой итерации — продолжаете её и углубляете. Важно, чтобы ваша новая фича-ветка оказалось очень короткоживущей, чтобы ловить минимум конфликтов при слиянии и углубить создание фичи.
Пилите задачи по фиче, чтобы разработка укладывалась в несколкьо дней?
Чистый мастер позволяет вам делать релизы настолько часто, насколько нужно.
Что значит "нечистый" мастер?
Но другие команды разработки тоже делают свои проекты.
Сервис/приложение не закреплен за командой? любая может вносить изменения?
На каком этапе и в какой ветке идет тестирование?
Так и не увидел ответа как быть с рефаторингом? Мелкий рефакторинг по месту в рамках фичи сделать не получится (не закроешь фичетоглом). Накопление долга потребует большого рефакторинга с теми же ограничениями в большем масштабе?
Как и сказали, фичетоглы в TBD не приимущество, а необходимость. Их можно использовать при любом подходе. А вот менеджить их при росте их количества становится затрано и чревато багами конфигурации.
Получается что моменты, записанные в плюсы TBD, не являются его заслугой. Короткоживущие ветки и фиче тоглы - как нарезать задачи и спланировать фичетоглы так и будет. Конфликты - в git flow если не держать неделями ветку без актуализации с мастером конфликты будут ровно в тех же местах что и в TBD. Стабильность мастера не пострадает, если в него не мержить не протестированую и не закрытую фичетоглом функциональность. Про ТТМ тоже не понятно где TBD приносит профит, по опыту ТТМ страдает на зависимостях от других команд.
Про стек в 4Мб тоже дичь
Прикольно, инфа про json-iterator/go давно попадалась, наверное здесь же на хабре, запомнилось как что прям супер быстрое. Здесь же на уровне стандартной библиотеки. График в репозитарии показывает, разницу чуть ли не порядок. Хз когда запускали тест, но закомичен он 7 лет назад. Либо тест такой тест либо прозводительность encoding/json за это время подтянули.
соглашусь с комментариями выше, не хватает flatbuffers и easyjson
тоже про gob вспомнил, но оно актуально только для go экосистемы
С пол года назад было, беседа с командой, несколько человек было с той стороный тим лид / тех лид / продакт, точно не помню. Один из них через некоторое время достал свиток начал парить. Ну такое себе...
бывало ни зрасти ни досвидания - ищем разработчика и ссылка на гуглодок с тестовым...
эт ппц
зачем так вкусно рассказываете... карцев с монологом про завтрак вспомнился
А что с листингами исходного кода и консоли? Нельзя было причесать, чтобы это нормально выглядело и читалось?
о как знакомо
22й год, PHP 7.0, ZF2, PHPUnit 5, кода поменьше, % покрытия тестами примерно такой же
Обновлялись постепенно.
На первом этапе относительно безболезненно сначала phpunit5 -> phpunit6, затем php7.0 -> php7.3 (макс что поддерживает phpunit6). Обновлять сразу и то и то я очканул. В коде правок не было, только тесты (phpunit переехал на неймспейсы).
Затем обновление phpunit6 -> phpunit9 (исправление сигнатур унаследованных методов TestCase и того что стало deprecated типа @expectedExceptionи MockObject\Matcher ) и, судя по логу, безболезненное переключение на php 7.4. После с небольшими, но грязными правками прям в vendor, на php 8.0.
На 8.1 ZF2 сыпал тоннами ошибок ((
Через полгода после предварительной подготовки исходников ZF2 -> ZF3 -> Laminas.
Тут были изменения интерфейсов фабрик и слушателей, избавление от сервислокатора в коде (оставили только в контроллерах), регистрозависимость ключей в сервис локаторе. Отдельная подстава была от zend session, который в сессии хранит \Zend\Stdlib\ArrayObject.
Норм. Спасибо, что поделились.
В начале подумал что это для DTO и все порешает кодогенерация, пока не дочитал до интерфейсов и сабслайсов ))
А нельзя сделать интрефейс, реализацией которого тип берет на себя ответственность копирование всякого странного?
ахаха, заглянул в трудовую, а там программист 1й категории
И это все на позицию фронтенд?
а есть счастливчики, у которых было иначе?
Пилите задачи по фиче, чтобы разработка укладывалась в несколкьо дней?
Что значит "нечистый" мастер?
Сервис/приложение не закреплен за командой? любая может вносить изменения?
На каком этапе и в какой ветке идет тестирование?
Так и не увидел ответа как быть с рефаторингом?
Мелкий рефакторинг по месту в рамках фичи сделать не получится (не закроешь фичетоглом). Накопление долга потребует большого рефакторинга с теми же ограничениями в большем масштабе?
Как и сказали, фичетоглы в TBD не приимущество, а необходимость. Их можно использовать при любом подходе. А вот менеджить их при росте их количества становится затрано и чревато багами конфигурации.
Получается что моменты, записанные в плюсы TBD, не являются его заслугой. Короткоживущие ветки и фиче тоглы - как нарезать задачи и спланировать фичетоглы так и будет. Конфликты - в git flow если не держать неделями ветку без актуализации с мастером конфликты будут ровно в тех же местах что и в TBD. Стабильность мастера не пострадает, если в него не мержить не протестированую и не закрытую фичетоглом функциональность. Про ТТМ тоже не понятно где TBD приносит профит, по опыту ТТМ страдает на зависимостях от других команд.
тестовое на 40h... такое должно оплачиваться
скорее, конкретного проекта, а не компании
в любом случае, если собеседующему надо чтобы вы угадали его позицию, а не озвучили свою - это звоночек, там делать нечего
предлагаете вернуться в far/mc/..? брр...
я правильно поимаю, что вы называете болью отсутствие типизации в нетипизированном языке?
Согласен, это не только лишь сам язык. Тем не менее, технология не перестает быть инструментом, одним из многих, который нужно использовать по месту.
Что касается моды. Мне кажется, как раз зрелый разработчик способен не вестись на хайп и трезво оценивать плюсы/минусы того или иного варианта.
Всегда думал, что язык это всего лишь инструмент.