?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Часть 1. Об архитектуре и фреймворках

Posted on 2015.06.26 at 20:27
Tags: , , ,

Для начала в очередной раз внесем ясность в вопрос, что же такое архитектура. Сколько десятилетий термин в ходу, и в него постоянно вносят ясность - без особого толка. Однако, коль скоро мы собираемся о ней говорить, это совершенно необходимо сделать в очередной раз. Иначе будет просто не понятно, о чем речь.




Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.


Результат проектирования - это как правило некоторая высокоуровневая структура системы, которую тут же снова называют словом "архитектура" (ну вот мало у нас слов, и те все иностранные), а потом начинают ломать голову, чем же это отличается от "дизайна", и пр. И накидывать при этом кучу умняка. Мы не будем. Вместо этого:


  • Мы будем стараться использовать для обозначения нашего понимания термин "Common Design Principles".

  • Постараемся разобраться в определении, и как оно соотносится с фреймворками и структурами. Увидете, как только вы начнете думать об архитектуре как о правилах много встанет на свои места.

Ну вот как это, правила? - спросите вы. Ну вот у меня в системе, например, MySQL, я пишу сервер на PHP с фреймворком Laravel. Вот, могу слои нарисовать, какие у меня есть. Где здесь правила? - скажете вы. Да здесь их куча. И я вам сейчас их покажу.

Во-первых, подразумевается, что все меняющиеся данные (или по карйней мере большинство) должны храниться в MySQL. Как, у вас нет такого правила? Вы можете легко заменить MySQL на PostgreSQL? Значит, правило более ограничивающее - данные должны хранится в реляционной форме, и плюс к этому вы не должны полагаться на уникальные возможности конкретной БД в работе с ними.

Во-вторых, "с фреймворком Laravel" означает, что вы не должны работать с табличками в своей базе напрямую, подразумевается, что вы должны делать это через ORM. И Laravel дает вам кучу своих правил, как это делать.

Эти правила очень сильно ограничивают вам множество вариантов, как может выглядеть структура вашего приложения, но, при этом, не ограничивают вас в в том, что будет делать ваше приложение (т.е. "функциональные требования"). И, таким образом, упрощают вам проектирование системы:


  • Искать решение в меньшем множестве вариантов - проще и быстрее, естественно, при наличии навыка работы с данными правилами.

  • Много людей могут проектировать в рамках этих правил, и более-менее легко понимать решения друг друга.

  • Вам не придется ломать голову о решении множества мелких технических проблем - пока вы остаетесь в рамках правил, это все делается за вас.

    Это все замечательно, но, конечно, не бесплатно. Правила могут ограничивать производительность, что может стать проблемой. Ну и в конце концов, правила соблюдают люди. А им соблюдать правила не всегда легко, и далеко не в каждом случае их соблюдение приносит пользу. Иногда правила настолько сложны, что инженеры их не понимают. А как можно соблюдать то, что не понимаешь?


Вообще, чтобы архитектура была архитектурой, а не фантазией, легко опровергаемой заглядыванием в код, необходимо всегда помнить, что эти правила выполняют люди. Поэтому, если вы хотите чтобы люди их соблюдали:


  • Про правила проектирования должны все в команде знать. Нет ни малейшего шанса следовать неизвестным правилам. То есть, если у вас в ящике стола лежит секретная диаграмма, про которую никто кроме вас не знает - это не архитектура. Что бы там не было написано.

  • Все должны их понимать и помнить. Люди в принципе не в состоянии следовать тому, что они не поняли. То есть, правила должны быть очень простыми, и их не должно быть много. Это значит, что если ваши правила хоть чуть-чуть напоминают правила игры в "драконий покер" - они являются архитектурой только в вашем воображении, все все равно будут делать по другому.

  • Соблюдение правил не должно сильно усложнять жизнь. Люди, надо отметить, и так-то не сильно любят соблюдать правила. Надо напоминать, как они поступают с правилами, требующими для соблюдения нечеловеческих усилий?

  • Правила должны помогать. Выгода от следования правилам должна превышать затраты на их соблюдение.

