Comments 14
ease deployed / простата в деплоя
Это сильно :)
То, что на некоторых картинках есть слово архитектура, ещё не делает их таковыми. А что выражает график maintainability - я так и не понял. Со временем технический долг упирается в асимптоту или уходит к розовым и голубым?
fault tolerance != reliability, пример scalability тоже довольно своеобразный, remove old code - ужасная формулировка, которая приводит к ошибочным выводам.
Ну и, конечно, весь текст построен на том, что чтобы вы могли сделать архитектуру, кто то другой её уже должен был создать и воплотить.
И самое смешное, что архитектура воплощенная в простой базовой диаграмме, где перечислены только названия модулей и базовые линии их взаимодействия друг с другом, окажется куда понятней и лаконичней, чем всё что изложил "академик" в главе своей "методички" выше.
Одно "архитектор" выше не написал: что архитектура уже следствие рефакторинга результата мозгового штурма по реализации базового функционала и элементов важных функциональных компонентов, из которых как из кирпичиков складывается программа.
Одним словом: В современное время очень сожалеешь, что редакторы Хабра не предусмотрели разделения анонсов постов в личных блогах, общественных блогах и корпоративных блогах, погрязших в самопиаре и накидывание модных трендов на вентилятор.
Архитектура не может быть лаконичной, но может быть излишней и избыточной. Именно по этому нет одной самодостаточной нотации. В сложной системе нужен целый свод диаграмм, таблиц, политик и набора инструментов для мониторинга. И это будет развиваться и дополнятся в течении жизненного цикла продукта.
Для чего то маленького может быть достаточно просто диаграммы классов или схемы данных. Но это вряд ли архитектура, хотя это явно документы проектирования.
В зависимости от проекта и команды, можно давать больше свободы и меньше проектировать. А в чём то крупном нужен хороший скелет.
Архитектура не может быть лаконичной, но может быть излишней и избыточной.
DirectX, протокол USB, OpenGL с вами сильно поспорят.
Умные люди целые книги о них написали, так что ещё и все ваши весёлые заявления идут лесом.
В зависимости от проекта и команды, можно давать больше свободы и меньше проектировать. А в чём то крупном нужен хороший скелет.
Сразу напрашивается мораль из статьи "Теперь я не могу сделать даже маленький сайт":
Похоже, я слишком много думаю наперёд.
Чувак испорчен хандженством вот таких коллег, которые ему вечно указывали как ему делать свою работу.
...давайте разберемся, а зачем она собственно то нужна? И на самом деле ответ довольно простой и легко изобразить на следующей картинке...
Далее следует картинка о том, что технический долг накапливается со временем.
Так все же, зачем она (архитектура) нужна?
Может с какого либо и начать надо?
Статья сырая и требует доработки в содержании и изложении. Поэтому пост ушёл в минус. Чего я не пойму, так это зачем молчаливо сливать автору карму? Дайте критику и шанс исправить, а не просто блокируйте.
Спасибо за комментарий. Статья не просто так называется для чайников. Я много раз видел как архитектуры разрабатывали с наскока и нафигарив просто популярные технологии, по этому и сделал доклад и потом написал цикл статей. Не удивительно что профи заминусавали. Но есть и люди которые добавили статью в закладки, так что она кому то в будущем возможно сильно поможет)
Я много раз видел как архитектуры разрабатывали с наскока и нафигарив просто популярные технологии, по этому и сделал доклад и потом написал цикл статей.
Знаете, вы в этой статье глупость ещё большую сделали, когда накидали с наскока популярных мифов и заблуждений, и мало того, что сами в теме не разобрались, так ещё только запутали окружающих.
То что вас заминусили - это меньшее, что они могли сделать.
Я вам по личному опыту скажу, что на Хабре поэтому и популярны личные и общественные блоги, где люди ставят конкретную цель, и рассказывают какими путями они её добивались. И тут ваш корпоративный пиар на фоне дефицита рекомендаций технической литературы вообще никаким клином не вбился.
В случае архитектуры - это всё рождается в творческом процессе, где желание сохранить структурную целостность и общесистемную логику будет выше желаний менеджеров "мне нужно сдать прототип через неделю и никак иначе".
Ну данная статья и правда не про то, естественно я решал конкретные задачи при разработке архитектуры, но данная статья скорее общая вводная что делать, если вам упала задача разработать новую архитектуру и через какие этапы нужно пройти. С одной стороны печально что статью заминировали, а с другой вижу что люди добавляют в закладки и пишут в личку благодарности, так что кому та статья помогла.
В целом могу написать и хардкорную статью, где можно разобрать именно проблемы построения микросервисов, их масштабирования, и как сделать так, что бы они не мешали друг другу. Но как по мне таких статей уже довольно много, а вот общей вводной нету. как и написано в названии, она для чайников ))
Но что меня поразило это "корпоративный пиар". Я же даже нигде названия компании не указывал ))) пиар явно божественный получился)
нет, таких людей нет, зачем добавлять в закладки малосвязный текст неофита, когда есть гораздо более лаконичные и нагруженные смыслом статьи
Я бы посоветовал после невнятной кучи примеров "архитектур" выбрать какую-то одну, расписать её компоненты, указать, на что обращать внимание при чтении/разработке архитектурного плана. Повторюсь, на примере КОНКРЕТНОЙ архитектуры. Затем уже общие черты расписать. Вдовесок можно рассказать про разные нотации для описания архитектур.
Отдельный вопрос: зачем схему данных в примеры архитектуры сунули?
Разработка архитектуры для чайников. Часть 1