конец нулевых, самописаный сервис деск на пыхе, ловим странное исключение в логе... нахожу его в коде, а там после обработки пачки кейсов, которые по задумке покрывают все случаи, стоит выброс исключения с комментарием - этого никогда не должно случится
Прикольно, инфа про 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 приносит профит, по опыту ТТМ страдает на зависимостях от других команд.
За годы опыта офферы, конечно, не дают. Я про предложения от рекрутеров, сам не откликался, входящих предложений хватило.
ps
офферы тоже были
На последнем месте проработал 16.5 лет. В сентябре искал работу, не заметил недостатка предложений.
конец нулевых, самописаный сервис деск на пыхе, ловим странное исключение в логе... нахожу его в коде, а там после обработки пачки кейсов, которые по задумке покрывают все случаи, стоит выброс исключения с комментарием - этого никогда не должно случится
Про стек в 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/..? брр...