Gaperton (gaperton) wrote,
Gaperton
gaperton

Categories:

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

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




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


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


  • Мы будем стараться использовать для обозначения нашего понимания термин "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. А вот фреймворк, чтобы быть фреймворком, просто обязан иметь какое-то свое мнение.

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

Tags: html5, javascript, архитектура, фреймворки
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 8 comments