Архитектура ИТ решений. Часть 2. Архитекторы

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III ОПРЕДЕЛЕНИЕ ПОНЯТИЯ АРХИТЕКТОР

Врач может похоронить свою ошибку, архитектор – разве что обсадить стены плющом. Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это? Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня. Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора. ...Далее...

Архитектура ИТ решений. Часть 1. Архитектура предприятия

I ВСТУПЛЕНИЕ

Архитектура распределяет массы и объемы. Вдохновение превращает инертный камень в драму. Ле Корбюзье.
Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы. Такая работа, естественно, требовала привлечения специалиста высокой квалификации. То есть разработчика ПО поименовали именно архитектором, рассчитывая заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их, на свое усмотрение принимать самостоятельные решения и т.п… Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове. ...Далее...

JavaSctipt — заполняем нишу между микросервисами и объектами — «нано-сервисы»

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


И даже иногда хочется чтобы было почти как в Erlang.


Идея создания фреймворка для микросервисов для NodeJs удачно воплощалась не единожды — так у нас как минимум есть Seneca и Studio.js, которые безусловно хороши, но они определяют большие логические единицы. С другой стороны у нас есть обычные объекты, разделяемые в системе посредством Dependency Injection или подобной техники, но они не дают должной четкости границ.


Иногда нужны "нано-сервисы".

Читать дальше →

[Видео] Доклады с митапа iOS-разработчиков Red Hot Chili Apples


Прошлый год закончился регулярной встречей iOS-разработчиков Red Hot Chili Apples. Под катом вы найдете записи докладов об альтернативе VIPER, базовых принципах функционального программирования на iOS, а также о том, как делать качественный проект при ограниченных ресурсах.

Читать дальше →

Как я писал собственную ERP систему, ver. 2.0

Прошлая моя статья вызвала много вопросов и замечаний у читателей. Действительно получилась достаточно скомкана, не описывала всего. Хочу попробовать ещё раз изложить этот кейс, описав его отталкиваясь от вопросов, полученных в комментариях.
Итак, дано: филиал крупной сети ресторанного бизнеса, специализирующейся на доставке заказов на дом. Читать дальше →

Как я писал собственную ERP систему, и что из этого получилось

Некоторое время назад ко мне обратился знакомый, хозяин одного из филиалов крупной сети по доставке суши и пицц. Их нынешняя ERP его вообще не устраивала, так как не было контроля за кухней и доставщиками, а так как кухонь по городу у него 5, то это была серьёзная проблема. Он предложил мне написать под него новую систему. Читать дальше →

Паттерны разработки: MVC vs MVP vs MVVM vs MVI

От переводчика: данная статья является переработкой английской статьи по паттернам разработки. В процессе адаптации на русский немало пришлось изменить. Оригинал




Выбор между различными паттернами разработки, всегда сопровождается рядом споров и дискуссий, а разные взгляды разработчиков на это еще больше усложняют задачу. Существует ли решение этой идеологической проблемы? Давайте поговорим о MVC, MVP, MVVM и MVI прагматично. Давайте ответим на вопросы: “Почему?”, “Как найти консенсус?”


Читать дальше →

Model-View-Presenter — компромисс и универсальный рецепт

image Аббревиатуру MVP можно интерпретировать по разному, но в статье речь пойдет не о спорте. В сети есть большое количество статей по архитектурным паттернам для iOS и Android разработчиков, и по MVP в частности. Иногда паттерн рассматривается в контексте обеих платформ. Кто-то выбирает данный паттерн для улучшения тестируемости своего кода, кто-то использует его в основном для разделения кода представления от модели. Также встречаются решения, которые используют MVP для унифицирования кода платформ, при условии что разработчики в компании владеют данными технологиями. Но общих слов и выводов иногда недостаточно для разработчика-прагматика. При проектировании коммерческих приложений неизбежно возникает множество деталей, которые общая архитектурная концепция не может раскрыть, и нельзя сказать, что есть единственное каноническое решение. В статье я постараюсь описать ситуации, с которыми очень часто сталкиваются мобильные разработчики на реальных проектах, и когда действительно стоит задуматься о переходе на архитектурный паттерн более сложный чем “One UIViewController (Activity) to rule them all”. Или лучше сказать, когда нам это будет выгодно. Далее речь пойдет о компромиссе между временем и сложностью разработки в реалиях “обычных” проектов, которые в основном приходят на оценку и разработку. Читать дальше →...Далее...

[Из песочницы] Проблемы понимания MVC в ASP.NET MVC и не только

Случалось ли вам делать рефакторинг "толстых" контроллеров? Приходилось ли создавать многоэтажные модели представлений? Добавлять в представление данные и переписывать при этом код контроллера? Казалось ли вам, что что-то идёт неправильно?


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

Читать дальше →

ARKit, Flutter, Core ML, анимации и многое другое на MBLTdev 2017



Привет, Хабр! 27 октября состоялась 4-я Международная конференция мобильных разработчиков MBLTdev 2017.

25 спикеров из Google, Uber, Avito, Fyusion, Sharewire, Tinkoff, PSPDFKit, Agoda, Сбербанк и других компаний выступили с докладами о последних трендах мобильной разработки и поделились собственным опытом и практикой. Главными темами конференции стали скорость и поддержка работы приложений, AR-взаимодействия, Core ML, анимации, Audio Unit Extension, организация работы в команде и многое другое. Как это было — читай под катом.
Читать дальше →
  • Новее
  • 1


Последние посты