Научиться проектировать архитектуры программного обеспечения (ООАП)

Цель

Научиться уверенно проектировать сложные архитектуры и системы программного обеспечения с помощью систематической постоянной практики. Практика выражается в моделировании разнообразных предметных областей (от простых до сложных, по возрастанию) при помощи UML-диаграмм, и финальной их реализации на каком-либо языке программирования.

Проблема

В наше стремительное время бизнес во всю юзает фреймворки при разработки ПО, оно и понятно - и быстро получается, и разработчиков легче найти/заменить. Разработчикам, в свою очередь, тоже хорошо - низкий порог вхождения в IT-индустрию получается. Вот разработчик клиентской части, к примеру, выучил AngularJS, углубился в детали и тонкости своего конкретного фреймворка. Затем он переключается, допустим, на React.js в силу того, что "тренды" поменялись. Повседневной задачей такого разработчика зачастую становится поддержание некоей огромной кодовой базы определенного продукта, оперативное закрытие "тасок" в джире. Пределом развития такого разработчика становятся компании-"галеры", в которых работает 200+ программистов, разделенных на многочисленные команды по 5-7 человек, работающих по scrum-системе с вечно горящими сроками. Жизнь такого разработчика превращается в день сурка, работе за станком каким-то, хождением по струнке в этих стеклянных многоэтажных офисах и утопанию в корпоративном сумашествии. Далее есть два варианта развития событий: либо человека целиком полгощает такая работа, он оседает в каком-нибудь EPAM на пять лет, дослуживается до сеньора там, берет ипотеку, дорогую машину в кредит, женится, заводит детей, отращивает пузо, притупляется в мышлении, и его все устраивает. Либо второе: он начинает подозревать что-то, осматриваться по сторонам, просыпаться. Он начинает какие-то поиски чего-то, беспокоится, и находит: малоизвестные компании, с небольшим числом сильных программистов, с нетривиальными инженерными задачами, с гораздо большими зарплатами, причем в сразу в иностранной валюте из кармана инвесторов. Команды, в которых люди друг другу становятся друзьями и единомышленниками, где нет рабочего дня с 11 до 21 и тимбилдингами по пятницам, где нет формальностей и корпоративной культуры. Но, к сожалению, понимает, что за плечами у него лишь ковыряния многолетние в десятиэтажных абстракциях, называемых "фреймворки", которые таким компаниям не нужны, потому как они ценят высокую производительность и качество своего продукта. Они создают прекрасные и гибкие архитектурные решения высокой сложности, кодовая база становится прозрачной и чистой, а работа превращается в удовольствие, стимулируя профессиональный рост. Вопрос лишь в том, что ближе душе.

Почему ООП?

Потому что объектно-ориентированный подход является единственным подходом на сегодня, который позволяет управлять невероятно сложными и хаотичными системами. Это проверено десятилетиями на примере мировых корпораций с гигантскими инфраструктурами. ООП и точка.