Senior Systems Architect
  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Девелопер, не умеющий русский язык

    Ой вы меня извините пожалуйста, я тут в изгнании вдалеке от родины успел позабыть горячо любимый и родной язык (сарказм). Будь моя воля — на галерах бы только по английски разговаривали.

    И ещё одно — в этой ветке тема CI никем не поднималась, пока вы не начали говорить, что, мол, его не знают. Видимо, для вас это коньковая тема, но при чём тут мы и остальная дискуссия?

    Вот в том-то и прикол — никто не поднял эту тему :) хотя оно пипец как связанно и завязано на CI/CD процесс. Быстрый фидбек и вот это все.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    А, _вы_ называете. Ook. Ваше право, но надо было это сказать сразу.

    Нет, не я, я выучил этот термин у более умных людей.

    Очевидно, что Вы считаете, что именно Ваша «экспертиза» (ещё один бездумно заимствованный термин при наличии ранее известных и при явной конфликтности) важнее других, в том числе «коммунити».

    И это тоже были не мои слова, landing.google.com/...​ok/chapters/foreword.html

    Today, we hear a brazen culture of «just show me the code.» A culture of «ask no questions» has grown up around open source, where community rather than expertise is championed. Google is a company that dared to think about the problems from first principles, and to employ top talent with a high proportion of PhDs.
    бездумно заимствованный термин

    Вам прямая дорога в 1С, там отлично ’парусски’ программируется.

    Только вначале спросите самого себя — какая часть происходящего в отрасли соответствует именно Вашему пониманию «big picture», чем бы оно ни было?

    Ну в 2010 я и мои единомышленники отстаивали CI, в 2012 отстаивали CD, потом девопс, инфра и конфигурейшн аз код итд итп. Из года в год слышу одно и то-же — нытье. А через пару лет все все равно делают так, как я говорил, и это становится де-факто стандартном в индустрии. Пока у меня нет причин сомневаться, что то что делаю и говорю я на эдже индустрии (ну справедливости ради — я это не придумываю, а подбреваю у еще более умных людей и сразу пытаюсь применить в своей компании). Да, звездная болезнь меня уже захватила, но на форуме криптохомячков ноунеймовой страны можно и повыеживаться без вреда карме.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    И какое это имеет отношение к теме того, что тестирование кода может быть усложнено просто фактом, что он дёргает что-то внешнее, что нельзя или невыгодно мокать?

    Да как же это, я правда вам тут азбуку должен объяснять? Если вы в упор не видите разницу юнит и интеграционного тестирования, и не понимаете, что не мокая в юнит тестировании вы превращаете это в интеграционное, где присутствуют уже как минимум два компонента и баг может быть как там так и тут. Отсутствием одного из уровней вы превращаете свои тесты в шум из-за возрастающего количества ложно-негативных и возможно не только. Неужели не понятно, что если юнит тесты компонента А были успешны но интеграционные зафейлились — с большой вероятностью проблемы в компоненте Б, в противном случае упали бы юнит тесты?

    Настоятельно прошу перестать речекрякать. Тут форум профессионалов, а не конференция криптохомячков.

    То есть вы в упор отрицаете, что написание тестов влияет на стиль вашего кода?

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Ну я вот например не представляю, как можно рассуждать о CI не зная основной проблемы с которой CI призван бороться — отложенный интегрейшн поинт. Девелопер, не знающий что такое CI рассказывает мне тут за практики тестирования?

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Мне неочевидно. Потому что такой термин вообще не находится ни в известном мне наборе, ни в гуглении.

    Если вы еще девопс загуглите, будет вообще интересно, ведь там столько мнений.. Обожаю этот современный мир, где коммунити стало важнее чем экспертиза :)
    Ладно, поскольку это и правда не гуглится, удостою объяснения. Есть разница между интеграционным тестированием компонентов одного приложения (что я называю пакетными тестами), например тестирование в сборке нескольких мавен-модулей. А есть настоящее интеграционное тестирование, где тестируется весь продукт целиком, где все реальное и не замоканное.

    Эти домыслы уже не только бессмысленны, но ещё и оскорбительны.
    Это было намеренно, или как?

    Я не виноват, что вы демонстрируете полное непонимание big picture в отрасли, которую представляете. Я расцениваю оскорблением необходимость доказывать вам это.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    мок

    Спасибо, окончательно уверился в полном непонимании сути интеграционного тестирования. Дальнейший диалог считаю бесполезным.

    Текущей установленной, или просто текущей, если в репо.

    Установленной где? В энве которого еще нет? В репе где? В бренче, в мастере? Секунду назад в мастере хедом был другой коммит — итд итп.

    в клеевой слой

    Что такое пресловутый клеевой слой, о котором все тут так распинаются? Кто-то еще пишет геттеры-сетерры прокси объектов вместо какого-то ямла или еще какого DSL с кодогенератором и получают за это зарплату? Проблемы индейцев..

    Что-что отодвинуть?
    Извините, ваш речекряк не распарсен.

    Предлагаю пойти книжек почитать, на тему CI/CD, некоторые буквы после этого станут более понятными.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    А это уже проблема ваших процессов, что интеграционный тест нельзя сделать иначе, чем «собрать артефакт и задеплоить».
    Для тестов самого верхнего уровня, я согласен, оно так. Но на уровне связи двух модулей ничего такого нафиг не надо.

    Очевидно, подразумеваются пакетные тесты, которые все еще не отменяют интеграционных. Или еще хуже, традиционное ’works fine on my machine, ops problem now’?

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    А что, если компонент B 3rd party? А если компонент другой команды? А какой версии брать компонент B? А если что-то упало, как определить виноват компонент A или компонент B? Мантра юнит тестирования превращается в мантру интеграционного, при том что постоянно интеграционные тесты путаются с пакетными, и при том что нет никакого понимания что интеграционные должны проводиться в контролируемом и предсказуемом энвайрменте (коим локальная тачка дева не является — очередная мантра, что если гоним локально то это есть достаточное условие).

    Можно и без параллельности: закончил предыдущую сборку — запустил новую, если после предыдущей что-то было отправлено.
    Если фичи проверены локально, то тот небольшой набор изменений, которые привели к поломке конкретного билда, легко отлавливается (практически всегда по тестам можно уточнить до 1-2 фич).

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

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    і одних відкритих issues по routerLinkActive 18 штук

    Ну так может нет никакой проблемы? Тест валидно фейлится. Видел много раз, как люди пытались залепить индикатор пустеещего топливного бака скотчем — нет индикатора, нет проблемы же.

    я код не пишу, в мене з тестом проблема, буду копатися в коді ангуляра, так що на мене в найближчі кілька днів не розраховуйте

    И что в этом плохого? Постоянно приходится всех учить говорить «нет», хотя на западе с этим проблем нету — у нас в нации в ДНК это прописано что-ли... Опять же к примеру выше, не получается пофиксить проблему — залепим индикатор скотчем и будем молиться что топлива хватит. Вдруг пронесет ©.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Во всех этих кейсах очень многое зависит от нюансов проекта и т.д. Как вариант, развернуть разрабатываемый компонент локально, чтобы он обращался по сети к другим удалённым компонентам, которые задеплоены в отдельном стабильном энве (одном).

    И как тогда локально делать интеграционные тесты для бекенда или мид-лейера К которому обращается множество других компонентов? Разворачивать целиком всю инфраструктуру на лептопе?

    Да, согласен, на большом скейле это не сработает

    Ну вот мы собственно и пришли к тому, к чему я и вел. Толпы «профи», которые в жизни не видели более-менее серьезный проект хотя-бы ОТ 50 человек хедкаунта приходят на доу и начинают рассказывать, что юнит тесты не работают. Не осилил != не работает.
    .
    Слабо подкованный заказчик находит слабо подкованных специалистов. Все довольны, получается нечто похожее на это s00.yaplakal.com/...​riginal/3/0/2/9783203.jpg
    .
    Проблема начинается тогда, когда эти слабо подкованные специалисты начинают выходить на публику и вещать о своих «удачах» базируясь на восторженных отзывах своего слабо подкованного кастомера.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Какой-то edge case, он правда должен изменить мое отношение к тестам? Я не очень близок с ангуляром, но складывается впечатление что либо тест не правильный (не замокан сам вызов метода который чего-то там делает с роутером), либо мок роутера должен быть подправлен (нет доков — ангулярка опенсорсная, гитхаб в помощь).

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Открытие PR играет в этом какую-то сакральную роль? Pipeline сборщиков запускается по коммиту, например — где PR в этом случае находится? Если процесс подразумевает открытие PR сразу — ОК, но это не является каким-то железобетонным ограничителем совсем.

    Открытие ПР служит сигналом, что код в фича-бренче готов для дальнейших степов (CI и ревью). Я видел сетапы, где бранчу собирали и без ПР, по пушу, но реально представь это на скейле сотни параллельно активных бренчей с допустим ~20 пушами в час — это сколько энвов нужно параллельно иметь и откуда у вас столько денег?

    Если его возможно выполнить локально, это вообще хорошо, т.к. в большинстве случаев проблема уже будет локализована. Желательно, чтобы так и получалось. Если локально никак, возможен, к примеру, такой вариант.

    Интеграционный тест локально? Что и с чем вы интегрируете в таком случае? Вы потом ваш лептоп в стойку в дц запихнете? Заранить конечно можно, только он говорит 0 информации, поскольку легко содержит и ложно-позитив и ложно-негатив.

    Если позволяют условия, PR должен открываться, а мердж производиться после максимально возможного контроля со стороны разработчика, чтобы не засорять процесс лишним шумом.

    Ну это разумеется так, но это не отменяет всех этих степов в CI. Мы же не отменяем валидацию ввода на бекенде потому что мы сделали ее на фронтенде, do we?

    Насчёт «10 пулл реквестов в час» я писал, что в этом случае да, возможно согласен, но в иных случаях (а их будет много) можно поступить гибче — это позволит отловить баги раньше. Поэтому, повторюсь

    Повторюсь, что раньше выловить баги позволяют юнит-тесты, а вы предлагаете нарушить CI/CD и деплоить динамик-энвы (то, что вы называете 0-энвами), что вообще никак не работает на скейле (ну разве-что у вас неограниченный поток финансов откуда-то). Мы же не базируем наши предположения на опыте гаражных пет-проектов на пять человек? А то так недолго дойти и до того «а зачем CI, а зачем git, а зачем jira» — че уж там юнит тестами ограничиваться.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Вы утверждаете, что вы будете разрабатывать с той же скоростью с тестами, что и без тестов?

    Представь стандартный рефакторинг, например ты хочешь изменить сигнатуру метода. Что ты делаешь? Идешь в IDE, кликаешь правой мышкой по методу и выбираешь ринейм — и умная IDE находит все вызовы этого метода и делает переименование там тоже. Сколько у тебя заняло бы времени на такую простую операцию без умной IDE?
    Так вот IDE умеет понимать только синтаксис, она не понимает логику. При рефакторинге, который затрагивает поведенческое изменение, при наличии юнит тестов, ты запустил их после рефакторинга и в течении минуты знаешь результат. Без тестов, затраченное время будет прямо пропорционально размеру кодовой базы, и после некоторого психологического барьера будет в принципе послано нахер ибо «и так сойдет». Все эти эпизоды суммируются в течении времени и за год-два получаем кодовую базу, которую никто не хочет брать на саппорт и толковые инженеры пачками бегут с проекта и все сложнее найти новых ибо сарафанное радио работает хорошо. Казалось бы, какое отношение юнит тесты имеют к джоб сатисфашну и аттришн рейту на проекте, huh?

    Поддержал: Dmitry Derevyagin
  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    так взагалі прикол — іноді ніфіга не очевидно як написати тест на працюючий код

    Действительно прикол, ведь юнит тест это автоматизированная запись того, что должно было происходить в голове при написании кода, что я называю «компиляцией в голове» и симуляцией исполнения. Если не понятно, как написать тест, то не понятно как развернуть этот метод/цикл и скомпилить и симулировать это все в голове, значит этого никогда не делалось, значит код написан по принципу «а что если я сюда воткну это и обновлю страничку? о, работает!», а значит код воняет, тяжело читабелен и не гибок.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Нижние.. ну ок.

    У нас, например, PR не открывается, пока локальный + самый нижний удалённый уровень не прошли успешно.

    Это как? Что есть «нижний энв» (дев энв по нормальному) и что в него деплоется если разработчик еще даже не открыл PR? Он деплоит прямо из IDE? Ведущие параллельную разработку разработчики имеют персональные дев энвы о которых никто не знает? Ребята, это самопал какой-то. Еще раз, есть уже заезженная пирамида тестирования, есть придуманные бранчинг стратегии такие как гит флоу и гитхаб флоу, есть CI/CD и build once run everywhere. Не нужно ничего придумывать. Все уже придумано за вас. Пуш в фича бренч -> ПР -> линтинг -> юнит тесты -> пакетные тесты -> код ревью -> мердж -> сборка и паблиш пакета -> деплойменты в энвы -> интеграционное, функциональное, лоад, e2e и прочее тестирование -> промоут на следующий энв (количество энвов меняется по вкусу, допустимы мелкие аджастменты). Кто не знает этого простого базового сиквенса — тот не понятно за что получает свой хлеб и не проходят TI у меня.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    На мою думку, график коррелирует с мнениями профессионалов в айти с которыми я общался за последние пару лет. Не могу сказать за все продукты компании, и уж точно это вряд-ли касается хардварных решений, но ряд энтерпрайзных софтверных продуктов, таких как WebSphere — да. В эру, когда деплойменты автоматизируются по максимуму, этот продукт просто не работал. На вскидку я не могу вспомнить ни одного человека из моего настоящего или бывшего окружения, кто-бы не скривился при слове IBM. Профессионалы из моего нетворка просто более не выбирают продукты IBM, и это важно в эре когда дремучий менеджмент (который покупал продукты которые он не понимал как использовать) вымирает как класс. Я конечно понимаю, что моя выборка нерепрезентативна, но она формирует мое мнение и мнение моего нетворка, и для меня этого достаточно. Я знаю, что в компании в которой я работаю или буду работать — любой сейлз из IBM зафейлится и не пройдет.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Я не знаю, что такое нижние уровни деплоймента. PR открывается из фича-бренчи в бейзлайн (мастер или что-то еще в зависимости от выбранной стратегии бранчевания). Это самое начало CD цикла, кроме локальной машины девелопера этот код еще никто и ничто не видело. Тестам на локальной машине дева доверять нельзя, по ряду причин.

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    Как торгуется IBM на nasdaq за последние пять лет

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

  • Рабочий продукт — прежде всего, или Когда не стоит увлекаться кодом и тестами

    очень просто вылавливаются на простейшем интеграционном тесте

    Слишком поздно — интеграционный тест означает что уже был собран артефакт и куда-то задеплоен (собрали машину и вывели на трассу). Если это гаражный проект, может быть и пофигу, а если у тебя по 10 пулл реквестов в репо в час — что будешь делать?

← Сtrl 123456...39 Ctrl →