Не знаю как дела обстоят сейчас, но лет 5-7 назад на собеседованиях было ультра-модно спрашивать про архитектурные шаблоны. Абстрактные фабрики, синглтоны, вот это все. Возможно это и хорошая разминка для ума, но ведь архитектурные шаблоны - не самоцель. Они - средство. А цель - это адекватная архитектура приложения. Не супер-сложная (чтобы коллеги не приходили в ужас от количества реверансов и условностей при чтении/написании кода), не полное ее отсутствие (никто не любит big ball of mud катающийся в тарелке со спагетти), а сбалансированная (т.е. с умеренным использованием абстракций и инкапсуляции), симметричная (все компоненты примерно одного размера, нет god objects и армии анемичных недо-компонентов) и обладающая слабым зацеплением (aka loose coupling, обожаю российскую терминологию) структура программы.
Level up your server-side game — join 8,000 engineers getting insightful learning materials straight to their inbox.
Достигнуть такой адекватной архитектуры помогает следование некоторым принципам. Например, мы должны стараться производить код с loose coupling и high cohesion (нет, даже не буду стараться перевести на русский эти термины). Еще один замечательный свод принципов - это SOLID. Четыре из пяти его постулатов применимы и за пределами объектно-ориентированной парадигмы. Любой компонент системы должен стараться не брать на себя слишком много (single-responsibility principle), быть легко расширяемым без необходимости копаться по локоть в его кишках (open–closed principle), обладать лаконичным и недвусмысленным интерфейсом (interface segregation principle) и не зависеть от конкретных реализаций соседних компонентов (dependency inversion principle). Заметьте, я умышленно не употреблял слово код в прошлом предложении, потому что более высокоуровневые компоненты (микросервисы, очереди задач, API и пр.) также должны удовлетворять этим принципам, чтобы результирующая система оказалась адекватной.
А шаблоны - они лишь одно из средств с помощью которых можно попробовать достигнуть вышеупомянуты принципов. Они же - то, с помощью чего можно сделать код просто адски-нечитаемым, когда применяются без понимания высшей цели. Так что обращайте больше внимания на фундаментальные принципы, а не на модные техники и умные названия, друзья.
Навеяно недавней статьей Кента Бека Monolith -> Services: Theory & Practice.
Подпишись на обновления блогa, чтобы не пропустить следующий пост!
