Как выше уже было сказано - роль тимлида сильно зависит от компании. Где то это просто техлид, где то занимается people менеджментом, где то отвечает за зарплаты, где то является solution архитектором, у кого-то в подчинени 5 человек, у кого-то 35. И вот от набора этих самых является и зависит должен ли тимлид писать код или нет.
У нас в компании считается что тимлид не должен писать код при этом если он его пишет - это не возбраняется, но лишь при условии что остальные «обязательные» активности не страдают.
Сам я с мнением автора насчет потери квалификации не согласен, вполне можно регулярно читать код своей команды и оставаться «в тренде», выполняя функции технического менеджера.
А если приложение крутится в докере, какой подход правильнее: подкрутить php-fpm или просто поднять N дополнительных контейнеров для распределения нагрузки?
Если фичи разные, то есть и ветки разные, то наш key value позволяет прописывать кастомные переменные окружения для какой из веток(стендов). То есть просто алгоритм описанный выше х2.
Если ветка одна, но по каким то причинам хотят тестировать несколько человек - то тестируют на одном стенде. Теоретически есть возможность поднять клон, но на практике так никто не делает.
У нас на ветках автоматически разворачивается стенд сервиса, который смотрит на мастера других сервисов, делается через gitlab ci. Мастера других сервисов подняты всегда. Соответсвенно базовый сценарий тестирования , когда пилится какая то фича в сервисе 1, а в других ничего не меняется, происходит автоматически. Внешние контракты сервиса 1 проверяются автотестами.
Интереснее когда пилятся два и более сервисов одновременно и их нужно потестировать между собой. В этом случае мы руками идём прописываем в нашем key-value хранилище (используем консул) ссылки на нужные стенды(вместо мастеров). Да это не так удобно, но надо достаточно редко
Не использовать для тестирования классов с большим количеством зависимостей юнит-тесты. Заменять их e-2-e или интеграционным тестами. По опыту чем больше зависимостей ты мокаешь, тем хрупче твой тест, и любое изменение в классе, даже без изменения внешнего контракта, перерастает в борьбу с тестами.
На мой взгляд, если и пользоваться моками в юнит-тестах, то только в качестве заглушек, а не шпионов. То есть без вызова expect. Аргументация: нарушения инкапсуляции.
Интеграционный тест, это такой тест, в котором тестируется что то вам не подконтрольное(БД, внешний API, обращение к datetime хоста), то есть не может выполняться условие что при одних и тех же параметрах(версия php, набор зависимостей), на выходе получаем те же результаты.
Если мы тестируем взаимодействие модулей между собой, при этом нет того, что я описал выше — это все то же юнит-тестирование.
Базовые классы — весьма сомнительный подход. По возможности лучше использовать композицию вместо наследования, да это более трудозатратно за счёт инжекта зависимости, зато более универсально и поддерживаемо, и не подвержено side эффектам.
Если нужен какой-то общий признак на уровне классов, то используйте пустой интерфейс.
А точная программа на 16 июня уже определена? Это https://yiiconf.ru/ru/offers/Common — участники докладов(16.06), а это https://yiiconf.ru/ru/offers/Workshop участники мастер классов(18.06), все правильно?
Правильно ли понимаю, что билет по тарифу Lite позволяет только послушать участников докладов 16 июня, но не дает право прохода на мастер-классы 18.06?
Как выше уже было сказано - роль тимлида сильно зависит от компании. Где то это просто техлид, где то занимается people менеджментом, где то отвечает за зарплаты, где то является solution архитектором, у кого-то в подчинени 5 человек, у кого-то 35. И вот от набора этих самых является и зависит должен ли тимлид писать код или нет.
У нас в компании считается что тимлид не должен писать код при этом если он его пишет - это не возбраняется, но лишь при условии что остальные «обязательные» активности не страдают.
Сам я с мнением автора насчет потери квалификации не согласен, вполне можно регулярно читать код своей команды и оставаться «в тренде», выполняя функции технического менеджера.
А если приложение крутится в докере, какой подход правильнее: подкрутить php-fpm или просто поднять N дополнительных контейнеров для распределения нагрузки?
Если фичи разные, то есть и ветки разные, то наш key value позволяет прописывать кастомные переменные окружения для какой из веток(стендов). То есть просто алгоритм описанный выше х2.
Если ветка одна, но по каким то причинам хотят тестировать несколько человек - то тестируют на одном стенде. Теоретически есть возможность поднять клон, но на практике так никто не делает.
У нас на ветках автоматически разворачивается стенд сервиса, который смотрит на мастера других сервисов, делается через gitlab ci. Мастера других сервисов подняты всегда. Соответсвенно базовый сценарий тестирования , когда пилится какая то фича в сервисе 1, а в других ничего не меняется, происходит автоматически. Внешние контракты сервиса 1 проверяются автотестами.
Интереснее когда пилятся два и более сервисов одновременно и их нужно потестировать между собой. В этом случае мы руками идём прописываем в нашем key-value хранилище (используем консул) ссылки на нужные стенды(вместо мастеров). Да это не так удобно, но надо достаточно редко
Не использовать для тестирования классов с большим количеством зависимостей юнит-тесты. Заменять их e-2-e или интеграционным тестами.
По опыту чем больше зависимостей ты мокаешь, тем хрупче твой тест, и любое изменение в классе, даже без изменения внешнего контракта, перерастает в борьбу с тестами.
На мой взгляд, если и пользоваться моками в юнит-тестах, то только в качестве заглушек, а не шпионов. То есть без вызова expect. Аргументация: нарушения инкапсуляции.
Интеграционный тест, это такой тест, в котором тестируется что то вам не подконтрольное(БД, внешний API, обращение к datetime хоста), то есть не может выполняться условие что при одних и тех же параметрах(версия php, набор зависимостей), на выходе получаем те же результаты.
Если мы тестируем взаимодействие модулей между собой, при этом нет того, что я описал выше — это все то же юнит-тестирование.
Базовые классы — весьма сомнительный подход. По возможности лучше использовать композицию вместо наследования, да это более трудозатратно за счёт инжекта зависимости, зато более универсально и поддерживаемо, и не подвержено side эффектам.
Если нужен какой-то общий признак на уровне классов, то используйте пустой интерфейс.
Правильно ли понимаю, что билет по тарифу Lite позволяет только послушать участников докладов 16 июня, но не дает право прохода на мастер-классы 18.06?