Я думаю, ревью это не тот этап, на котором нужно вспоминать, что оказывается, нужно обучение и обмен опытом. Это должно делаться где-то гораздо раньше - на внутренних митапах, в сессиях параллельного программирования и т.п. А не блокировать все тогда, когда весь код уже написан, и задача ждёт только апрува.
Если мне требуется разработчик с опытом работы на laravel + react/vue от года, зачем мне рассматривать бэкендера с опытом 2 года на flask?
Я бы поспорил с самим подходом вида "требуется разработчик с опытом работы на Laravel" - когда тот, кто писал CRUD-ы на Laravel подходит, а вот если писал те же самые CRUD-ы на Flack, то уже не подходит.
Такой фильтр разве что удобен для автоматического отсеивания резюме. И, возможно, несколько лет назад он был оправдан, когда скорость входа в новый проект сильно зависела от того, что человек набил руку именно на определенном языке программирования или фреймворке.
Но сейчас, с появлением LLM и агентных инструментов, языки и фреймворки постепенно становятся вторичными: с этими инструментами хороший разработчик быстро освоит и Laravel, и Flask, если у него есть опыт веб-разработки, понимание HTTP/REST, БД, миграций, транзакций, очередей, кешей, безопасности, тестирования, эксплуатации.
Поэтому, искать надо не "разработчика именно на PHP такой-то версии и именно на Laravel", а человека, который умеет создавать продукт: проектировать архитектуру, писать поддерживаемый код, дебажить, обеспечивать надежность сервисов и т.п.
Наконец-то кто-то написал по этой теме действительно дельные вещи, а не шаблонные вбросы про какую-то великую добавленную сложность или про то, что целый 1 дополнительный раз нужно мышкой кликнуть, чтобы попасть в реализацию метода :)
Честно говоря, создается ощущение, что это какие-то выдуманные истории. Потому что очень уж много ляпов и несостыковок.
Например, в случае №1 человеку хватает знаний, чтобы заработать денег на 2 квартиры в ОАЭ и в Испании, он покупает и продает их туда-сюда, но не прочитал даже азы налогового законодательства при этом??
Или вот, в случае №4, например:
для доказательства налогового нерезидентства РФ от него ждут сертификат о налоговом резидентстве Кипра.
Это вы сами придумали? С каких пор у нас при проведении в РФ меньше 183 дней в году, нужно еще доказывать наличие или отсутствие налогового резидентства в других странах? В п. 2 ст. 207 НК РФ вроде бы все четко указано, кто и когда считается налоговым резидентом. Более того, можно быть налоговым резидентом сразу двух стран, потому что не везде это определяется именно по количеству дней нахождения в стране.
Я и не писал про обязательность. Я сказал, что работа и семья не исключает возможности уделять время и саморазвитию, в том числе и через создание публичных проектов.
Это вроде бы не взаимоисключающие вещи, пару часов в неделю всегда можно найти. Потому что если никогда не выходить за рамки повседневных рабочих задач с 9:00 до 18:00, и никак не инвестировать в расширение своего кругозора и навыков, то через какое-то время востребованность на рынке начнет неизбежно проседать.
Важно, что IC — это финальная роль, а не промежуточный этап.
IC это не роль, а целая ветка развития инженеров (или семейство ролей), как альтернатива менеджерской ветке. Создаётся впечатление, что в целом в статье в нескольких местах путается понятие Individual Contributor и Staff+. Фактически, и Senior это тоже IC, но только на более низком грейде.
Зачем давать столько имен одному и тому же? Тех лид - это тогда кто? Он круче принципала?
Потому что Staff это грейд, а Tech Lead это конкретная функция внутри команды. Staff может взять на себя функцию техлида, но этим его диапазон не ограничен. Он также может курировать кросс-командные технические инициативы, может разрабатывать фреймворк, которым пользуется множество команд - и все это будет Staff.
Проблема просто в том, что в статьях на эту тему часто смешивают все в кучу, используя для одного и того же обозначения термины IC, Staff, Tech Lead и т.п.
Классика. Бюджет ограничен, но вместо того чтобы попытаться привести в порядок код на PHP, переписываем все на два других языка, экономя аж целых 45 MB памяти)
Юнит-тесты это чаще всего и есть самый точный и дешевый способ сделать то, что делается при white-box тестировании.
Если юнит-тест то проходит, то нет, это вопрос к тем кто его писал, а не к самой концепции. Даже более того, за счет того что в юнит-тестах нет сети, БД и тому подобного, шанс flakebility при правильном написании даже ниже, чем у функциональных/приемочных тестов.
Ну, и гораздо полезнее, когда CI загорается красным сразу после некорректного коммита, а не спустя полдня, когда упал регресс-ран из e2e-сценариев.
Если вы отключаете хрупкие юнит-тесты в CI, а не чините их, то это опять вопрос к тем, кто работает над проектом, а не к самой концепции.
Приёмочные и функциональные тесты проверяют сквозные пользовательские сценарии (happy path + несколько граничных) и требуют обычно полного запуска системы с базой, брокером и т.п.
Если вместо использования юнит-тестов, вы будете пытаться тестировать все инварианты через перебор комбинаций входов в функциональных тестах, вам нужен будет по меньшей мере квантовый CI-сервер, потому что это будет очень-очень долго и тяжеловесно.
В нормальной разработке вместо этого юнит-тесты обычно используются чтобы быстро прогнать много граничных комбинаций за секунды и показать точный метод, где упал инвариант. Поэтому, говорить что юнит-тесты не нужны значит недооценивать само их предназначение.
Когда я вижу очередную статью или видеоурок про тестирование кода, я почти уверен, что мне опять расскажут про моки.
Создаётся впечатление, что это самый лучший и правильный способ писать тесты, и вообще, невозможно обойтись без моков.
Да? А у меня, наоборот, создается впечатление, что из каждого утюга стало модно кричать про то, что моки и юнит-тесты не нужны, а нужны только интеграционные тесты. Хотя, у этих инструментов в целом разное предназначение.
А то что юнит-тесты позволяют очень точно протестировать бизнес-логику и покрыть граничные случаи, которые или очень тяжело или вообще невозможно покрыть огромными интеграционными тестами - это конечно же БЕСПОЛЕЗНО :)
Каждый раз, когда читаю очередную похожую статью, возникает ощущение, что наше понимание того, что является хорошим или плохим кодом, постепенно движется куда-то не в ту сторону. Упрощение ради самого упрощения стало идеей фикс.
Безусловно, в статье есть и дельные мысли. Но не покидает чувство попытки любые правила назвать "старыми привычками" и преподносить антипаттерны как полезные рекомендации. Те же толстые контроллеры, за которые раньше били по рукам новичков, теперь вдруг стали хорошим подходом.
Увеличилось быстродействие — переход с Akka на Spring в среднем увеличил производительность REST в 1,5—2 раза.
Вспоминается известный сценарий: в плохо организованном проекте на PHP возникает евангелист Go, переписывает всё с нуля, а затем приписывает весь прирост скорости самому языку, забывая, что главная проблема может быть в неудачной реализации.
И в этой статье примерно так же, многие аргументы звучат не как объективный анализ технологий, а больше как "не умею или не хочу разбираться с тем, что есть, поэтому затащу любимый Spring".
Не надо путать "стрельбу дробью" и обычную сквозную трассировку одной доменной идеи через предусмотренные слои. Причем, локализованную bounded context-ом.
Вот где настоящая "стрельба дробью", это где прокидывают поля из БД чуть ли не напрямую до UI "as-is". По сути, тогда мы делаем структуру таблиц БД публичным контрактом сразу для всех частей системы. И любая правка этой структуры будет размазываться дробью по проекту. Так что, по сути DDD, наоборот, лечит эту проблему.
Я думаю, ревью это не тот этап, на котором нужно вспоминать, что оказывается, нужно обучение и обмен опытом. Это должно делаться где-то гораздо раньше - на внутренних митапах, в сессиях параллельного программирования и т.п. А не блокировать все тогда, когда весь код уже написан, и задача ждёт только апрува.
Я бы поспорил с самим подходом вида "требуется разработчик с опытом работы на Laravel" - когда тот, кто писал CRUD-ы на Laravel подходит, а вот если писал те же самые CRUD-ы на Flack, то уже не подходит.
Такой фильтр разве что удобен для автоматического отсеивания резюме. И, возможно, несколько лет назад он был оправдан, когда скорость входа в новый проект сильно зависела от того, что человек набил руку именно на определенном языке программирования или фреймворке.
Но сейчас, с появлением LLM и агентных инструментов, языки и фреймворки постепенно становятся вторичными: с этими инструментами хороший разработчик быстро освоит и Laravel, и Flask, если у него есть опыт веб-разработки, понимание HTTP/REST, БД, миграций, транзакций, очередей, кешей, безопасности, тестирования, эксплуатации.
Поэтому, искать надо не "разработчика именно на PHP такой-то версии и именно на Laravel", а человека, который умеет создавать продукт: проектировать архитектуру, писать поддерживаемый код, дебажить, обеспечивать надежность сервисов и т.п.
Наконец-то кто-то написал по этой теме действительно дельные вещи, а не шаблонные вбросы про какую-то великую добавленную сложность или про то, что целый 1 дополнительный раз нужно мышкой кликнуть, чтобы попасть в реализацию метода :)
Я не писал про плохо или хорошо. Мой комментарий про наличие опций роста не только в сторону менеджмента.
Есть много людей, которым комфортно и интересно продолжать работать в чистом разработческом фокусе, и в этом нет проблем.
Но тем, кто хочет более стратегических задач, не обязательно идти именно в управление людьми.
Честно говоря, создается ощущение, что это какие-то выдуманные истории. Потому что очень уж много ляпов и несостыковок.
Например, в случае №1 человеку хватает знаний, чтобы заработать денег на 2 квартиры в ОАЭ и в Испании, он покупает и продает их туда-сюда, но не прочитал даже азы налогового законодательства при этом??
Или вот, в случае №4, например:
Это вы сами придумали? С каких пор у нас при проведении в РФ меньше 183 дней в году, нужно еще доказывать наличие или отсутствие налогового резидентства в других странах? В п. 2 ст. 207 НК РФ вроде бы все четко указано, кто и когда считается налоговым резидентом. Более того, можно быть налоговым резидентом сразу двух стран, потому что не везде это определяется именно по количеству дней нахождения в стране.
Вряд ли есть какой-то единый список, но из того, что я встречал, есть два технических направления для роста:
Ветка Staff → Principal → Distinguished.
Разные виды архитекторов: Solution Architect, Software Architect, Data Architect, Enterprise Architect.
Непонятно только, почему выбор сводится только к тому чтобы либо идти управлять людьми, либо вечно быть в роли разработчика.
Есть же и технические направления роста вплоть до Architect и Principal Engineer :)
Я и не писал про обязательность. Я сказал, что работа и семья не исключает возможности уделять время и саморазвитию, в том числе и через создание публичных проектов.
Это вроде бы не взаимоисключающие вещи, пару часов в неделю всегда можно найти. Потому что если никогда не выходить за рамки повседневных рабочих задач с 9:00 до 18:00, и никак не инвестировать в расширение своего кругозора и навыков, то через какое-то время востребованность на рынке начнет неизбежно проседать.
IC это не роль, а целая ветка развития инженеров (или семейство ролей), как альтернатива менеджерской ветке. Создаётся впечатление, что в целом в статье в нескольких местах путается понятие Individual Contributor и Staff+. Фактически, и Senior это тоже IC, но только на более низком грейде.
Потому что Staff это грейд, а Tech Lead это конкретная функция внутри команды. Staff может взять на себя функцию техлида, но этим его диапазон не ограничен. Он также может курировать кросс-командные технические инициативы, может разрабатывать фреймворк, которым пользуется множество команд - и все это будет Staff.
Проблема просто в том, что в статьях на эту тему часто смешивают все в кучу, используя для одного и того же обозначения термины IC, Staff, Tech Lead и т.п.
Классика. Бюджет ограничен, но вместо того чтобы попытаться привести в порядок код на PHP, переписываем все на два других языка, экономя аж целых 45 MB памяти)
Речь не про отладку, а про единую точку правды и скорость обнаружения ошибок. Ведь человеческий фактор никто не отменял. Но да ладно.
Что могу сказать, могу пожелать только удачи с подходами "отключать тесты в CI" и надеяться, что разработчики будут все тесты запускать локально.
Как пошутили где-то в комментариях, с такими подходами можно просто в прод всё катить, и пусть пользователи тестируют :)
Юнит-тесты это чаще всего и есть самый точный и дешевый способ сделать то, что делается при white-box тестировании.
Если юнит-тест то проходит, то нет, это вопрос к тем кто его писал, а не к самой концепции. Даже более того, за счет того что в юнит-тестах нет сети, БД и тому подобного, шанс flakebility при правильном написании даже ниже, чем у функциональных/приемочных тестов.
Ну, и гораздо полезнее, когда CI загорается красным сразу после некорректного коммита, а не спустя полдня, когда упал регресс-ран из e2e-сценариев.
Если вы отключаете хрупкие юнит-тесты в CI, а не чините их, то это опять вопрос к тем, кто работает над проектом, а не к самой концепции.
Приёмочные и функциональные тесты проверяют сквозные пользовательские сценарии (happy path + несколько граничных) и требуют обычно полного запуска системы с базой, брокером и т.п.
Если вместо использования юнит-тестов, вы будете пытаться тестировать все инварианты через перебор комбинаций входов в функциональных тестах, вам нужен будет по меньшей мере квантовый CI-сервер, потому что это будет очень-очень долго и тяжеловесно.
В нормальной разработке вместо этого юнит-тесты обычно используются чтобы быстро прогнать много граничных комбинаций за секунды и показать точный метод, где упал инвариант. Поэтому, говорить что юнит-тесты не нужны значит недооценивать само их предназначение.
Да? А у меня, наоборот, создается впечатление, что из каждого утюга стало модно кричать про то, что моки и юнит-тесты не нужны, а нужны только интеграционные тесты. Хотя, у этих инструментов в целом разное предназначение.
А то что юнит-тесты позволяют очень точно протестировать бизнес-логику и покрыть граничные случаи, которые или очень тяжело или вообще невозможно покрыть огромными интеграционными тестами - это конечно же БЕСПОЛЕЗНО :)
Каждый раз, когда читаю очередную похожую статью, возникает ощущение, что наше понимание того, что является хорошим или плохим кодом, постепенно движется куда-то не в ту сторону. Упрощение ради самого упрощения стало идеей фикс.
Безусловно, в статье есть и дельные мысли. Но не покидает чувство попытки любые правила назвать "старыми привычками" и преподносить антипаттерны как полезные рекомендации. Те же толстые контроллеры, за которые раньше били по рукам новичков, теперь вдруг стали хорошим подходом.
Вспоминается известный сценарий: в плохо организованном проекте на PHP возникает евангелист Go, переписывает всё с нуля, а затем приписывает весь прирост скорости самому языку, забывая, что главная проблема может быть в неудачной реализации.
И в этой статье примерно так же, многие аргументы звучат не как объективный анализ технологий, а больше как "не умею или не хочу разбираться с тем, что есть, поэтому затащу любимый Spring".
Не надо путать "стрельбу дробью" и обычную сквозную трассировку одной доменной идеи через предусмотренные слои. Причем, локализованную bounded context-ом.
Вот где настоящая "стрельба дробью", это где прокидывают поля из БД чуть ли не напрямую до UI "as-is". По сути, тогда мы делаем структуру таблиц БД публичным контрактом сразу для всех частей системы. И любая правка этой структуры будет размазываться дробью по проекту. Так что, по сути DDD, наоборот, лечит эту проблему.