Comments 14
Самая главная книга для начинающего архитектора и вообще IT-специалиста - "Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте" Эдвард Йордан.
Самое удивительное то, что выросло поколение которое повторяет все ошибки описанные и разобранные лет 30 назад. История сделала поворот по спирали.
Всё повторяется - вплоть до прямых цитат : "а на тестовом стенде у нас все работало быстро ".
СУБД — фундамент любой системы, поэтому: Владимир Комаров, «Путеводитель по базам данных»
К сожалению , современное поколение разработчиков воспринимает СУБД как хранилище данных. Как работает СУБД они не знают и знать не хотят - "зачем вы используете pg_adviser_lock? У нас Фреймворк такой."
Это не исключение это правило. В ходе решения поставленной задачи по импортозамещению и миграции решений с Oracle на PostgreSQL над особенностями и отличием СУБД они не задумываются , берут Фреймворк и ORM и потом классическое "мы уперлись в СУБД".
Они все такие, решение предоставляются разными подрядчиками , и разными командами разработки . Пока , я не встретил ни одного разработчика прошедшего хотя бы DBA-1. Может, это мне не везет, а может это современный тренд такой .
Итог всегда один - перевод в промышленную эксплуатацию , аварийная ситуация , ответ разработчиков "мы не понимаем, что происходит". Это не гипербола , это прямая цитата с конфколла по ходу решения аварийной ситуации.
Иногда доходит до смешного - подрядчик-поставшик решения объясняет вендору СУБД , что СУБД работает неправильно - "а вот в Oracle блокировки обрабатываются по другому и на старой системе все работало". Это было на самом деле, я лично это слышал.
"У нас проблема с СУБД , очень много ожиданий Client read." - это не шутка это мнение руководителя группы разработки. Пришлось собрать нервы в кулак и очень аккуратно , максимально толерантно объяснять и открывать глаза на картину мира и цитировать RTFM. В свое рабочее время и совершенно бесплатно .
Увы, увы. Микросервисы да паттерны.
Про микросервисы был забавный случай - руководитель разработки гордо рапортует -"мы перевели архитектуру с монолита на микросервисы". Странно , но почему то со стороны СУБД никаких изменений не выполнялось.
Выяснилось они считают отдельным микросервисом - отдельную БД в кластере PostgreSQL.
Какой смысл и выгода от использования отдельной БД в кластере взамен отдельной схемы в одной БД - я пока не понял, хотя особенно данную тему и не копал. Возможно , выгода есть.
А как еще воспринимать субд? Как графический движок, или веб-сервер?
Если разработчик (абсолютно корректно) воспринимает базу данных как... базу данных, это не значит, что он не знает как она работает. Я же, как архитектор, если вижу необходимость в продвинутых дба-скиллах для конкретного проекта, буду просить разрабов с продвинутыми дба-скиллами, либо вообще дедикейтед дба. Но правда в том, что далеко не всегда они нужны. Если вы используете для выполнения задач разрабов с неподходящим набором и уровнем скилов, то скорее всего это не его проблема. Вы ж его наняли для этой работы, как-то тестировали...
Основная идея микросервисов: логическое разделение доменной области и бизнес-логики для создания слабо связанной системы. Пока перед продом не стала реальная задача по отказоустойчивости и масштабированию, вполне допустимо все базы в один кластер сунуть, это ничуть не обесценит архитектуру. Но будет дешевле, что есть козырным аргументом для бизнеса. При необходимости девопс легким движением руки разнесет базы физически, это не потребует глобального рефакторинга. А необходимость может появиться через время после запуска.
Я думаю тут вопрос больше не в том, чтобы уметь делать, а в том, чтобы знать, что так можно сделать.
Не "как правильно управлять локами в многопоточной среде", а "локи существуют".
Как разработчик, я не всегда (практически никогда) не могу повлиять на компетенции людей, с которыми приходится работать. Поэтому естественно что мне хочется, чтобы они хотя-бы знали, когда они могут позвать на помощь.
От бестолковых коллег, да и в принципе от широкого спектра самых разных человеческих ошибок и косяков (после которых люди еще имеют наглость упрекать ии в галлюцинациях...) никто не застрахован. И иногда действительно какие-то качества мешают человеку выявить (или признать) свою некомпетентность в чем-то и вовремя попросить совета-помощи. Ничего не попишешь. Для минимизации вреда и контроля подобного рода ошибок существует культура разработки, со всеми этими код ревью, дейликами и тех. лидами. Но серебряной пули нету, увы.
Гладко было на бумаге, да забыли про овраги.
В статье перечисляются виды архитекторов, потом даются книги для ИТ-архитектора, которого нет в этих видах.
Затем даются паттерны разработки чведь архитектору надо о них знать". А как насчёт уровней солюшн, корпоративного, неужели нет книг, и достаточно выучить паттерны и работать? Сомнительно, но нет.
Как то так
Порекомендую Team Topologies чтобы понимать откуда ноги растут или почему отличная архитектура встречает сопротивление в организации.
По промокоду IDKFA в Строках эти книги можно прочитать бесплатно
А по коду IDDQD - скачать бесплатно без смс (шутка :)
Вот программист, например, выучил C++, но новаторских изменений в нем намного меньше, чем подходов разработки паттернов, фреймворков, технологий и так далее.
Фраза "выучил C++", подозреваю, относится к не очень большому проценту программистов на нем.
Сравнение количества новаторских изменений в языке с количеством подходов (далее по тексту), имхо, не совсем корректно. И вообще непонятно, что с чем сравнивается. Можно, например, сравнить количество новаторских изменений в C++23 по сравнению с C++98.
"42" - ответ на главный вопрос жизни, вселенной и всего такого.
С него и начинайте...
стандарты
GERAM
Библиография стандарта
[1] ENV 12204:1996 Перспективные производственные технологии. Системная архитектура. Конструкции для моделирования предприятия (Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling)
[2] ENV 40003:1990 Компьютеризированное интегрированное производство. Системная архитектура. Среда для моделирования предприятия (Computer integrated manufacturing - Systems architecture - Framework for enterprise modeling)
[3] ISO/TR 10314-1:1990 Промышленная автоматизация. Цеховое производство. Часть 1. Эталонная модель для стандартизации и методологии для идентификации требований (Industrial automation - Shop floor production - Part 1: Reference model for standardization and a methodology for identification of requirements)
[4] ISO 14258:1998 Промышленные автоматизированные системы. Концепции и правила для моделей предприятий (Industrial automation systems - Concepts and rules for enterprise models)
[5] ISO/IEC 15288:2002 Системная инженерия. Процессы жизненного цикла систем (Systems engineering - System life cycle processes)
[6] ISO/IEC TR 15504-2:1998 Информационная технология. Оценка программного процесса. Часть 2. Эталонная модель для процессов и возможности процесса (Information technology - Software process assessment - Part 2: A reference model for processes and process capability)
[7] ISO/IEC 15414:2002 Информационная технология. Открытая распределенная обработка. Эталонная модель. Язык предприятия (Information technology - Open distributed processing - Reference model-Enterprise language)
[8] ISO 15531-1:2004 Промышленные автоматизированные системы и интеграция. Управляющие данные о промышленном производстве. Часть 1. Общий обзор (Industrial automation systems and integration - Industrial manufacturing management data - Part 1: General overview)
[9] AMICE, CIMOSA Открытая системная архитектура для компьютеризированного интегрированного производства (Open System Architecture for CIM. 2nd edn. Berlin: Springer-Verlag. ISBN 0 387 56256 7, 1993)
[10] Bernus, P. and Nemes, L Вклад GERAM в консенсус в области интеграции предприятий (The Contribution of GERAM to Consensus in the Area of Enterprise Integration, in Kosanke and Nell, pp. 175-189, 1997)
[11] Bernus, P., et al. eds. Архитектура интеграции предприятий (Architectures for Enterprise Integration. Chapman and Hall, London ISBN 0412 731401, 1996)
[12] Cheim, D. and Doumeingts, G. Эталонная модель GRAI-GIM, архитектура и методология (The GRAI-GIM reference model, architecture and methodology, in Bernus, P., et al., eds., Architectures for Enterprise Integration, Chapman and Hall, London ISBN 0412 73140 1, 1996)
[13] CIMOSA ASSOCIATION, CIMOSA - Открытая системная архитектура для компьютеризированного интегрированного производства (Open System Architecture for CIM: Technical Baseline, Version 3.2, 1963)
[14] Doumeingts, G., Vallespir, B. and Chen, D., Сетка GRAI моделирования решений (Decision modelling GRAI grid, in Bernus, P., Mertins, K. and Schmidt, G., eds. Handbook on architecture for Information Systems, Berlin, Springer-Verlag, 1998)
[15] Kosanke, K. and Nell, J.G. Стандартизация в ИСО для инжиниринга предприятий и интеграции (Standardization in ISO for enterprise engineering and integration, in Computers in Industry, 40 (1999), pp.311-319, Elsevier Science B.V., Amsterdam, 1999)
[16] Kosanke, K. and Nell, J.G., eds., Инжиниринг предприятий и интеграция: нахождение консенсуса на международном уровне (Enterprise Engineering and Integration: Building International Consensus. In: Proceedings of ICEIMT 97, Research Reports Esprit, Berlin, Springer-Verlag, ISBN 3 540 63402 9, 1997)
[17] Kosanke, K., Vernadat, F.B. and Zelm, M., CIMOSA: Эволюция и приложения в сфере инжиниринга предприятий и интеграции (Evolution and Applications in Enterprise Engineering and Integration. Computers in Industry, Elsevier, 1999, vol.40, No.2-3)
[18] Ortiz, A., Lario, F. and Ros, L, Интеграция предприятий - Интеграционный менеджмент бизнес-процессов (Enterprise Integration - Business Process Integrated Management, in Kosanke, K., Vernadat, F.B. and Zelm, M., 1999, pp.311-319)
[19] Petrie, C.J., Jr., ed. Моделирование интеграции предприятий. Тезисы 1-й международной конференции ICEIMT 92 (Enterprise Integration Modelling. Proceedings of the 1st International Conference. MIT Press, Cambridge, MA, ISBN 0 262 66080 6, 1992)
[20] Scheer, A.-W., Инжиниринг бизнес-процессов - Эталонная модель промышленных предприятий (Business Process Engineering - Reference Models for Industrial Enterprises, Berlin, Springer-Verlag, 1994)
[21] Scheer, A.-W, ARIS - Среда бизнес-процессов (Business Process Frameworks. 2nd edn., Berlin, Springer-Verlag. ISBN 3 540 65813, 1999)
[22] Sowa, J.F. and Zachman, J.A., Extending and formalizing the framework for information systems architecture, IBM Systems Journal, 1992, vol.31, No.3 4
[23] Vernadat, F.B., Моделирование предприятий и интеграция - Принципы и приложения (Enterprise Modelling and Integration - Principles and Applications, Chapman and Hall, London, ISBN 0 412 60550 3, 1996)
[24] Williams, T.J., Rathwell, G.A. and Li Hong, eds. Руководство по планированию и применению программ интеграции предприятий (A Handbook on Master Planning and Implementation for Enterprise Integration Programmes. Report 160, Purdue Laboratory for Applied Industrial Control, Purdue University, W. Lafayette, IN, 1996)
Книги в переводе теряют смысл
5 книг, которые стоит почитать начинающему ИТ-архитектору