Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
За опечатки в личку — всем спасибо!
Имхо ваша дилемма решается вводом метрик (kpi). Красивый код пишется ведь не из-за эстетической причины (если мы говорим про бизнес), а из-за того, что приложение будет дешевле в поддержке. При внедренной методологии разработки, сборе метрик и некотором опыте вы сможете прикинуть стоимость решения используя разные подходы. Собственно это и даст руководящему составу обоснование выбора того или иного пути. А что думают конечные разработчики, если честно не важно, главное, чтоб им работалось комфортно, закрывались необходимые потребности, в общем. чтоб были удовлетворены и счастливы :)
Так вроде статья же о том, что красивый код не имеет ничего общего с ускорением решения, если под капотом хорошая архитектура. Т.е. можно наговнокодить запилить с нуля прототип модуля X, он удобно встроится в существующем окружении и будет себе работать, пока нужен. А что внутри, пофиг. Главное — что он был встроен быстро. А еще главное — что также быстро может быть выпилен из системы. А красивый код нужен скорее в монолите — когда чем лучше код, тем меньше жди от него неприятностей, т.к. все со всем связано.
P.S. Я тоже люблю красивый код.
P.S. Я тоже люблю красивый код.
я всегда думал, что красивый код это и есть хорошая архитектура, как в глобальных так и в микро-масштабах
Имхо, архитектура — это про декомпозицию и взаимодействие. Не важно на каком уровне. И на уровне одного модуля/сервиса/приложения — это "хороший код" (паттерны там всякие). А когда речь идет о комплексном многоуровневом проекте — архитектура уже далека от кода, она оперирует подсистемами (их интерфейсами и порядком взаимодействия). И в случае, если последняя хороша, то чистотой кода в ее компонентах иногда можно пренебречь в угоду скорости разработки.
Суть архитектуры — разделять код. модуль от модуля, сервис от сервиса. Хороший код, от времянок и говнокода. Тогда архитектура помогает разрабатывать.
По поводу масштабов — вопрос размера решения. Если оно маленькое — архитектура работает на уровне модулей. Если большое — на уровне сервисов.
Т.е. не нужно делать ее многоуровневой. Какие могут быть модули в сервисе? никаких — он одну фичу делает. одну функцию. Как может быть архитектура внутри модуля в монолите? тоже никакой.
Вложенные модули в модули и прочее — адское зло и в целом противоречит идеям композии, переиспользования. А в целом — еще и порождает массовые зависимости между модулями. Чего в хорошей архитектуре быть вообще не должно.
По поводу масштабов — вопрос размера решения. Если оно маленькое — архитектура работает на уровне модулей. Если большое — на уровне сервисов.
Т.е. не нужно делать ее многоуровневой. Какие могут быть модули в сервисе? никаких — он одну фичу делает. одну функцию. Как может быть архитектура внутри модуля в монолите? тоже никакой.
Вложенные модули в модули и прочее — адское зло и в целом противоречит идеям композии, переиспользования. А в целом — еще и порождает массовые зависимости между модулями. Чего в хорошей архитектуре быть вообще не должно.
Не только в монолите — он нужен там где его реально будут менять. т.е. пусть у вас модуль или сервис который постоянно переписывается — он должен быть "красив", прост и понятен. Верстка та же, стили и прочее — оно постоянно меняется. там должен быть порядок.
А вот из каких тряпок и грязи собрали модуль отправки писем — не важно, главное что отправлял в соответствии с ТЗ. Если он верно написан — шаблонов писем в нем не будет. И менять там впринципе нечего — почта она вон 40 лет не меняется.
А вот из каких тряпок и грязи собрали модуль отправки писем — не важно, главное что отправлял в соответствии с ТЗ. Если он верно написан — шаблонов писем в нем не будет. И менять там впринципе нечего — почта она вон 40 лет не меняется.
Чтобы в него по 10 лет не залазить он изначально должен быть написан добротно.
Да, если потом поменялись стили, подходы и определеный АПИ, то можно только обертку поменять не заглядывая во внутрянку, пока пхп7 не отменит конструкторы пхп4стайл. Но изначально он должен быть красивым.
Иначе у нас и иньекций будет, и первое же расширение протокола всё сломает что не успело сломаться после того как добавили четыре атача одновременно и т.п.
Да, если потом поменялись стили, подходы и определеный АПИ, то можно только обертку поменять не заглядывая во внутрянку, пока пхп7 не отменит конструкторы пхп4стайл. Но изначально он должен быть красивым.
Иначе у нас и иньекций будет, и первое же расширение протокола всё сломает что не успело сломаться после того как добавили четыре атача одновременно и т.п.
Чтобы в него по 10 лет не залазить он изначально должен быть написан добротно.
Без явных багов и "красивый код" — понятия очень разные и обычно не пересекающиеся
только обертку поменять не заглядывая во внутрянку
Я там на 3 абзаца расписал, что обертку менять вообще не нужно. Плохая архитектура — если ее нужно постоянно менять…
пока пхп7 не отменит конструкторы пхп4стайл
Ну живет отдельный сервис у вас нас php4. Он же жить вам не мешает — пусть живет и дальше. Нужно будет в нем правки делать — и php обновим и говнокод перепишем. Работает — не трож. Тем более можно и не трогать. Трогают обычно от желания поучиться вместо того чтобы поработать.
расширение протокола всё сломает
Ну вот я привел пример почты — протокол 40 лет не меняется. Нормальные люди его сделали. Грамотные в архитектуре. SMTP. Потом появился ESMTP — но он не противоречит старому и целиком и полностью его поддерживает.
Это больше к вопросу выбора решений — не нужно выбирать сырое, что еще много раз поменяется.
Вся проблема заключается в том, что даже в простых приложениях часто невозможно представить одну фичу одним модулем. Предположим, речь идет о такой простой функции, как добавление нового Клиента в какое-нибудь бизнес-приложение. Такая фича потребует создание новой формы, изменений в слое доступа к данным и в базе данных. Возможно, потребуются небольшие изменения и в слое бизнес-логики.
В приведенном примере одна простая фича затронула сразу 3-4 подсистемы. Более сложные фичи в более сложных приложениях могут затронуть большее количество подсистем, и изменения могут оказаться не такими простыми. Так что рекомендация "1 фича = 1 модуль" — это лишь благое, но нежизнеспособное пожелание.
В приведенном примере одна простая фича затронула сразу 3-4 подсистемы. Более сложные фичи в более сложных приложениях могут затронуть большее количество подсистем, и изменения могут оказаться не такими простыми. Так что рекомендация "1 фича = 1 модуль" — это лишь благое, но нежизнеспособное пожелание.
Совсем нет. Вы просто сходу представляете нерасширяему систему (MVC например).
Что такое добавить нового клиента в приложение? Идем с конца: нам нужна сущность клиента, нам нужна возможность его добавить (форма), нам нужны внешние ключи/связи.
Вспоминаем, что база это не то куда надогадить, а мы понимаем ее как "микросервис для хранения данных". Окей.
Итого: 2 задачи, 2 фичи, 2 правки:
Как пускать туда манагеров в этот микросервис? Ну да, у нас же нормальная архитектура и композиция — авторизация у нас централизована по токену.
Как показать все в едином интерфейсе? Ну да, у нас же все по уму — мы ssi используем и proxy_pass. Внешне — все в одном UI, не внешне — хоть в разных ЦОД.
Вы просто начинаете с того, что у вас монолит на MVC — там да, проблема. Но не надо закладываться на то, что "мы сразу с нуля будем делать плохо"
Что такое добавить нового клиента в приложение? Идем с конца: нам нужна сущность клиента, нам нужна возможность его добавить (форма), нам нужны внешние ключи/связи.
Вспоминаем, что база это не то куда надо
Итого: 2 задачи, 2 фичи, 2 правки:
- Добавить таблицу с юзерами в БД (правка в микросервисе "СУБД", CREATE TABLE, CRAETE VIEW)
- Нужен интерфейс (список, форма добавления/редактирования, валидация, само сохранение) — чисто новый микросервис, ничем на прочее не завязанный. На запись в БД имеет права только в свою табличку clients. На чтение — только из готовых VIEW (чтоб связи выбрат — клиент-менеджер, клиент-партнер). VIEW как известно — это интерфейс (читаем wikipedia).
Как пускать туда манагеров в этот микросервис? Ну да, у нас же нормальная архитектура и композиция — авторизация у нас централизована по токену.
Как показать все в едином интерфейсе? Ну да, у нас же все по уму — мы ssi используем и proxy_pass. Внешне — все в одном UI, не внешне — хоть в разных ЦОД.
Вы просто начинаете с того, что у вас монолит на MVC — там да, проблема. Но не надо закладываться на то, что "мы сразу с нуля будем делать плохо"
О том как представить "СУБД как микросервис" можно отдельную статью написать. Но суть простая:
"все" и "кто-то" один — я имею ввиду микросервисы.
- Читать могут все и только из VIEW — сохраняем обратно совместимый интерфейс
- Создавать новые записи может только кто-то один
- Изменять записи может только кто-то один (возможно он же и их создатель — так даже лучше)
- Удалять записи может только кто-то один (возможно он же и создатель, и редактор)
"все" и "кто-то" один — я имею ввиду микросервисы.
А чем вам MVC мешает делать модульно?
Добавление таблиц и т.п. это миграции. Это вообще отдельная песня.
Новая ответственность, новая сущность, новая моделька, отдельный класс, вероятно в отдельной папке отдельного модуля (как настроишь среду). Контроллер для CRUD? Наследуемся от стандартного класса (да, академический контроллер это не контроллер в бытовом понимании а его экшн, но базовый класс под CRUD-контроллер это удобно и практично. Я вообще такие вещи простой строчкой в конфиге предпочитаю делать, без кода). Нужны вьювы для CRUD? Написали вьювы. Всё собственно. Права со сценариями/ролями мы пристроили еще в модельку.
Телодвижений вроде как аж целых четыре — сотворить модельку, сотворить и запустить миграцию, сотворить шаблоны, сотворить контроллер в виде одной строчки. Но по смыслу тоже самое что и в микросервисах — создаем структуру таблицы, пишем бизнеслогику (модель) пишем вьювы. А обвеска везде одинакова по сложности.
Тот же профиль, только в продукт птицефабрики.
Добавление таблиц и т.п. это миграции. Это вообще отдельная песня.
Новая ответственность, новая сущность, новая моделька, отдельный класс, вероятно в отдельной папке отдельного модуля (как настроишь среду). Контроллер для CRUD? Наследуемся от стандартного класса (да, академический контроллер это не контроллер в бытовом понимании а его экшн, но базовый класс под CRUD-контроллер это удобно и практично. Я вообще такие вещи простой строчкой в конфиге предпочитаю делать, без кода). Нужны вьювы для CRUD? Написали вьювы. Всё собственно. Права со сценариями/ролями мы пристроили еще в модельку.
Телодвижений вроде как аж целых четыре — сотворить модельку, сотворить и запустить миграцию, сотворить шаблоны, сотворить контроллер в виде одной строчки. Но по смыслу тоже самое что и в микросервисах — создаем структуру таблицы, пишем бизнеслогику (модель) пишем вьювы. А обвеска везде одинакова по сложности.
Тот же профиль, только в продукт птицефабрики.
Дело не в том, как Вы организуете доступ к базе данных — через микросервис или посредством слоя доступа к данным, а в том, что Вы понимаете под словом фича (feature). Обычно под feature понимают некоторую пользовательскую функцию, т.е. особенность приложения, которая интересна пользователю. Когда приложение рассматривается в виде набора (или дерева) фич, то при этом осуществляется функциональная декомпозиция приложения с точки зрения пользователя. Но эта декомпозиция никак не совпадает со структурной декомпозицией того же самого приложения, которое осуществляет инженер вне зависимости от того, какая архитектура, какие принципы заложены в основе этой технической декомпозиции: будь то разбиение по слоям, микросервисы, MVC и т.д. и т.п.
Взглядов на одно и тоже приложение может быть несколько. И нужно четко понимать различия между этими взглядами, в том числе, различие между взглядом пользователя и взглядом инженера.
Взглядов на одно и тоже приложение может быть несколько. И нужно четко понимать различия между этими взглядами, в том числе, различие между взглядом пользователя и взглядом инженера.
Получается, «серебряная пуля» для развивающихся продуктов, имеющих сложности с программной подсистемой, — это рефакторинг архитектуры?
На первом этапе, выводя продукт на рынок, мы можем не знать о большинстве требований/условий функционирования, мы имеем ограниченный бюджет, компентенции, время, чтобы продумать все как следует => выбираем не самое лучшее архитектурное решение, но позволяющее быстро заработать. Так образуется технический долг…
Тогда:
если продукт пользуется спросом мы можем позволить себе провести рефакторинг архитектуры, избавиться от технического долга и обеспечить развитие на долгие годы
если продукт не пользуется спросом, то технический долг списывается
На первом этапе, выводя продукт на рынок, мы можем не знать о большинстве требований/условий функционирования, мы имеем ограниченный бюджет, компентенции, время, чтобы продумать все как следует => выбираем не самое лучшее архитектурное решение, но позволяющее быстро заработать. Так образуется технический долг…
Тогда:
если продукт пользуется спросом мы можем позволить себе провести рефакторинг архитектуры, избавиться от технического долга и обеспечить развитие на долгие годы
если продукт не пользуется спросом, то технический долг списывается
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Не называйте код словом «Продукт». Об архитектуре