Наконец-то кто-то написал по этой теме действительно дельные вещи, а не шаблонные вбросы про какую-то великую добавленную сложность или про то, что целый 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, наоборот, лечит эту проблему.
Сложно аргументированно комментировать, не зная, что именно вы делали. Возможно, вы не до конца разобрались с деплоем в K8s и делали все как-будто у вас по старинке физические машины с фиксированными IP. С тем же Akka Cluster, помню, были свои нюансы с необходимостью использовать StatefulSets и Headless Service.
Так вы код СУБД писали и запускали в докере? Ну, тоже ничего страшного. Если у СУБД корректно вынесено состояние и есть механизм восстановления, то все должно быть нормально.
Наконец-то кто-то написал по этой теме действительно дельные вещи, а не шаблонные вбросы про какую-то великую добавленную сложность или про то, что целый 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, наоборот, лечит эту проблему.
Сложно аргументированно комментировать, не зная, что именно вы делали. Возможно, вы не до конца разобрались с деплоем в K8s и делали все как-будто у вас по старинке физические машины с фиксированными IP. С тем же Akka Cluster, помню, были свои нюансы с необходимостью использовать StatefulSets и Headless Service.
Так вы код СУБД писали и запускали в докере? Ну, тоже ничего страшного. Если у СУБД корректно вынесено состояние и есть механизм восстановления, то все должно быть нормально.