Comments 12
Чётко, спасибо, прочитал обе части за раз!
Статьи хорошие, но вот одного не могу понять - чего автор так привязался к Feng'у? Ну ушел себе человек гусей пасти, что тут такого? Все performance architect 'ы рано или поздно там оказываются :)
я много раз так делал, но не знал что этому методу придумали такое странное название.
Но вы изобразили слишком примитивную схему, фактически вырожденный случай, на практике все маленько (хотя в большинстве случаев - гораздо) сложнее, полная схема должна выглядеть примерно так:
Дело в том что практически нет шансов что Old Component не взаимодействует с остальным кодом приложения поэтому это взаимодействие тоже придется перенаправить и это самая боьшая сложность в реализации этого метода рефакторинга. Вот я уже смотрю на мою картинку с дополнениями и вижу что она тоже не полная.
вам в любом случае плюс за то что подняли интересную тему!
Чем больше тестов - тем лучше. Очень важно понимать, что в процессе переноса мы не создали новых багов и полностью совместимы с другими частями приложения.
а это похоже на какой-то подростковый максимализм, при этом это очень распространненное заблуждение. Обычно после какого-то оптимального (тут кстати очень уместно математическое: необходимого и достаточного) количества тестов, дальнейший рост этого количества тестов приводит к тому, что вы будете не в состоянии осмыслить результаты тестирования, просто потому, хотя бы, что в процессе осмысления второй четверти (например) этих результатов, вы забудете что вы поняли в первой четверти.
Короче говоря если без какого-то теста можно обойтись - это мусорный тест, если вы не знаете точно сколько вам нужно тестов (необходимо и достаточно) с большой вероятностью вы плодите мусорные тесты, и значит неэффективно расходуете ресурсы.
Я бы хотел иметь докумантацию по паттернам в таком стиле Ж)
Начинать надо с инфраструктурных вещей (шаблоны, CI/CD, авторизация, протоколы), иначе авторы разных микросервисов первым делом нагородят разных решений для одного и того же исходя каждый из своего чувства прекрасного. И через несколько лет, когда картинка должна начать сходится, будет прямо очень больно. Это опыт из практики, в теории никто не видит в этом проблемы, мол пусть расцветают все цветы. Но этот подход годится только для реально больших организаций, в организации более обозримого размера зоопарк не окупается
Спасибо большое за статьи!
Смеялся в голос с "Сильно тормозить и доставлять не те товары что были выбраны --> Main Core Service"
Очень легко и приятно читается такой стиль)
Мое уважение всем шуткам за 300 и даже за 299.99 *приподнимаю шляпу *
Сухого изложения мне хватает и в документации на своих проектах)
Спасибо, было познавательно и смешно,
буду ждать новых статей!
Автор тупой и вообще все что написано - ересь.
Хочу поблагодарить автора за интересную серию статей, невероятно сильно вкатывает стиль изложения)
Микросервисы для тех, кто прикидывается разработчиком. Часть 2