Да можно было и не начинать с такой глупости: путать и смешивать распределение ответственности (1 команда -> 1 сервис -> 1 ответственность за разработку и релиз ) с разделением предметной области\контекста ( 1 фича — 1-> один близкий контекст (домен) -> 1 один микро сервис). Или если в принципе команд физически 1 или 2, то что им после написания 2ого микро сервиса сказать: нанимайте ещё людей, а мы будем эти 2 поддерживать? нет конечно. Они будут продолжать их писать. И фичи делать и поддерживать.
Да и все эти авторы книг по DDD и микро сервисам они, конечно же дураки.
Заканчивать действительно стоит, раз на подробный комментарий человек безапелляционно говорит просто глупость в духе «ой всё». Вероятнее всего вы или не писали сами микро сервисы (судя по выступлениям вы обычный менеджер который делал раньше девопс, а не разработчик) или писал неправильно, но потом героически решал проблемы вызванные своим недопониманием проблемы связанности и разделения (распределённые транзакции, там где они не нужны, гонки в распределённых сервисах, многоуровневые подзапросы и т.д.)
PS и ваши моментальные и безответные минусы — как детский сад: радуют и забавляют. Когда нечего ответить, а признавать что не прав стыдно, то лучше поправить пенсне и притвориться важным
В итоге предложили решение какое? Сделать новый монолит. Ок 10 гигантских монолитов, вместо 30-300 маленьких сервисов. Ещё «лучше»!
А всего лишь надо было иначе проектировать: 1 микросервис = 1 фича, т.е. один контекст. Не функционально близкие вызовы, а фича! Глобальный контекст это продукты или ордера в которые входят несколько микросервисов про ордера, например (импорт, отображение, проводка). Они не должны быть между собой связаны функционально, только логически, на схемках. А у вас это было функционально связано, не просто кодом, а вызовами сервисов. Конечно комок грязи получится.
У вас не должно быть микро сервиса product, order, catalog которые лепят CRUD операции плюс что-то делают. Это типичная ошибка новичка, которую 100 раз описали в книгах и обсудили. Но т.к. это про проектирование предметной области, а мало кто умеет это делать, то все просто пропускают мимо ушей и бегут деплоить докером новый orderService. У вас может быть микросервис «отобразить ордера для грида с общими данными, фильтрами и агрегацией», «провести новый заказ», «отменить заказ», «импортировать продукты», «отобразит продукты». Это физически разные сервисы. Тогда у вас не будет комка грязи с кучей вызовов. Вызовов вообще быть не должно практически. Максимум 1 уровень после Api Gateway + первого сервиса (того 2 уровня).
А главное, после такого объединения в 10 монолитов мы:
1. Получаем высокий уровень связанности, продолжая расширять его (нам же нужны новые фичи), вместо того чтобы не трогать то, что и так работает и делать новые фичи в новых микро сервисах. А связанность — главная проблема монолита. Она и влияет на сложность поддержки и увеличение вероятности ошибок и приводит к краху бизнеса, когда никто легаси г. не хочет расширять и даже переписывать. И это уже следующая глобальная беда, от которой страдает бизнес. Это вообще главная проблема — высокая стоимость поддержки и цена ошибки. Бинго, мы вернули её.
2. Мы не можем больше переписать микросервис за разумное время (12 человек за 1 неделю), не может быстро найти проблему и пофиксить её, не сломав другие куски, мы должны все перетестировать, вместо 1 куска.
3. ХЗ что делать с историей кода, т.к. 1 микросервис = 1 репозиторий. У нас не так, у нас общий репозиторий? поздравляю, мы мазохисты, но пока не знаем об этом.
4. Про порядок деплоя вообще смешно слушать было. Вы серьёзно? может у вас ещё микро сервисы один за другим вызываются и ждут действий в определённом порядке, а не только как справочники? Ок, молодцы. Вы сделали свою SOA шину. Это г. не работало ещё в 2005ом.
Слово микро — ключевое, а не лишнее. А то, что кто-то не умеет управлять большим количеством сервисов — так это его личная проблема, а не проблема архитектуры.
Вот что бывает, когда люди, не имея практики и не зная современных подходов по проектированию процессов предметной области, а умея только перекладывать данные из табличек базы в UI, не зная как применять DDD и формировать правильные контексты берутся за следующий уровень — делить код на инфраструктурном уровне. А потом виноваты все — микросервис, архитекторы, зоопарки.
Зато освоили кучу новых слов и возможно даже технологий, кубренетисы, докеры, OSGI.
Нет, неправильно. Если вам нужен агрегатор который одновременно работает с 1000 комментами, авторами и списками его книг, а также описанием (я так понимаю вы про подняли всю базу в память), то значит вы смешали контексты предметной области, а значит сама архитектура неверно построена. И сами сущности, инкапсуляция и архитектура слоёв и микро сервисов. DDD это не про «прочитал статью, узнал новую фишку а ля проверяй параметры в конструкторе» и начал использовать. Это целостная концепция, где одно подкрепляет другое.
Более того, есть Lazy Loading который поднимет вам ваши 1000 комментов только если по ним нужно пройтись (если уж так получилось).
ПРичем всё это нужно именно для изменения модели предметной области. Для чтения можно использовать CQRS подход.
А вообще это сферический конь в вакууме. Нужен конкретный пример и на нём я смогут отмести 100500 «а если» и сформировать правильную модель. Иногда даже такую, которую даже сам не ожидал бы увидеть в начале. Просто нужно перестать думать данными и таблицами БД, а начать думать процессами (предметной области, бизнес-сценариями).
Нарушение DRY — это не дублирование кода, это дублирование информации.
Тем ни менее это тоже не совсем верно. Я бы сказал нельзя дублировать контексты, но не их части. Где контекст предметной области — это определённая фича с её нюансами и правилами, а части — это конкретные данные и доступ к ним, реализация правил и ограничений, алгоритмы. Вот конкретные данные и алгоритмы можно и нужно дублировать. А контексты — нет. Информации, данных, нужно ровно столько, сколько её нужно в рамках предметной области, контекста или суб-контекста. Если нужно одни и те же данные в двух сервисах дублировать, значит нужно дублировать, а не шарить код. Если можно не дублировать (например, очевидна перспектива вынесения общего сервиса), то нужно не дублировать. Но в жизни не очень грамотными разработчиками принята за аксиому и священную корову норма, что дублировать «низя и точка». От сюда на практике случаев общих библиотек предметной области или DAL в разы больше, чем случаев проблем из-за дублированной инфы.
Итого, весь принцип DRY является высосанным из пальца неуклюжим определением, попыткой реально сложную неочевидную вещь объяснить на пальцах, сделав только хуже. Ни чета определением из той же физики. Одно дело объяснить папусу, почему земля круглая, а другое дело заставить его после этого строить ракету или пойти в кругосветку, обладая только знанием, что земля круглая. Просто автор DRY, Д. Миллер, сам не очень хорошо понимает то, о чём пишет. А после этого ещё хуже интерпретируют читатели. А сводилось всё к тому, что должен быть 1 файл конфигурации в 1 месте для одной системы.
Не создавать то, в пользе чего не уверен, гораздо более оптимальная стратегия, чем сперва создать а потом удалять на рефакторинге.
Видимо мы про какие-то разные ситуации говорим. Вы, стало быть, про «создание впрок» или нечто подобное. Но т.к. рефакторинг происходит постоянно, то сложно даже прочертить границу когда нужно создавать. Сейчас или через час. Понятное дело, что создавать сущности которые через неделю наверное понадобится — это бред. Но опять же программирование, как живопись или скульптура, процесс постоянных изменений, добавления объёма и формирование формы. А потому рефакторинг — это часть написания кода и добавить во время разработки сколько надо сущностей, половину потом удалить потому что предметная область обрела новые детали и вырисовалась новая форма — это и есть единственно правильный и оптимальный подход.Это то, о чём я говорю. В противовес ему я знаю только 1 вариант: всё запланировать и расписать заранее(водопад), вплоть до классов и методов, но потом с этим г. невозможно просто работать и от этого все нормальные компании давно отказались. Вариант же «добавлять по мере необходимости» и есть часть моёго подхода. Просто необходимость меняется с прорисовкой детали и там где у тебя был 1 класс (сущность), может появиться 3, но потом из-за тех. деталей, выявлений общего поведения чего-то ещё, може остаться в итоге 2 класс. ну и т.д. Это просто нюансы.
который каждую маломальскую сущнусь стремился усложнить по максимому.
Сложно угадать что вы имели введу, но возможно то, что математик пытался бежать впереди поровоза в духе «я знаю что это потом понадобиться». Не, это неправильно, это зло.
Но, если у нас предметная область различается хоть на 1 поле, тогда:
Сущность user уже с первых строк кода могла быть реализовнана как целая домення область из user-core, user-address, credentials, user audit, connected apps, payment data
Это правильно. Хороший контекст и домен превыше всего. Вообще всего. Потому что это залог:
1. минимизации ошибок в реализации
2. минимизации скрытых ошибок и сайд-эффектов
3. возможности передать код след. разработчику, и позволить ему разобраться в нём так, что тот выполнит п.1. и 2.
Можно жить с низкой производительностью — её можно улучшить. Можно жить с техническими багами реализации или недоделками (ну типа нет 100500 валидации на такое-то условие) — их можно исправить. Нельзя существовать с продуктом, которые делает не то, что нужно, да ещё и скрыто. И при этом не позволяет себя исправить ( например исправление только за счёт костылей, что вносит сумятицу и сайд-эффекты. разраб уволился, с ним и знание «а почему так», а код и контекст не говорят почему)
Но конечно, заготовки делать на случай просматривающегося контекста — это тоже зло. Разработка и развитие предметной области сродне лепки из пластилина или глины (обратное резьбе по камню): меся обрастает, потом переосмысление, рефакторинг всего. Если есть опыт, то рефакторинг проходит легко. Если говнокодили в начале, то с болью. Но нужно развивать доменную область, которая отображает фактическую модель систему — а не:
а) изначально запланированную, но которая оказалось избыточной\недоделанной
б) изначально незапланированную, но вылепленную без «развития», а потому таскающую за собой кучу легаси свойств и зависимостей из других контекстов, которые поленились создать\не поняли что надо создать.
почемуто раз в 5 больше ненужных усложнений в виде сущностей.
Слава Богу его можно было убедить словами и рефакторинг он не воспринимал болезненно.
Ну это и есть то самое развитие. Насоздавал. Понял что 5 из 8 сущностей лишние или дубли — удалил. Это норма.
Если рефакторинг перед началом каждой новой задачи, во время изменения куска кода или фикса бага то и нет проблем с поступательным развитием. А если рефакторинг — это плановая задача «вернуть тех. долг», то всё, считай нет и не будет его никогда.
Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом.
Вот это лютый бред и трешак, который привёл к монолитизации и колоссальному увеличению связанности и мешает людям подняться на ступень выше в написании качественного кода. С ним возятся до сих пор, хотя больше плохого, чем хорошего. Ну при условии что вы не мамкин сайт домашний пишите, а приложение миллионов на 5-7 строк кода. Он актуален исключительно в среде теоретиков и джунов, чтобы последние не копипастили один и тот же код в разных классах.
На практике, люди, упоротые этим принципом и не знающие других подходов с огромной болью живут в огромном монолитие с единой dll типа DAL единой dll типа DomainModel и т.д.
Всё это таскается из одного проекта в другой, шарится между десятками сервисов и апи и потом распилить такое на микро сервисы просто невозможно, точнее бизнес не хочет. Цена поддержки растёт кратно. Зато без копирования, ага.
Как нужно делать:
1. Не копировать код в рамках 1 класса и одной, при возможности одной dll.
2. Делать всё в рамках одной фичи. А ля микросервис. Это означает что нет никаких папок с кучей разных репозиотриев а ля Reposotories/AccountRepository и тут же Reposotories/OrdersRepository. А есть 2 фичи (Accounts/ Orders/) внутри которых есть такие репо (Accounts/AccountRepo, Accounts/AccountFactory, Orders/OrderRepo...). В будущем это позволит разделить контексты И если вдруг фиче про ордера нужен доступ к данным из аккаунта, то да, копипастится логика хоть полностью и делается свой репо (Orders/AcountForOrdersRepo… ). Менять её придётся разве что раз в 1000 лет. А вот поддерживать и менять в рамках одной фичи — сколько угодно раз. И нафига тогда нужен такая связанность с Account фичей? Нет уж.
3. По мере разрастания кода — разносить вообще в разные библиотеки (контексты) и репозитории.
А DRY на помойку.
Прежде чем переходить к реализации, убедитесь, что все хорошо продумано.
Это тоже теоретическая чушь, которая на практике сводится к:
1) мы уже делали такое и знаем что примерно нужно сделать ещё раз. Тогда проблемы нет.
2) мы ещё не делали такое и хз что нас ждёт. В этом случае ничего не поможет, ничего не угадать. Например мы на своём проекте несколько лет использовали singlar для для работы множества клиентов с сервером и сервер с очередью через RebbitMQ. В итоге отказались от подхода, как нестабильного, перешли на realtime запрос-ответ. Угадать заранее, фактически без прототипа в продакшене такое было невозможно.
Что же на самом деле лучше сделать в таком случае?
а) Изучить максимум инфы по данной технологии.
б) делать простые небольшие изолированные куски. Потом с увеличением их числа вовремя рефакторить и объединять в контексты. Постоянный рефакторинг — только он поможет избежать факапа. А рефакторинг подразумевает поднятие на уровень выше в архитектуре и её пересмотр в том числе. Когда время пришло.
SOLID
Вот это must have и за его нарушение (чаще всего S) увольнять к чертям. Оно хоть как-то спасает от связанности и роста проблем.
Не создавайте ненужных сущностей без необходимости.
Очередной теоретический бред для джунов, наверное. Сущности всегда создаются в зависимости от контекста и бизнеса. Если у тебя 5 вариантов работы с ордерами и в одном случае нужны одни поля, а в другом — другие и только id + name общие, то это разные сущности. И их нужно создавать. А не гонять одну God object по всему домену. Увеличивая связанность. Если тебе нужно вернуть объект в виде json то не нужно возвращать сущность из предметной области. Пусть она хоть 1 в 1 пока совпадает с DTO объектом. Ключевое слово тут «пока» совпадает.
Фаулер и Макконели верно говорят, что самое дорогое — поддержка. А поддержка дорожает с увеличением сложности. А сложность в том числе берётся и от связанность, из-за невозможности просто удалить и заново переписать кусок. А вдруг кому-то что-то сломает?!
Солид противоречит ягни, драй и кису. То есть конечно, иногда они успешно сосуществуют в некоторых местах. Но есть достаточно слуачев когда надо выбирать. И я агитирую за выбор солида.
А ещё LoadAsync().GetAwaiter().GetResult() и LoadAsync().Result вызывают дедлоки и категорически запрещены к использованию, являются жутким говнокодом. Но их используют по старой привычке и потому что ни разу не «прилетело».
Правильно вызывать асинхронный код исключительно через новый поток как написано выше:
var value = Task.Run(async () => await GetValueAsync()).Result;
потому что в зависимости от контекста вызова там куча вариантов (кажется 6), когда поток попадёт 100% в дедлок, когда не 100% и когда не попадёт. Разница для одного и того же кода будет даже если вы вызывали его как часть библиотеки, через IIS или как часть сервиса.
Изложу своё мнение, основанное на личном опыте комплексного внедрении автоматического тестирования и end-to-end тестов в CI\CD для очень крупного веб. приложения.
Когда речь идёт о UI (end-to-end) или API (функциональные) тестах, то всё кроме селениума и подобных библиотек — ненужная лажа для автоматизации тестирования, которую пытаются впарить клиентам за баснословные деньги. Пришлось прочувствовать это на своём опыте, когда CTO назначил использовать пару подобных платных штук (хиптест и что-то ещё, уже не помню название), вместо nunit\xunit и ЯП. Через год мучений просто отказались и забыли как страшный сон. Ускорение выполнения только после переделки под nunit выросла в 3 раза.
Вся автоматизация должна делаться исключительно на языке программирования, дабы минимизировать стоимость поддержки, скорость запуска и разработки, а также покрывать условия:
1. На каждый тест легко создаётся свой набор данных и легко удаляется. Система должна оставаться чистой
Например в базе данных перед и после должно удаляться всё что, касается ордеров, если мы тестируем фильтры или создание\отображение ордеров. И потом создаваться нужные наборы и комбинации, а не из кучи мусора выбирать нужный нам.
2. Должен быть максимально гибкий и удобный инструмент по созданию тестовых данных.
Очевидно что это код на ЯП, а не галиматья в виде скриптов от третьесортных систем, кукумберов и прочей визуальной фигни. И не да бог с кодогенерацией.
Никакие апи или там SQL скрипты также не подходят для создания тестовых данных.
а) Апи (речь про открытые интерфейсы, не про библиотеки) или веб-апи не подходит потому, что ваша система может тупо не иметь апи для создания половины сущностей. Например вы тестируете грид и фильтры (достаточно просто насоздавать разных ордеров), а ордера импортируются кучей разных сервисов из разных маркетплейсов. Т.к. тест должен иметь ограниченный контекст и не занимать пол дня, то разумно отображение тестировать отдельно, а импорт сервисов — отдельно, т.к. это другая система из другого сценария. Конечно же может быть и сценарий по импорту ордеров из маркетплейса. Но его набор данных не должен быть связан с тестами фильтра на гриде.
б) Чистые SQL скрипты создания данных не подходят потому что поддержка их будет заниматься больше времени, чем создание теста, а всё на стороне БД будет изменяться очень-очень часто. Вовремя отказались от такого, казалось бы, разумного подхода. Плюс скрипты в духе вставить в одну-две таблицы — это детский сад. В крупных системах такого не будет, а будет куча хранимок, иногда с несколькими версиями в которых сложно разобраться
Выход на самом деле простой — использовать DAL библиотеку, которую поддерживают разработчики для создания тестовых данных. Тогда вы изолируетесь от всего головняка с поддержкой своего самописного дала и от сложности создания многих сущностей в бд.
Ещё лучше, если у вас нормальные разработчики, использующие DDD там будет всё намного проще. Просто берёте фабрики с репозиториями и генерируете данные, которые вам нужны для UI\API
В автоматизации решает стоимость её поддержки. Автоматизация загибается, когда сложность поддержки увеличивается. При этом нужна достаточная гибкость при создании данных, а также скорость выполнения тестов. 200-300 end-to-end тестов выполняются 3-4 часа на UI. Против 20-30 минут для функциональных (АПИ), против нескольких минут для интеграционных (dal, связки систем), против нескольких секунд для unit (методы)
Скорость и покрытие напрямую зависят от способа создания данных. Если вам нужно протестировать 10 фильтров на гриде с кучей комбинацией, то что проще: каждый раз вызвать апи, создавая сущности или одним махом залить все нужные комбинации в базу, очищая все лишние сущности от прошлых тестов?
Вывод — ознакомьтесь с очередной подборкой «топ-5 самых лучших инструментов в year_number» и отложите их на полку, если они не могут быть использованы в коде.
О! Как раз за ними пределываю. Херак-херак и в продакшен. Сперва просматриваются зачатки архитектуры, но потом всё равно всё стало god-оbjects. Наверное, как обычно продали дужна как синьора, которые по титулу компании мидл-стронг подающий надежды. Или недооценили сроки. Неприятное ощущение, стыдно за наших. Перед клиентом защищаю, мол пацаны много сделали, но сам-то вижу что это уровень идусов и лучше сделать меньше.
А ещё integration testing это не фейки и песочницы, это реальные стыки систем. Это, например, тестирование DAL уровня запросв (методов Repository) с реальной базой. тестррование методов repository по обращению к сервису с реальным сервисом по http. Но никак не с фейкам. Нет песочницы и тестового аккаунта к реальной системе? Значит для этого куска нельзя реализовать интеграционные тесты. Обходитесь юнитами. И уже тем более интеграционное тестирование не «просто уровнем выше будем тестировать: наделали кучу зависимостей разных подсистем и один монстро-тест запустили, который и в базу лезет и в сервис шлёт и в очередь». Это самая распространённая ошибка, которая становится причиной: «ой… чё-то тесты опять упали», а потом «ну да, есть тесты, но поддерживать их тяжко, потому не запускали давно»
Но однажды один QA-инженер из нашей команды узнал её данные. Имея благие намерения, он решил реализовать автотесты.
Для автотестов делается свой сервис со стабами, фейк у вас в статье. В который скармливается «ожидаемый ответ на ожидаемый запрос» а ля Setup из библиотеки Moq только по HTTP
И погнали тесты делать любые. QA должен был знать такие базовые вещи, прежде чем использовать карту. Но это ещё большой вопрос, надо ли это делать, когда достаточно один раз от реальной системы получить ответы, понять логику и всё заменить моками.
Последствия использования песочниц внизу пирамиды — появление различных инфраструктурных проблем:
Ещё бы. Когда на уровень юнит-тестов бизнес логики лезем е2е тестами, да ещё и с нестабильным инструментарием. Разделять, это нужно разделять. Бизнес логика тестируется только юнитами и только моками, никаких песочниц от эппл. Песочница это е2е тесты и частично интеграционные.
формат нотификаций, а тест при этом давал ложноположительные результаты
нужно трекать такие изменения. документацию или запросами к реальному серверу раз в день, например. Как минимум версию сервиса трекать и\или xsd схему.
ЗЫ
О боже, опять это дурное слово из рунглиша — «нужны знания и экспертиза». Пришлите адрес, вышлю ссылку на словарь Ожегова.
Экспертиза в русском языке это документ, заключение по результатам исследований: «проводить экспертизу».
В том значении, в котором автор пытается применять слово переводя с английского, есть добротное выражение: «знание и опыт» или «специальные знания». Но никак не «знания и экспертиза».
Нужные знания и опыт. Или нужные опыт и специальные знания.
Только американские домохозяйки-присяжные купятся на бред типа «очень крутой хаккер, глава империи… пользовался IP адресом из России, чтобы сливать туда данные», «оплачивал цветы жене и билеты с аккаунтов, под которыми торговал картами», «не пользовался шифрованием, зато использовал простые пароли и одинаковые ники в течение 20 лет», «зарегился на яху,» чтобы его было проще читать? и прочая хрень. Читать смешно, но пендосы верят, как верят в то, что им все должны и обязаны (выдавать, например), а они никому и ничего. Святая простота.
потому всё это расследование бред чистой воды. Весь смысл был взять в 2014 году за жопу какого-нибудь сына российского чиновника или депутата и давить на Россию. Ну и т.к. это всё чепуха, то её можно было и на конференции рассказать. Чтобы другие хакеры узнали «оперативные методы» и лучше прятались, наверное? Всё.
Хотя и я и согласен с мыслью в целом, но про оупенсорс — это какая-то чушь. Вы или не имеете жены и детей, либо на работе не заняты особо, либо забили на семью (но конечно же этого никогда не признаете). Видали мы таких. У человека 8 часов из которых эффективных 4-6 на разработку и ещё пару часов на общение и митинги. Всё. Остальное время мозг должен отдыхать. А на выходных есть домашние дела. Жена хочет внимания, дети с отцом поиграть, чтобы не вырасти мудаками и не сказали через 10 лет: «Слышь, дай прикурить, типа батя… хэ-хэ». Только полные задроты сидят бесплатно после работы в оупенсорсах и это медицинский факт. Нормальные специалисты получают достаточно бабла в энтерпрайзе и в ус не дуют. И уж точно ни я ни кто-то из моих бывших или текущих коллег или подчинённых не будем тратить свои вечера, чтобы удовлетворить какую-то там айчарку или четырёхглазого техлилда ссылкой на гитхаб «как я закоммитил в оупенсорс». Не тот возраст. Студенчество с беззаботной и ветряной жизнью кончилось у синьоров 10-15 лет назад. Хочешь узнать как я пишу код? Давай свою задачу сюда. Не достаточно? Нанимай меня, плати бабло и смотри всё что тебе нужно. Нет денег? Ищи студентов которые на гитхаб коммитят.
Слово «бэкграунд» — не совсем одно и то же, что русское слово «опыт»
Ничего иного в русском языке оно не имеет, кроме значения «опыт». Ваши фантазии на тему слов и понятий ничего не значат для других людей, это лишь ваши заблуждения. Карта — не территория.
Просто не хотят люди, привыкшие к англицизмам, принять тот факт, что в русском языке достаточно слов, чтобы выразить любую мысль.
Отказываюсь верить что кто-то действительно так говорит.
В английском у этого сочетания совсем другое значение, с IT никак не связанное
Тем хуже. Потому что это переводится как навыки общения в коллективе — более точное и ёмкое название, чем сленговое выражение soft skills.
Во-первых, как бы вы это слово перевели? Ситуация? Задача?
Как бы перевели сочетание «use case»?
Во-вторых, слово «кейс» в значении «чемодан», пришедшее к нам из того же английского, вас почему-то не смущает…
Вижу, русский язык — не ваш конёк.
use case — это ничто иное как один из следующих вариантов( как богат русский язык, правда?): способ\ вариант\ пример использования или ещё лучше и точнее — прецедент.
Совершенно нормальное устоявшееся сочетание в айтишной среде.
Давай все словам заменим в русском языке тогда? Почему говорим клавиатура, а не кейборд? Отправьте мне на почту, а не на mail? Как «большие объемы данных» это переводится.
5. Вы использовали скрам, канбан, лин?
У этих слов есть русские аналоги?
Эти методологии имеют общее название «точно в срок». Найти подходящий перевод или аналог — задача переводчиков. Переводить это вообще нормально, если это не новое слово, как например «автомобиль» для начала 20 века. Иногда это могут быть уже имена собственные и нужно оставлять как есть, а иногда просто нужен переводчик.
6. Чекните кусочек кода и сделайте пропоузал по его улучшению
На мой взгляд — высосано из пальца, никогда с таким не сталкивался.
Вы не чекините не заливаете (сленг) код? Тогда у меня плохие новости…
Правильный перевод был бы «сдать\отдать (типа как под расписку) код».
Ага, ваш вариант «планёрка» — звучит куда лучше чем слово «митинг»…
Вообще-то митинг — это обычное совещание. Да, планёрка звучит куда лучше, потому что русское слово, произошедшее от слова план (латинское planus- ровный) и сто лет в обед обрусевшее.
но в данном случае выбор очевиден — совещание.
«Фидбэк» — ОК, вполне нормальное слово на мой взгляд.
Чем?! Чем оно нормальное? Фидбек это «обратная связь», «отзыв»!
Вам в университете фитбек профессор на дипломную работу давал или отзыв писал?
В таких условиях бороться со сленгом разработчиков совершеннo бесполезно и даже глупо.
Нужно просто лапки к верху поднять и принимать всё как есть. Пусть нас пожирает иностранная культура, а мы, вместо перевода слова на русский, будем заимствовать лексикон из языка другой культуры, причем (это важно!) в тех местах, где совершенно нет в этом необходимости.
Если же не хотят просвещаться – отстаю, пусть сидят круглосуточно в Excel и прочих продуктах Майкрософта.
и потом
Каким todo-менеджером пользуетесь лично вы?
MS Outlook.
Каким таск-менеджером / issue-tracker’ом / репозиторием пользуетесь в компании?
MS Outlook.
Какие еще инструменты и ПО используете в работе?
Системы документооборота, ERP, BI, кадровые системы, семейство Майкрософта.
Ничего не имею против, т.к. сам пишу под .net но нужно как-то поскромнее сперва ёрничать над другими, когда сам пользуешься продуктами той же компании.
В 2003 году окончил Московский государственный университет
С 2001 года работал в ЗАО «Фронстеп», где прошел путь от стажера до заместителя генерального директора по консалтингу. С 2008 года
Иначе говоря только закончил универ и уже через 5 лет гендир. «23 трехлетний СЕО» — это повод для стыда, а не для гордости. Иностранцы смеются над нашими синьорами с 5-7 годами опыта. Это они про СЕО ещё не знают.
Сразу вспомнил про один психологический эффект: когда чиновник достигает своего максимального уровня и больше не может эффективно работать на вверено ему должности, то дабы он не вредил «в поле», его повышают или придумывают должность под него. но такую, чтобы не мешал и мог надувать щёки. Не такой ли наш герой?
Видимо не справился с обязанностями CEO, потому пришлось уйти в
С 2008 года по 2012 год занимал должность директора по ИТ в АО «Автодизель»
Т.е. руководил админами, картриджи меняли, сетку тянули, 1с ставили. Ясно, понятно.
судя по копеечным вакансиям «PHP — $500.» Java — $1400
и совсем не софтварному профилю ( какая газо-химическая контора) к информационным технологиями данный герой-управленец имеет крайне косвенное отношение. Я бы назвал продвинутый пользователь всяких там Sharepoint и прочего… вна. Который, в виду размеров компании, даже имеет свой отдел разработки из 10-15 человек. Но заявляет, что чуть ли ни ИТ-бизнес решения предлагают.
Короче, лесом. История любого разработчика, который сидит на удалёнке на 5-7кило или участвовал в провальном проекте будет гораздо интереснее, чем «яйца на завтрак».
1. Как происходит возврат средств? Например, в случае возврата товара.
2. Можно ли через psp например не списать деньги, а заморозить на 30 дней, до получения товара покупателем? шлюз также как напрямую через эквайр
3. Кто в данной схеме может выступать арбитром сделки, если нужна такая сделка (деньги замораживаются и ждут подтверждения)? шлюз или банк?
Забей спорить с детьми. Им вон по 24-25 лет, 90ый, 91 год рождения. Они ещё даже джунеорами не перестали быть не только по уровню знаний, но и по опыту жизненному, а уже учат других. Но 23-ие синьоры уже проступают. Такие никогда не признают, что столкнулись с подобными проблемами кодинга после 40, не имя ни семьи ни детей. 3 часа в день на самообразование… Это только если ты один с мамкой живёшь и в ответ на пойти попить пиво друзьям говоришь: «Не, парни, я сегодня пасс. Чего-то хочется выучить новый язык». Когда нет ни сына\дочери с которым нужно заниматься, а который без отца (с отцом лунатиком 12 часов за компом сидит) растёт, когда нет жены, которая внимания хочет. Детки на хабре, потому ресурс стал гoвнoм уже давно. Новое поколение барадтых самовлюблённых кодеров, которые реально считают, что детские фриланс-поделки на гитхабе — это показатель их опыта\навыков\любойдругойхерни. И стоит только захотеть и ты сегодня придумал, завтра написал, а после завтра миллионер и работаешь по 2 часа в день.
Кто не сталкивался с воровством 3000$ (коротенькими транзакциями, разумеется) с карты по номеру и CV коду в банальном американском супермаркете посредствам видеонаблюдения над кассовым аппратом и вероятного сговора между кассиром (которая на доли секунд перевернула карту другой стороной) и охраной (которая эту инфу записала на бумажку и потом использовала), тому не понять, что такого важного может быть в том, чтобы не доставать карточку вообще.
Казалось бы — достал, передал кассирше, она её вставила, что-то набрал и дальше пин вводишь. Что может случиться?! А вот может и ещё как может.
А ещё банк говорит «вы давали кому-то карту в руки?».
Ты такой: «нет конечно». А в магазине продавцу? Ну полстолько если продавцу, чтобы вставить в терминал…
Ах, т.е. давали. Ваша честь, пунктом договора 123 запрещается передача кому-либо платёжных карт, которые являются собственностью банка. Клиент нарушил условия договора и передал карту, бабки мы ему возвращать не намерены. Это уже печальная судебная практика с которой меня ознакомили юристы.
2гис не работает для ios 7 и iphone 4. Что вы за компания, которая отметает своих клиентов?! Кто мешает оставить старую версию для ios 7 и не обновлять её?! или обновлять только картами онлайн, а не функционалом. нафиг он новый не нужен.
Налаживается всё с IT в Крыму. Фиг знает что с этой долиной, но в целом стабильный рост. После спада и перестроения структуры, когда часть компаний решила переехать пустое место потихоньку начали занимать другие компании. Спад был по 4-м причинам:
1. некоторые безумные владельцы компаний были напуганы своими «украинскими» партнёрами и новостями, что свернули дейятельность и переехали. Менее безумные просто подождали и сейчас снимают сливки.
2. из-за ожидания «что там будет дальше» не спешили тут открываться в прошлом году. Сейчас навёрстывают.
3. из-за привычки все считать в $ и жадности владельцев компаний, которые платят в рублях (тот же люксофт или датаарт на украине платят в $ а в россии в рублях, получая прибыль в долларах) народ стал получать резко меньше, чем привык. Впрочем как и везде в россии. Вот некоторые и поехали вслед за компашками. Год-два и все вернуться. Особенно после проседания рубля, когда работать за валюту и экспортировать мозги и идеи стало ещё выгоднее.
4. ну ещё и от того, что в России джава и пхп значительно больше распространены, чем тот же .net и был небольшой перекос в вакансиях-резюме. Сбежали самые глупые и истеричные, а теперь многие из них кусают локти, потому что уехавшие с их компаниями люди во всякие мински или польши на 2200$ и снимающие там квартиру за 400$ уже подумывают о том, как бы вернуться обратно и делают это. За примером далеко ходить не надо — 3 коллеги на работе, покорявшие Питер и Минск вернулись и работают на свои 90-120 тыр. И кстати ещё вопрос от куда сбежало больше из крыма компаний или из украины разработчиков.
Но спад уже прошёл примерно в мае-июле и начался рост. Появились новые компании, в т.ч. открылись новые не с материка. Появились новые проекты и люди заняты. Проблем с банками и переводами валюты нет. У нас есть клиенты и из америки и из европы и из израиля и из москвы, которые отлично и успешно переводят средства с небольшой хитростью. Крупные и вполне солидные. А про губительность санкции трындят в основном укропы, которые судя по комментариям выше, реально рассчитывают сюда вернуться не на правах гостей. Всё обходится на раз два. Главный стимул роста — дешёвый рубль и низкие ЗП в россии для экспорта мозгов. не можем вон вакансии закрыть уже, весь резерв, который был ещё пол года назад в 10-15 человек уже закрыт и +5 новых человек ищем. Часть кандидатов из Новосибирска, Кирова, Твери. Переезжают сюда.
Даже не парься об этом. Идеи ничего не стоят. Совсем ничего. Ноль. Можешь попытаться возразить, но всё равно придёшь к выводу, что ноль, если подумаешь. И вот почему: если бы сами идеи чего-то стоили, то давно бы был уже рынок по продаже идей. И кто-то их покупал, кто продавал. А рынка такого нет. Есть конечно люди, которые говорят, что заплатят миллион за идею, но это всё враньё и бахвальство. Потому что денег стоит стоит только реализация идеи и команда, которая смогла реализовать хотя бы прототип работающий. И покупатель прекрасно знает это. А идеи (без реализации ) — это просто слова, фантазии, чьи-то хотелки. И не факт что совпадающие с большинством, готовым платить
К тому же чисто по теории вероятность твоя идея уже 100% кому-то приходила в голову и ни одному. Где реализация? А нет её или уже есть давно (частенько с этим сталкиваюсь)
Так что можешь рассказывать кому угодно. А если ты, например, далёк от какой-то области и тебе повезёт поделиться своей идей с человеком из той области, то получишь быстрый фидбек, «что классное приложение, где можно меняться статусами и фотками с возможностями смотреть порно уже давно есть». А пацанты-то и не знали!
Да и все эти авторы книг по DDD и микро сервисам они, конечно же дураки.
Заканчивать действительно стоит, раз на подробный комментарий человек безапелляционно говорит просто глупость в духе «ой всё». Вероятнее всего вы или не писали сами микро сервисы (судя по выступлениям вы обычный менеджер который делал раньше девопс, а не разработчик) или писал неправильно, но потом героически решал проблемы вызванные своим недопониманием проблемы связанности и разделения (распределённые транзакции, там где они не нужны, гонки в распределённых сервисах, многоуровневые подзапросы и т.д.)
PS и ваши моментальные и безответные минусы — как детский сад: радуют и забавляют. Когда нечего ответить, а признавать что не прав стыдно, то лучше поправить пенсне и притвориться важным
А всего лишь надо было иначе проектировать: 1 микросервис = 1 фича, т.е. один контекст. Не функционально близкие вызовы, а фича! Глобальный контекст это продукты или ордера в которые входят несколько микросервисов про ордера, например (импорт, отображение, проводка). Они не должны быть между собой связаны функционально, только логически, на схемках. А у вас это было функционально связано, не просто кодом, а вызовами сервисов. Конечно комок грязи получится.
У вас не должно быть микро сервиса product, order, catalog которые лепят CRUD операции плюс что-то делают. Это типичная ошибка новичка, которую 100 раз описали в книгах и обсудили. Но т.к. это про проектирование предметной области, а мало кто умеет это делать, то все просто пропускают мимо ушей и бегут деплоить докером новый orderService. У вас может быть микросервис «отобразить ордера для грида с общими данными, фильтрами и агрегацией», «провести новый заказ», «отменить заказ», «импортировать продукты», «отобразит продукты». Это физически разные сервисы. Тогда у вас не будет комка грязи с кучей вызовов. Вызовов вообще быть не должно практически. Максимум 1 уровень после Api Gateway + первого сервиса (того 2 уровня).
А главное, после такого объединения в 10 монолитов мы:
1. Получаем высокий уровень связанности, продолжая расширять его (нам же нужны новые фичи), вместо того чтобы не трогать то, что и так работает и делать новые фичи в новых микро сервисах. А связанность — главная проблема монолита. Она и влияет на сложность поддержки и увеличение вероятности ошибок и приводит к краху бизнеса, когда никто легаси г. не хочет расширять и даже переписывать. И это уже следующая глобальная беда, от которой страдает бизнес. Это вообще главная проблема — высокая стоимость поддержки и цена ошибки. Бинго, мы вернули её.
2. Мы не можем больше переписать микросервис за разумное время (12 человек за 1 неделю), не может быстро найти проблему и пофиксить её, не сломав другие куски, мы должны все перетестировать, вместо 1 куска.
3. ХЗ что делать с историей кода, т.к. 1 микросервис = 1 репозиторий. У нас не так, у нас общий репозиторий? поздравляю, мы мазохисты, но пока не знаем об этом.
4. Про порядок деплоя вообще смешно слушать было. Вы серьёзно? может у вас ещё микро сервисы один за другим вызываются и ждут действий в определённом порядке, а не только как справочники? Ок, молодцы. Вы сделали свою SOA шину. Это г. не работало ещё в 2005ом.
Слово микро — ключевое, а не лишнее. А то, что кто-то не умеет управлять большим количеством сервисов — так это его личная проблема, а не проблема архитектуры.
Вот что бывает, когда люди, не имея практики и не зная современных подходов по проектированию процессов предметной области, а умея только перекладывать данные из табличек базы в UI, не зная как применять DDD и формировать правильные контексты берутся за следующий уровень — делить код на инфраструктурном уровне. А потом виноваты все — микросервис, архитекторы, зоопарки.
Зато освоили кучу новых слов и возможно даже технологий, кубренетисы, докеры, OSGI.
Более того, есть Lazy Loading который поднимет вам ваши 1000 комментов только если по ним нужно пройтись (если уж так получилось).
ПРичем всё это нужно именно для изменения модели предметной области. Для чтения можно использовать CQRS подход.
А вообще это сферический конь в вакууме. Нужен конкретный пример и на нём я смогут отмести 100500 «а если» и сформировать правильную модель. Иногда даже такую, которую даже сам не ожидал бы увидеть в начале. Просто нужно перестать думать данными и таблицами БД, а начать думать процессами (предметной области, бизнес-сценариями).
Тем ни менее это тоже не совсем верно. Я бы сказал нельзя дублировать контексты, но не их части. Где контекст предметной области — это определённая фича с её нюансами и правилами, а части — это конкретные данные и доступ к ним, реализация правил и ограничений, алгоритмы. Вот конкретные данные и алгоритмы можно и нужно дублировать. А контексты — нет. Информации, данных, нужно ровно столько, сколько её нужно в рамках предметной области, контекста или суб-контекста. Если нужно одни и те же данные в двух сервисах дублировать, значит нужно дублировать, а не шарить код. Если можно не дублировать (например, очевидна перспектива вынесения общего сервиса), то нужно не дублировать. Но в жизни не очень грамотными разработчиками принята за аксиому и священную корову норма, что дублировать «низя и точка». От сюда на практике случаев общих библиотек предметной области или DAL в разы больше, чем случаев проблем из-за дублированной инфы.
Итого, весь принцип DRY является высосанным из пальца неуклюжим определением, попыткой реально сложную неочевидную вещь объяснить на пальцах, сделав только хуже. Ни чета определением из той же физики. Одно дело объяснить папусу, почему земля круглая, а другое дело заставить его после этого строить ракету или пойти в кругосветку, обладая только знанием, что земля круглая. Просто автор DRY, Д. Миллер, сам не очень хорошо понимает то, о чём пишет. А после этого ещё хуже интерпретируют читатели. А сводилось всё к тому, что должен быть 1 файл конфигурации в 1 месте для одной системы.
Видимо мы про какие-то разные ситуации говорим. Вы, стало быть, про «создание впрок» или нечто подобное. Но т.к. рефакторинг происходит постоянно, то сложно даже прочертить границу когда нужно создавать. Сейчас или через час. Понятное дело, что создавать сущности которые через неделю наверное понадобится — это бред. Но опять же программирование, как живопись или скульптура, процесс постоянных изменений, добавления объёма и формирование формы. А потому рефакторинг — это часть написания кода и добавить во время разработки сколько надо сущностей, половину потом удалить потому что предметная область обрела новые детали и вырисовалась новая форма — это и есть единственно правильный и оптимальный подход.Это то, о чём я говорю. В противовес ему я знаю только 1 вариант: всё запланировать и расписать заранее(водопад), вплоть до классов и методов, но потом с этим г. невозможно просто работать и от этого все нормальные компании давно отказались. Вариант же «добавлять по мере необходимости» и есть часть моёго подхода. Просто необходимость меняется с прорисовкой детали и там где у тебя был 1 класс (сущность), может появиться 3, но потом из-за тех. деталей, выявлений общего поведения чего-то ещё, може остаться в итоге 2 класс. ну и т.д. Это просто нюансы.
Сложно угадать что вы имели введу, но возможно то, что математик пытался бежать впереди поровоза в духе «я знаю что это потом понадобиться». Не, это неправильно, это зло.
Но, если у нас предметная область различается хоть на 1 поле, тогда:
Это правильно. Хороший контекст и домен превыше всего. Вообще всего. Потому что это залог:
1. минимизации ошибок в реализации
2. минимизации скрытых ошибок и сайд-эффектов
3. возможности передать код след. разработчику, и позволить ему разобраться в нём так, что тот выполнит п.1. и 2.
Можно жить с низкой производительностью — её можно улучшить. Можно жить с техническими багами реализации или недоделками (ну типа нет 100500 валидации на такое-то условие) — их можно исправить. Нельзя существовать с продуктом, которые делает не то, что нужно, да ещё и скрыто. И при этом не позволяет себя исправить ( например исправление только за счёт костылей, что вносит сумятицу и сайд-эффекты. разраб уволился, с ним и знание «а почему так», а код и контекст не говорят почему)
Но конечно, заготовки делать на случай просматривающегося контекста — это тоже зло. Разработка и развитие предметной области сродне лепки из пластилина или глины (обратное резьбе по камню): меся обрастает, потом переосмысление, рефакторинг всего. Если есть опыт, то рефакторинг проходит легко. Если говнокодили в начале, то с болью. Но нужно развивать доменную область, которая отображает фактическую модель систему — а не:
а) изначально запланированную, но которая оказалось избыточной\недоделанной
б) изначально незапланированную, но вылепленную без «развития», а потому таскающую за собой кучу легаси свойств и зависимостей из других контекстов, которые поленились создать\не поняли что надо создать.
Ну это и есть то самое развитие. Насоздавал. Понял что 5 из 8 сущностей лишние или дубли — удалил. Это норма.
Если рефакторинг перед началом каждой новой задачи, во время изменения куска кода или фикса бага то и нет проблем с поступательным развитием. А если рефакторинг — это плановая задача «вернуть тех. долг», то всё, считай нет и не будет его никогда.
ЗЫ Сори, меня раз в месяц комменты работают.
Вот это лютый бред и трешак, который привёл к монолитизации и колоссальному увеличению связанности и мешает людям подняться на ступень выше в написании качественного кода. С ним возятся до сих пор, хотя больше плохого, чем хорошего. Ну при условии что вы не мамкин сайт домашний пишите, а приложение миллионов на 5-7 строк кода. Он актуален исключительно в среде теоретиков и джунов, чтобы последние не копипастили один и тот же код в разных классах.
На практике, люди, упоротые этим принципом и не знающие других подходов с огромной болью живут в огромном монолитие с единой dll типа DAL единой dll типа DomainModel и т.д.
Всё это таскается из одного проекта в другой, шарится между десятками сервисов и апи и потом распилить такое на микро сервисы просто невозможно, точнее бизнес не хочет. Цена поддержки растёт кратно. Зато без копирования, ага.
Как нужно делать:
1. Не копировать код в рамках 1 класса и одной, при возможности одной dll.
2. Делать всё в рамках одной фичи. А ля микросервис. Это означает что нет никаких папок с кучей разных репозиотриев а ля Reposotories/AccountRepository и тут же Reposotories/OrdersRepository. А есть 2 фичи (Accounts/ Orders/) внутри которых есть такие репо (Accounts/AccountRepo, Accounts/AccountFactory, Orders/OrderRepo...). В будущем это позволит разделить контексты И если вдруг фиче про ордера нужен доступ к данным из аккаунта, то да, копипастится логика хоть полностью и делается свой репо (Orders/AcountForOrdersRepo… ). Менять её придётся разве что раз в 1000 лет. А вот поддерживать и менять в рамках одной фичи — сколько угодно раз. И нафига тогда нужен такая связанность с Account фичей? Нет уж.
3. По мере разрастания кода — разносить вообще в разные библиотеки (контексты) и репозитории.
А DRY на помойку.
Это тоже теоретическая чушь, которая на практике сводится к:
1) мы уже делали такое и знаем что примерно нужно сделать ещё раз. Тогда проблемы нет.
2) мы ещё не делали такое и хз что нас ждёт. В этом случае ничего не поможет, ничего не угадать. Например мы на своём проекте несколько лет использовали singlar для для работы множества клиентов с сервером и сервер с очередью через RebbitMQ. В итоге отказались от подхода, как нестабильного, перешли на realtime запрос-ответ. Угадать заранее, фактически без прототипа в продакшене такое было невозможно.
Что же на самом деле лучше сделать в таком случае?
а) Изучить максимум инфы по данной технологии.
б) делать простые небольшие изолированные куски. Потом с увеличением их числа вовремя рефакторить и объединять в контексты. Постоянный рефакторинг — только он поможет избежать факапа. А рефакторинг подразумевает поднятие на уровень выше в архитектуре и её пересмотр в том числе. Когда время пришло.
Вот это must have и за его нарушение (чаще всего S) увольнять к чертям. Оно хоть как-то спасает от связанности и роста проблем.
Очередной теоретический бред для джунов, наверное. Сущности всегда создаются в зависимости от контекста и бизнеса. Если у тебя 5 вариантов работы с ордерами и в одном случае нужны одни поля, а в другом — другие и только id + name общие, то это разные сущности. И их нужно создавать. А не гонять одну God object по всему домену. Увеличивая связанность. Если тебе нужно вернуть объект в виде json то не нужно возвращать сущность из предметной области. Пусть она хоть 1 в 1 пока совпадает с DTO объектом. Ключевое слово тут «пока» совпадает.
Фаулер и Макконели верно говорят, что самое дорогое — поддержка. А поддержка дорожает с увеличением сложности. А сложность в том числе берётся и от связанность, из-за невозможности просто удалить и заново переписать кусок. А вдруг кому-то что-то сломает?!
+100500.
Именно так.
Правильно вызывать асинхронный код исключительно через новый поток как написано выше:
var value = Task.Run(async () => await GetValueAsync()).Result;
потому что в зависимости от контекста вызова там куча вариантов (кажется 6), когда поток попадёт 100% в дедлок, когда не 100% и когда не попадёт. Разница для одного и того же кода будет даже если вы вызывали его как часть библиотеки, через IIS или как часть сервиса.
Когда речь идёт о UI (end-to-end) или API (функциональные) тестах, то всё кроме селениума и подобных библиотек — ненужная лажа для автоматизации тестирования, которую пытаются впарить клиентам за баснословные деньги. Пришлось прочувствовать это на своём опыте, когда CTO назначил использовать пару подобных платных штук (хиптест и что-то ещё, уже не помню название), вместо nunit\xunit и ЯП. Через год мучений просто отказались и забыли как страшный сон. Ускорение выполнения только после переделки под nunit выросла в 3 раза.
Вся автоматизация должна делаться исключительно на языке программирования, дабы минимизировать стоимость поддержки, скорость запуска и разработки, а также покрывать условия:
1. На каждый тест легко создаётся свой набор данных и легко удаляется. Система должна оставаться чистой
Например в базе данных перед и после должно удаляться всё что, касается ордеров, если мы тестируем фильтры или создание\отображение ордеров. И потом создаваться нужные наборы и комбинации, а не из кучи мусора выбирать нужный нам.
2. Должен быть максимально гибкий и удобный инструмент по созданию тестовых данных.
Очевидно что это код на ЯП, а не галиматья в виде скриптов от третьесортных систем, кукумберов и прочей визуальной фигни. И не да бог с кодогенерацией.
Никакие апи или там SQL скрипты также не подходят для создания тестовых данных.
а) Апи (речь про открытые интерфейсы, не про библиотеки) или веб-апи не подходит потому, что ваша система может тупо не иметь апи для создания половины сущностей. Например вы тестируете грид и фильтры (достаточно просто насоздавать разных ордеров), а ордера импортируются кучей разных сервисов из разных маркетплейсов. Т.к. тест должен иметь ограниченный контекст и не занимать пол дня, то разумно отображение тестировать отдельно, а импорт сервисов — отдельно, т.к. это другая система из другого сценария. Конечно же может быть и сценарий по импорту ордеров из маркетплейса. Но его набор данных не должен быть связан с тестами фильтра на гриде.
б) Чистые SQL скрипты создания данных не подходят потому что поддержка их будет заниматься больше времени, чем создание теста, а всё на стороне БД будет изменяться очень-очень часто. Вовремя отказались от такого, казалось бы, разумного подхода. Плюс скрипты в духе вставить в одну-две таблицы — это детский сад. В крупных системах такого не будет, а будет куча хранимок, иногда с несколькими версиями в которых сложно разобраться
Выход на самом деле простой — использовать DAL библиотеку, которую поддерживают разработчики для создания тестовых данных. Тогда вы изолируетесь от всего головняка с поддержкой своего самописного дала и от сложности создания многих сущностей в бд.
Ещё лучше, если у вас нормальные разработчики, использующие DDD там будет всё намного проще. Просто берёте фабрики с репозиториями и генерируете данные, которые вам нужны для UI\API
В автоматизации решает стоимость её поддержки. Автоматизация загибается, когда сложность поддержки увеличивается. При этом нужна достаточная гибкость при создании данных, а также скорость выполнения тестов. 200-300 end-to-end тестов выполняются 3-4 часа на UI. Против 20-30 минут для функциональных (АПИ), против нескольких минут для интеграционных (dal, связки систем), против нескольких секунд для unit (методы)
Скорость и покрытие напрямую зависят от способа создания данных. Если вам нужно протестировать 10 фильтров на гриде с кучей комбинацией, то что проще: каждый раз вызвать апи, создавая сущности или одним махом залить все нужные комбинации в базу, очищая все лишние сущности от прошлых тестов?
Вывод — ознакомьтесь с очередной подборкой «топ-5 самых лучших инструментов в year_number» и отложите их на полку, если они не могут быть использованы в коде.
А ещё integration testing это не фейки и песочницы, это реальные стыки систем. Это, например, тестирование DAL уровня запросв (методов Repository) с реальной базой. тестррование методов repository по обращению к сервису с реальным сервисом по http. Но никак не с фейкам. Нет песочницы и тестового аккаунта к реальной системе? Значит для этого куска нельзя реализовать интеграционные тесты. Обходитесь юнитами. И уже тем более интеграционное тестирование не «просто уровнем выше будем тестировать: наделали кучу зависимостей разных подсистем и один монстро-тест запустили, который и в базу лезет и в сервис шлёт и в очередь». Это самая распространённая ошибка, которая становится причиной: «ой… чё-то тесты опять упали», а потом «ну да, есть тесты, но поддерживать их тяжко, потому не запускали давно»
Для автотестов делается свой сервис со стабами, фейк у вас в статье. В который скармливается «ожидаемый ответ на ожидаемый запрос» а ля Setup из библиотеки Moq только по HTTP
И погнали тесты делать любые. QA должен был знать такие базовые вещи, прежде чем использовать карту. Но это ещё большой вопрос, надо ли это делать, когда достаточно один раз от реальной системы получить ответы, понять логику и всё заменить моками.
Ещё бы. Когда на уровень юнит-тестов бизнес логики лезем е2е тестами, да ещё и с нестабильным инструментарием. Разделять, это нужно разделять. Бизнес логика тестируется только юнитами и только моками, никаких песочниц от эппл. Песочница это е2е тесты и частично интеграционные.
нужно трекать такие изменения. документацию или запросами к реальному серверу раз в день, например. Как минимум версию сервиса трекать и\или xsd схему.
ЗЫ
О боже, опять это дурное слово из рунглиша — «нужны знания и экспертиза». Пришлите адрес, вышлю ссылку на словарь Ожегова.
Экспертиза в русском языке это документ, заключение по результатам исследований: «проводить экспертизу».
В том значении, в котором автор пытается применять слово переводя с английского, есть добротное выражение: «знание и опыт» или «специальные знания». Но никак не «знания и экспертиза».
Нужные знания и опыт. Или нужные опыт и специальные знания.
потому всё это расследование бред чистой воды. Весь смысл был взять в 2014 году за жопу какого-нибудь сына российского чиновника или депутата и давить на Россию. Ну и т.к. это всё чепуха, то её можно было и на конференции рассказать. Чтобы другие хакеры узнали «оперативные методы» и лучше прятались, наверное? Всё.
Ничего иного в русском языке оно не имеет, кроме значения «опыт». Ваши фантазии на тему слов и понятий ничего не значат для других людей, это лишь ваши заблуждения. Карта — не территория.
Просто не хотят люди, привыкшие к англицизмам, принять тот факт, что в русском языке достаточно слов, чтобы выразить любую мысль.
Тем хуже. Потому что это переводится как навыки общения в коллективе — более точное и ёмкое название, чем сленговое выражение soft skills.
Вижу, русский язык — не ваш конёк.
use case — это ничто иное как один из следующих вариантов( как богат русский язык, правда?): способ\ вариант\ пример использования или ещё лучше и точнее — прецедент.
Давай все словам заменим в русском языке тогда? Почему говорим клавиатура, а не кейборд? Отправьте мне на почту, а не на mail? Как «большие объемы данных» это переводится.
Эти методологии имеют общее название «точно в срок». Найти подходящий перевод или аналог — задача переводчиков. Переводить это вообще нормально, если это не новое слово, как например «автомобиль» для начала 20 века. Иногда это могут быть уже имена собственные и нужно оставлять как есть, а иногда просто нужен переводчик.
Вы не
чекинитене заливаете (сленг) код? Тогда у меня плохие новости…Правильный перевод был бы «сдать\отдать (типа как под расписку) код».
Вообще-то митинг — это обычное совещание. Да, планёрка звучит куда лучше, потому что русское слово, произошедшее от слова план (латинское planus- ровный) и сто лет в обед обрусевшее.
но в данном случае выбор очевиден — совещание.
Чем?! Чем оно нормальное? Фидбек это «обратная связь», «отзыв»!
Вам в университете фитбек профессор на дипломную работу давал или отзыв писал?
Нужно просто лапки к верху поднять и принимать всё как есть. Пусть нас пожирает иностранная культура, а мы, вместо перевода слова на русский, будем заимствовать лексикон из языка другой культуры, причем (это важно!) в тех местах, где совершенно нет в этом необходимости.
и потом
Ничего не имею против, т.к. сам пишу под .net но нужно как-то поскромнее сперва ёрничать над другими, когда сам пользуешься продуктами той же компании.
Иначе говоря только закончил универ и уже через 5 лет гендир. «23 трехлетний СЕО» — это повод для стыда, а не для гордости. Иностранцы смеются над нашими синьорами с 5-7 годами опыта. Это они про СЕО ещё не знают.
Сразу вспомнил про один психологический эффект: когда чиновник достигает своего максимального уровня и больше не может эффективно работать на вверено ему должности, то дабы он не вредил «в поле», его повышают или придумывают должность под него. но такую, чтобы не мешал и мог надувать щёки. Не такой ли наш герой?
Видимо не справился с обязанностями CEO, потому пришлось уйти в
Т.е. руководил админами, картриджи меняли, сетку тянули, 1с ставили. Ясно, понятно.
судя по копеечным вакансиям «PHP — $500.»
Java — $1400
и совсем не софтварному профилю ( какая газо-химическая контора) к информационным технологиями данный герой-управленец имеет крайне косвенное отношение. Я бы назвал продвинутый пользователь всяких там Sharepoint и прочего… вна. Который, в виду размеров компании, даже имеет свой отдел разработки из 10-15 человек. Но заявляет, что чуть ли ни ИТ-бизнес решения предлагают.
Короче, лесом. История любого разработчика, который сидит на удалёнке на 5-7кило или участвовал в провальном проекте будет гораздо интереснее, чем «яйца на завтрак».
2. Можно ли через psp например не списать деньги, а заморозить на 30 дней, до получения товара покупателем? шлюз также как напрямую через эквайр
3. Кто в данной схеме может выступать арбитром сделки, если нужна такая сделка (деньги замораживаются и ждут подтверждения)? шлюз или банк?
Казалось бы — достал, передал кассирше, она её вставила, что-то набрал и дальше пин вводишь. Что может случиться?! А вот может и ещё как может.
А ещё банк говорит «вы давали кому-то карту в руки?».
Ты такой: «нет конечно». А в магазине продавцу? Ну полстолько если продавцу, чтобы вставить в терминал…
Ах, т.е. давали. Ваша честь, пунктом договора 123 запрещается передача кому-либо платёжных карт, которые являются собственностью банка. Клиент нарушил условия договора и передал карту, бабки мы ему возвращать не намерены. Это уже печальная судебная практика с которой меня ознакомили юристы.
1. некоторые безумные владельцы компаний были напуганы своими «украинскими» партнёрами и новостями, что свернули дейятельность и переехали. Менее безумные просто подождали и сейчас снимают сливки.
2. из-за ожидания «что там будет дальше» не спешили тут открываться в прошлом году. Сейчас навёрстывают.
3. из-за привычки все считать в $ и жадности владельцев компаний, которые платят в рублях (тот же люксофт или датаарт на украине платят в $ а в россии в рублях, получая прибыль в долларах) народ стал получать резко меньше, чем привык. Впрочем как и везде в россии. Вот некоторые и поехали вслед за компашками. Год-два и все вернуться. Особенно после проседания рубля, когда работать за валюту и экспортировать мозги и идеи стало ещё выгоднее.
4. ну ещё и от того, что в России джава и пхп значительно больше распространены, чем тот же .net и был небольшой перекос в вакансиях-резюме. Сбежали самые глупые и истеричные, а теперь многие из них кусают локти, потому что уехавшие с их компаниями люди во всякие мински или польши на 2200$ и снимающие там квартиру за 400$ уже подумывают о том, как бы вернуться обратно и делают это. За примером далеко ходить не надо — 3 коллеги на работе, покорявшие Питер и Минск вернулись и работают на свои 90-120 тыр. И кстати ещё вопрос от куда сбежало больше из крыма компаний или из украины разработчиков.
Но спад уже прошёл примерно в мае-июле и начался рост. Появились новые компании, в т.ч. открылись новые не с материка. Появились новые проекты и люди заняты. Проблем с банками и переводами валюты нет. У нас есть клиенты и из америки и из европы и из израиля и из москвы, которые отлично и успешно переводят средства с небольшой хитростью. Крупные и вполне солидные. А про губительность санкции трындят в основном укропы, которые судя по комментариям выше, реально рассчитывают сюда вернуться не на правах гостей. Всё обходится на раз два. Главный стимул роста — дешёвый рубль и низкие ЗП в россии для экспорта мозгов. не можем вон вакансии закрыть уже, весь резерв, который был ещё пол года назад в 10-15 человек уже закрыт и +5 новых человек ищем. Часть кандидатов из Новосибирска, Кирова, Твери. Переезжают сюда.
К тому же чисто по теории вероятность твоя идея уже 100% кому-то приходила в голову и ни одному. Где реализация? А нет её или уже есть давно (частенько с этим сталкиваюсь)
Так что можешь рассказывать кому угодно. А если ты, например, далёк от какой-то области и тебе повезёт поделиться своей идей с человеком из той области, то получишь быстрый фидбек, «что классное приложение, где можно меняться статусами и фотками с возможностями смотреть порно уже давно есть». А пацанты-то и не знали!