То есть, в идеале, правила должны быть идеальными. Про них все знают, они настолько просты, что их понимает сходу каждый идиот, следовать им ничего не стоит, а если следовать - то будет сразу ощутимая, видимая не микроскопом польза.

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

Ну так как бы не бывает, ну? - скажете вы. И тут на сцену выходят Фреймворки. Та-да.




Фреймворки дают вам правила проектирования, соблюдение которых, предположительно должно вам помочь. Задача фреймворка - сделать этот процесс проще, приятнее, и понятнее.


За этим мы и используем фреймворки. Они, как правило, задают некий скелет приложения, или его части, или скорее, правила их построения. За это мы их любим. В отличии от библиотек - их мы испольузем чтобы получить какую-то полезную функциональность, и как раз очень не любим, когда они начинают лезть не в свое дело, и диктовать нам какие-либо условия на структуру приложения.

Ну, в жизни, конечно, все немного сложнее. Выбором одного фреймворка дело не заканчивается. Фремворк может касаться какого-то одного архитектурного аспекта - например, только делать ORM. Его одного мало, чтобы сделать архитектуру, то есть, накрыть правилами проектирования все приложение. И кроме того, фреймоворки далеко не одинаковы в причиняемом ими добре - некоторые из них деспотичны, решая за вас совершенно все, а какие-то напротив, достаточно либеральны в плане там разных свобод.

http://stackoverflow.com/questions/802050/what-is-opinionated-software

Софт бывает opinionated, и unopinionated. Эти термины не имеют отношения к тому, какое мнение относительно софтины сложилось в сообществе. Здесь речь идет о "мнении" кусочка софта о том, как вы должны делать разные вещи (ну то есть правила он вам ставит). Библиотека как правило unopinionated. А вот фреймворк, чтобы быть фреймворком, просто обязан иметь какое-то свое мнение.

Короче, все бы хорошо, только количество разных фреймворков для веб-разработки одностраничных приложений давно перевалило за сотню. И каждую неделю появляется новый. Что говорит нам об одном - не смотря ни на что, никто до сих пор тольком не понимает, как правильно их делать. И уж во всяком случае, в сообществе нет на этот счет какого-либо общего мнения.


Comments:


aknost
aknost at 2015-06-27 05:53 (UTC) (Link)
да, общий словарь, как свод договоренностей по общей реальности
especialhifi at 2015-06-27 06:30 (UTC) (Link)
Ух ты, не зря я этот блог до сих пор мониторю. Очередной мощный пост :-)
vtv at 2015-06-27 20:16 (UTC) (Link)

Согласен с предыдущим комментатором. Внезапно и мощно!

alekciy
alekciy at 2015-07-04 07:13 (UTC) (Link)
Поддерживаю. Причем мощь именно в максимально понятности и краткости. От себя замечу, что так просто о сложных вещах лично я читал только у Стивенса в его книге по разработке сетевых приложений которую даже перевод не смог испортить.

Очень надеюсь, что автор пусть и не часто, но будет писать в свой жж.
LiveJournal
livejournal at 2015-06-28 07:56 (UTC) (Link)

LJournalist #2714

Пользователь jenyay сослался на вашу запись в своей записи «LJournalist #2714» в контексте: [...] ьных и неформальных *правил*, руководствуясь которыми люди проектируют систему. С комментариями [...]
LiveJournal
livejournal at 2015-06-28 07:56 (UTC) (Link)

LJournalist #2714

Пользователь jenyay сослался на вашу запись в своей записи «LJournalist #2714» в контексте: [...] | Без комментариев [...]
LiveJournal
livejournal at 2015-06-30 19:47 (UTC) (Link)

Часть 1. Об архитектуре и фреймворках

Пользователь insanegigolo сослался на вашу запись в своей записи «Часть 1. Об архитектуре и фреймворках» в контексте: [...] Оригинал взят у в Часть 1. Об архитектуре и фреймворках [...]
Osteolaemus tetraspis
plumqqz at 2015-06-30 23:01 (UTC) (Link)
Да, как-то так.
Previous Entry  Next Entry