Pull to refresh
3
Дегтярёв Евгений@bat

Go/PHP Developer

5
Subscribers
Send message

тоже про 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 и все порешает кодогенерация, пока не дочитал до интерфейсов и сабслайсов ))

Простой Map со ссылками тут не обойтись, потому что слайс ссылается не на underline array, а на первый элемент. Я не смог придумать способ копирования таких массивов, который бы не тянул за собой большой оверхед. Если есть идеи — поделитесь в комментариях.

А нельзя сделать интрефейс, реализацией которого тип берет на себя ответственность копирование всякого странного?

"Если ваша должность называется не «Senior Developer» или «Team Lead», а «Инженер 1-ой категории» или...

ахаха, заглянул в трудовую, а там программист 1й категории

И это все на позицию фронтенд?

Если же модификация произошла от руководства, и внедряет темные практики...

а есть счастливчики, у которых было иначе?

Вы продолжаете работать над своей фичей в новой итерации — продолжаете её и углубляете.
Важно, чтобы ваша новая фича-ветка оказалось очень короткоживущей, чтобы ловить минимум конфликтов при слиянии и углубить создание фичи.

Пилите задачи по фиче, чтобы разработка укладывалась в несколкьо дней?

Чистый мастер позволяет вам делать релизы настолько часто, насколько нужно.

Что значит "нечистый" мастер?

Но другие команды разработки тоже делают свои проекты.

Сервис/приложение не закреплен за командой? любая может вносить изменения?

На каком этапе и в какой ветке идет тестирование?

Так и не увидел ответа как быть с рефаторингом?
Мелкий рефакторинг по месту в рамках фичи сделать не получится (не закроешь фичетоглом). Накопление долга потребует большого рефакторинга с теми же ограничениями в большем масштабе?

Как и сказали, фичетоглы в TBD не приимущество, а необходимость. Их можно использовать при любом подходе. А вот менеджить их при росте их количества становится затрано и чревато багами конфигурации.

Получается что моменты, записанные в плюсы TBD, не являются его заслугой. Короткоживущие ветки и фиче тоглы - как нарезать задачи и спланировать фичетоглы так и будет. Конфликты - в git flow если не держать неделями ветку без актуализации с мастером конфликты будут ровно в тех же местах что и в TBD. Стабильность мастера не пострадает, если в него не мержить не протестированую и не закрытую фичетоглом функциональность. Про ТТМ тоже не понятно где TBD приносит профит, по опыту ТТМ страдает на зависимостях от других команд.

тестовое на 40h... такое должно оплачиваться

буду использовать в зависимости от кодостиля вашей компани

скорее, конкретного проекта, а не компании

в любом случае, если собеседующему надо чтобы вы угадали его позицию, а не озвучили свою - это звоночек, там делать нечего

предлагаете вернуться в far/mc/..? брр...

многие боли php там решены на уровне языка

первую очередь строгая типизация

я правильно поимаю, что вы называете болью отсутствие типизации в нетипизированном языке?

Согласен, это не только лишь сам язык. Тем не менее, технология не перестает быть инструментом, одним из многих, который нужно использовать по месту.

Что касается моды. Мне кажется, как раз зрелый разработчик способен не вестись на хайп и трезво оценивать плюсы/минусы того или иного варианта.

Всегда думал, что язык это всего лишь инструмент.

проверил сертификат от марта 21го, сохранен в июле, рабочий

Мой комментарий придирка к слову выжить. Все что описано в статье можно описать одной фразой - поменять стиль вождения.

Да, в хороший минус машина по льду/снегу идет как. Но вот по поводу постоянной температуры - ну не бывает такого. Даже в стабильную погоду качели до 15-20 градусов, в городе менее выражено, за городом более. Например, днем теплеет до 15-20, ночью опускается до 30-40. На фоне этого машина перестала тормозить как летом уже не проблема.

В мороз чистого сухого асфальта нет, на проезжей части намерзает конденсат из выхлопных, особенно в местах концентрации транспорта. Если была оттепель с осадками, потом резкое похоложание, все в лядых колдобинах до след оттепели, если повезет.

Это мнение хабровчанина с юга Сибири. Якутск, наверное, посмеется над морозом -20.

Как выжить зимой. Руководство автомобилиста

хабровчане из регионов с зимой отличной от дефаулт-сити подтянутся и расскажут что значит выжить зимой...

Information

Rating
Does not participate
Location
Алтайский край, Россия
Registered
Activity

Specialization

Бэкенд разработчик