Всем привет!
Cуммирую серию постов про DDD - https://telegra.ph/Izuchaem-DDD--predmetno-orientirovannoe-proektirovanie-08-30
#ddd #books #book_review
Cуммирую серию постов про DDD - https://telegra.ph/Izuchaem-DDD--predmetno-orientirovannoe-proektirovanie-08-30
#ddd #books #book_review
Telegraph
Изучаем DDD – предметно-ориентированное проектирование
Всем привет! Еще в начале лета в моих постах были намеки на хорошую книгу по DDD. Сейчас как раз самое время про нее рассказать))) Влад Хононов "Изучаем DDD – предметно-ориентированное проектирование". Настоятельно рекомендую к прочтению всем, кто интересуется…
👍2
Всем привет!
Возращаясь к тебе legacy.
Давно хотел прочитать книжку Эффективная работа с унаследованным кодом. legacy в жизни разработчика есть всегда (если только он сознательно не ищет только greenfield проекты), поэтому тема полезная. Книга не новая, но судя по отзывам (и по факту как выяснилось) актуальная.
Небольшое введение в тему. Есть 2 способа бороться с легаси - я бы их назвал архитектурный и програмистский. Архитектурный - взять и сделать рядом новую систему, постеменно перетягивая туда функционал и используя такие паттерны как Strangler Application, API Gateway, Decorator, Facade...
Програмисткий - улучшать легаси изнутри, делить его на микросервисы по необходимости и т.д. Это конечно крайности, как правило используется смесь обоих подходов.
Так вот - книга про второй способ. Я ожидал найти там набор практик и паттернов по улучшению легаси. И более того - они там есть. Но главная мысль в книге другая, и она немного неожиданная. Сразу вспомнилась шутка: как только код написан - он уже стал легаси) И так может быть) Если мы даем такое определение легаси - много кода без тестов. Почему? В чем основная проблема легаси? Никто не знает досконально как оно работает, никто не хочет с этим кодом разбираться и, как следствие, его боятся менять. Очевидно, что если кода много и тестов нет - менять его страшно. Бинго. И собственно вся книга о том, как написать недостающие тесты даже если на первый взгляд это кажется очень сложным.
#legacy #book_review
Возращаясь к тебе legacy.
Давно хотел прочитать книжку Эффективная работа с унаследованным кодом. legacy в жизни разработчика есть всегда (если только он сознательно не ищет только greenfield проекты), поэтому тема полезная. Книга не новая, но судя по отзывам (и по факту как выяснилось) актуальная.
Небольшое введение в тему. Есть 2 способа бороться с легаси - я бы их назвал архитектурный и програмистский. Архитектурный - взять и сделать рядом новую систему, постеменно перетягивая туда функционал и используя такие паттерны как Strangler Application, API Gateway, Decorator, Facade...
Програмисткий - улучшать легаси изнутри, делить его на микросервисы по необходимости и т.д. Это конечно крайности, как правило используется смесь обоих подходов.
Так вот - книга про второй способ. Я ожидал найти там набор практик и паттернов по улучшению легаси. И более того - они там есть. Но главная мысль в книге другая, и она немного неожиданная. Сразу вспомнилась шутка: как только код написан - он уже стал легаси) И так может быть) Если мы даем такое определение легаси - много кода без тестов. Почему? В чем основная проблема легаси? Никто не знает досконально как оно работает, никто не хочет с этим кодом разбираться и, как следствие, его боятся менять. Очевидно, что если кода много и тестов нет - менять его страшно. Бинго. И собственно вся книга о том, как написать недостающие тесты даже если на первый взгляд это кажется очень сложным.
#legacy #book_review
👍2