Comments 22
Может, статья и неплохая. Но почему она оказалась в разделе "Новости"?
PS Обращаю внимание @moderator
Какую литературу посоветуете, чтобы укрепить навыки проектирования архитектуры?
Вот небольшой список от Александра, автора статьи)
https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
https://www.amazon.com/Software-Architecture-Trade-Off-Distributed-Architectures/dp/1492086894
https://www.amazon.com/Building-Secure-Reliable-Systems-Implementing/dp/1492083127
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321
Есть ещё один прикольный антипаттерн, называется Testing Driven Development. Это когда пишется куча тестов, под них заводиться какой нибудь Continuous Integration сервер, сперва этот зоопарк даже пытаются как-то поддерживать. Но со временем требований становится всё больше, архитектура приложения меняется, заказчик поджимает... в итоге на тесты просто забивают и убирают их с сервера. А когда майлстоун сдан, код уже настолько ушёл вперёд от тестов, что поддерживать их более нет возможности и желания.
Хочется поправить. Сам TDD не является антипатерном. А вот его не верное применение - да.
TDD отлично подходит для покрытия конного, не бизнес функционала. Например у вас есть реализация своего DSL заточенного под вашу предметную область. Поверх этого DSL написано куча бизнес-логики.
Если вы будете пытаться в TDD и на DSL и на бизнес-уровне - будет то, что вы описали
Если покрыть с помощью TDD сам DSL, то это отличное решение. Который позволит добиться большой стабильности и отсутствия регрессий при развитии синтаксиса/логики самого DSL.
А как же старый-добрый божественный объект? Как же спагетти код (он же рак абстракций)?
А "ком грязи", насколько я понимаю, правильно называется "высокое сцепление".
А ещё есть "луковый код", когда слоёв абстракции over 100500.
А. Значит, я перепутал название. Я имел ввиду как раз ситуацию, когда адаптер поверх прокси поверх фасада поверх декоратора и всё это приправлено интерфейсами.
А ещё есть противоположность божественного объекта - каша из интерфейсов (interface soup). Возникает, когда проектировщик недостаточно знаком с предметной областью и с принципами разработки ПО. В итоге всё вокруг - интерфейсы, сплошные касты туда сюда и "за деревьями не видно леса".
-
Спасибо за статью. Всё, что прочитал - уже знакомо, но лишний раз не помешает.
Не знаю, как такое обозвать, но у нас в фирме при разработки интерфейсов использовали формат JSON. Да, модерный формат. Но используют его в ETL процессах. Вместо CSV. И всё бы ничего, но объем данных передаваемых с помощью JSON 3-5 гигабайта. И иногда не хватает окна времени, вовремя эти данные прочитать и положить в базу данных. Взяли-бы для этого csv - думаю этих проблем не было-бы.
Обычно такое получается, когда приложение проектируют "20-летние синьйоры", закончив 3-дневные курсы ВеликихАрхитекторов. Всё в рест, всё пихаем в джсон, всё яваскриптом и электронами. В итоге хелловорлд на 20гб.
Точно. И что интересно, никакая аргументация не помогает. Стоят на своём, что все используют json. Я привожу пример - все люди используют ножи, но ведь не для спиливания дерева.
Ну справедливости ради, json тоже вполне себе можно быстро парсить. Например, тут парсят со скоростью 3.5 Гб/секунду https://github.com/simdjson/simdjson
Да и жмется обычной он вполне хорошо (я сжимал биржевые данные и получал сжатие до 27 раз).
Да и просто замена может не сработать, например, если у разработчиков неструктурированные данные, то не получится однозначно сконвертировать.
Еще важный момент, что переход от json к csv на на текстовых данных вероятно уменьшит размер всего в 2 раза (если предположить, что размер ключей ~ размеру значений), что уменьшит размер в вашем случае до 1.5...2.5гб, чего может быть недостаточно, если количество данные растет
Выглядит, что проблема точно не в формате данных. Замена на csv не решит проблему, в лучшем случае отсрочит. вероятнее всего вам нужно более глобально архитектуру переделывать, чем просто поменять формат
Рассмотрим первый антипаттерн. Классический count(*) конечно встречается в коде, но зачастую вся бизнес логика заточена после слова where. И тут могут быть вполне сложные конструкции которые тащить из БЛ в слой базы тоже так себе затея. Плюс если нужно не просто узнать количество, но и произвести какие то манипуляции с самими записями, то количество просто является приложением к.
Антипаттерны проектирования