О чем нужно рассказать, когда спрашивают про архитектуру проекта/приложения?

Question

[Евгений Шустрый]

Привет всем. Зачастую, на собеседованиях просят рассказать об архитектуре приложения/проекта на текущем месте работы, на самом деле не совсем понимаю, что означает "архитектура" ?
Для меня архитектура это то, предположим, как связаны компоненты системы, в каком виде они хранятся.
Например, есть application server и какие-то компоненты хранятся виде ejb в контейнере, общаются разные подсистемы при помощи jms.
В общем интересно послушать Вашего мнения, которые могли бы объяснить на чем следует делать акцент при описании "архитектуры" и что вообще под этим понятием подразумевается, только пожалуйста без ссылок на вики.

Comments

[devalone]

Зачастую, на собеседованиях просят рассказать об архитектуре приложения/проекта на текущем месте работы

Отвечай просто: NDA :)

[Сергей Горностаев]

̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻ ҉, и получай тестовое задание того объёма, на котором сможешь продемонстрировать свои знания в этой области.

Answer 1

[Сергей]

Отвечай "мы стараемся придерживаться чистой архитектуры, но у нас столько легаси кода..." )))
Вообще Роберт Мартин писал, что основное преимущество ООП, что это позволило разбивать систему на части-плагины. Т.е. систама разбита на довольно независимые части которые, которые взаимодействуют между собой через довольно устойчивые интерфейсы.
Архитектура это как эти плагины разметить в системе.
Например чистая архитектура имеет узнаваемую структуру
в ценре бизнеслогика, вокруг вещи которые предоставляют логике данные, сохранение этих данных... вокруг различные сервиса, отображение в ui, работа с сетью, с базой данных и т.п.
Т.е. получается слои. Важный момент, что внутренний слой не зависит от слоя который внешний. Поэтому появляется независимость от реализации от внешних слоев. И к этому появляется сравнительное простое тестирование частей системы.
Т .е. (на примере чистой архитектуры, описанной здесь совсем не точно и очень сумбурно)
Рассказ об архитектуре должен быть об разбивании системы на части и как эти части зависят друг от друга. И какие выгоды или проблемы такое разбиение дает.
Так же часто сопутствуют вопросы "как организовано взаимодействие слоя А со слоем/компонентой Б". Там скорее проверяется знаете ли вы решение типовых проблем. И шаблонов. например MVP, MVC, MVVM, Repository и проч.

Answer 2

[Vitaly]

Вопрос сам по себе слишком общий. В ответ обычно надо задавать уточняющие вопросы. Про технологический стек, тип приложения, уровень детализации, слои и т.п. спросить. А уж на том, что действительно интересно собеседнику и делать акцент. Можно ещё рассказать обо всём поверхностно и по реакции понять, что действительно интересно, но спросить всё-таки лучше.
Самая серьезная ошибка на технических собеседованиях: начать отвечать на вопрос без полного понимания того, о чём вас спросили. Задавайте уточняющие вопросы, вовлекайте собеседника, рассуждайте вслух и т.д. Нормальное техническое собеседование проверяет вашу способность думать.
Вообще, универсальный рецепт при любой дискуссии, и не только на собеседовании: определить о чем и зачем вообще дискуссия. Т.е. определиться в терминах, уточнить граничные условия, уровни детализации, к чему хотим прийти и т.п. Но, предупреждаю сразу, люди вас за это любить не будут :)

Answer 3

[Алексей Джо]

Много чего можно рассказать. Достаточно прочитать книгу Мартина Фаулера «Архитектура корпоративных программных приложений», из которой все станет понятно.
В общем смысле архитектура - это способ организации системы, например n-tier архитектура. Архитектура в детальном смысле - используемые паттерны проектирования и то для какой цели они используются, например использование паттерна Repository для реализации основных методов взаимодействия с БД, например CRUD.

Для игр, например, архитектура также представляет способ организации системы в целом и описание используемых паттернов проектирования для организации каждого компонента системы в отдельности. Но с корпоративными приложениями лучше не сравнивать.

Comments

[Иван Шумов]

Труд Фаулера действительно достоин. Можно сказать что это сейчас настольная книга архитектора, и даже не начинающего. Жаль не все до него доходят. Хотя он объясняет все достаточно простым, как мне кажется, языком