От Smalltalk до микросервисов

Первой технологией удалённых вызовов, с которой столкнулся я, была CORBA, которую я использовал в своём дипломном проекте. Это была новая волна технологией а-ля RMI/RPC. Суть была в том, что объект необязательно должен быть в адресном пространстве программы, можно использовать реализацию нужного интерфейса, при этом брокер таких сообщений/вызовов прятал за собой то, что этот объект может быть на другом сервере, при этом мы фактически имели абсолютно такую же ссылку на объект и вызывали метод обычным привычным способом.

Очередной хайп-волной была Service-oriented architecture (SOA) и расцвет веб-сервисов SOAP и шин ESB. Точно так же как в CORBA интерфейс для удалённых вызовов описывался с помощью специального языка IDL, для SOAP-сервисов было описание на WSDL. Точно так же был особый компонент, реестр сервисов, где можно было получить ссылку на тот сервис, который непосредственно обработает запрос.

Потом была хайп-волна REST-сервисов. И даже в GraphQL когда добавились мутации, принцип всё тот же, можно удалённо манипулировать бизнес-объектами где-то в сети. Наступила эпоха микросервисов.

Но если чуть абстрагироваться от деталей, это всё тянется с самого Smalltalk и его идеи библиотеки классов, где главное, что тебе нужно сделать — это найти нужный интерфейс, получить ссылку на реализующий его объект класса и послать сообщение.

Абсолютно то же самое и с DI-контейнерами, которые мы используем каждый день: жизненным циклом управляет не программа, а контейнер, нам важно лишь знать, реализация какого интерфейса нам нужна, получить ссылку, дальше работать как с обычным объектом.

Эта музыка будет вечной, потому что регулярно меняют батарейки)

«Ретроспектива» с Программистом-Прагматиком #1

В комментариях можно задать вопросы к эфиру или поделиться проблемами в:
- объектно-ориентированном программировании и проектировании,
- моделировании на UML,
- применении шаблонов проектирования,
- юнит-тестировании,
- декомпозиции/абстракции
и так далее.

Эфир в субботу, 20.04 в 12 МСК, на час-полтора, как пойдёт. Записи этого эфира не будет)

Ритуал

Наш мозг не любит сложность.

Во-первых, из-за объективных ограничений, сколько единиц смысла можно держать в «оперативной памяти».
Проектирование применяется для того, чтобы разложить изначально сложную решаемую задачу или проблему на маленькие взаимосвязанные части, каждой из которых легче оперировать изолированно.

Во-вторых, что не менее важно, из-за высокой «энергозатратности» процесса мышления. Можно сказать, что наш мозг в этом смысле ещё и ленивый. Поэтому любую, даже декомпозированную задачу, он стремится превратить в механическое движение на автомате, где мозг «засыпает».

Бездумная чрезмерная декомпозиция, называемая по-простому «ООП головного мозга» — как раз последствие того, что выполнялось она механически, неосознанно. Потому что так надо. Зачем я рисую эти UML-диаграммы: чтобы что-то объяснить, или потому что так надо? Зачем я на этом звонке: чтобы внести свой вклад, или просто потому что позвали?

То же самое происходит с любой системой, которую мы применяем. Например, agile-рутины. На дейли мозг хочет спать, на ретро он хочет спать, он не хочет никогда напрягаться. И поэтому любые повторяющиеся действия из осознанных превращаются в ритуал.

Потом возвращаешься спустя какое-то время к таким решением, и спрашиваешь себя: «Что у меня в голове было, о чём я думал тогда?» Ты не думал, ты делал не приходя в сознание. И так тоже можно работать годами)

Чтобы мозг не спал, когда пишешь код, рисуешь диаграммы, участвуешь в собрании, важно держать в голове мотивационную часть и цель: зачем вообще мы это делаем? Зачем вообще я этим занимаюсь? Почему мы решили делать именно так? Потеряешь контекст — потеряешь осознанность действий.

#WeekendWisdom от Кента Бека, создателя TDD и XP: цель проектирования ПО в создании кусков и слоёв, которые способен воспринять человеческий разум.

От серийного дейтинга с новыми технологиями к серьёзным отношениям с профессией

Все мы знаем это чувство: скучно делать одну и ту же работу, решать одни и те же рутинные задачи в N+1-й раз. Дофамина там уже нет, ты знаешь, что как делать, и ты знаешь результат. Да, всё получится, но.

Неизбежно от этого однообразия находится отдушина в «смене обстановки»: новый приём/фишечка из статьи или доклада на конференции, новая технология, а потом и новые языки программирования. Успешен на бэке — почему бы не попробовать JS и React. А может апнуть з/п изучив Go?

Всё это похоже на онлайн-дейтинг: найти нового, необычного и непохожего не прошлых партнёра, с интересом изучать его… Чтобы спустя время вернуться к поиску новых мэтчей. Этот дофамин тоже быстро исчерпывается.

Лично для меня проектирование — вот тот самый источник долгого/медленного дофамина. Где ты больше не ищешь новых смыслов, а создаёшь эти смыслы.

Должно быть, альпинистам было бы скучно годами спускаться с одного склона, чтобы просто взобраться на очередной новый. Всё, что, собственно, требуется от очередной трассы, то что в ней привлекает — это сложность. В которую ты закладываешь свои смыслы и свои собственные вызовы.

Действие качественного, медленного дофамина больше не требует бесконечного перебора новых вариантов. Ты борешься со сложностью, наводя порядок в хаосе по своему разумению. Когда ты задаёшь правила, именно это делает тебя сильным, это делает тебя инженером. Так ты сам наполняешь свою профессию смыслом, а твои отношения с ней делаешь приятными и долгосрочными.

Бескомпромиссность архитектурного идеализма

Вчера с коллегами обсуждали книгу Роберта Мартина «Чистая архитектура». И я заметил, что стремление к основательному, базирующемуся на проектировании хорошей архитектуры походу порой порождает идеализм мышления и полярность мнений: есть «плохой» вариант (на собеседованиях кандидаты часто приводят пример «монолита») и «хороший», правильный с расширяемой и масштабируемой чистой архитектурой.

Это нежизнеспособно.

Всему своё время. Особенно в реалиях гибких методологий. Бывают моменты, когда бизнесу важно получить быстрый результат, проверить гипотезу или застолбить нишу. В условиях, когда ещё ничего не понятно, но важна скорость — детальное и идеальное проектирование может сыграть в минус. В пределе мы получим идеально созданную, но бесполезную вещь в себе, которая ещё и обошлась дорогой ценой.

А дело всё во впадении в крайности. Неправильно в жизни, а не на страницах книги, иметь полярные мнения.

Мне понравилась метафора, которую в дискуссии привёл я. Очутившись на необитаемом острове, у вас не возникнет дилеммы между быстрым результатом сейчас и многообещающим идеальным будущим. Сначала вам нужно решить вопрос, что поесть здесь и сейчас. Найти на этом острове какие-нибудь ягоды, фрукты, что-то не требующее даже обработки. Потом — создать условия для термической обработки. Потом — разнообразить рацион. Очень глупо в условиях пустого желудка на необитаемом острове читать лекции о том, как беспилотные тракторы и современные технологии земледелия могут накормить толпу людей при минимальных затратах и с максимальной урожайностью, устойчивостью к вредителям и болезням. У вас ещё нет трактора (работающей системы) и нет толпы людей (пользователей). Так же и с кровом: вы не станете строить небоскрёб, пока не защищены от дождя.

Но шалаш из подручных средств тоже можно сделать по-разному: чтобы дождь и ветер не проникали внутрь, а не разваливающийся от малейшего ветра; чтобы он был расположен неподалёку от того места, где планируете в дальнейшем поставить избушку, а не где бог на душу положит. Искусство проектирования архитектуры — в том, чтобы находить лучшие решения в текущих условиях и с учётом ближайшей перспективы.

Короткие циклы обратной связи

Бизнес-аналитики гарантированно расскажут вам, как сильно первоначальные представления — что пользователя, что их собственные — отличаются от итогового результата. Руководители стартап-проектов подтвердят, как важно активно тестировать гипотезы одну за другой, чтобы от этих самых гипотез перейти к реальным представлениям о выбранной нише.

Ничто не высечено из камня. Мир состоит из уникального сочетания случайностей, поэтому любой проект создаётся [почти] как в первый раз.

Рефакторинг архитектуры — это не переделка в один прекрасный момент (обычно при смене команды), а продолжающийся процесс доработки архитектуры под меняющуюся реальность и/или наши уточняющиеся знания о ней.

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

И суть TDD тоже в сокращении цикла обратной связи о качестве кода.

Это всё тот же синдром Данилы-мастера, если кажется, что можно долго и упорно, тщательно и «правильно» готовиться, а потом выйти и впечатлить всех монументальностью результатов. Писателю — придётся пройти циклы короткой прозы с обратной связью от читателей и критиков. Спортсмену — пройти систему турниров от местечковых до самых крупных. Предпринимателю — череду убыточных и малоуспешных начинаний.

И именно в этом процессе сформируется наиболее верное представление, о том, как всё устроено, и как должно быть.

Подробности в посте ниже ⬇️

Система для системного мышления

Я точно не из тех, кто будет бурчать про «поколение ЕГЭ», падение качества образования, засилье курсов и прочие стариковские установки. Потому что убеждён:

Всё у нас с новыми поколениями разработчиков отлично!

Наша работа — для умных ребят с определённым складом ума, постоянным самосовершенствованием и желанием создавать.

И если я что и могу сделать для этих людей, это помочь пройти путь к более глубокому пониманию профессии, к уверенному достижению результатов, к полному удовлетворению делом, которому мы все отдаём значительную часть времени каждый день.

Я уверен, что системный подход и мышление способны повысить профессиональный уровень junior- и middle-разработчиков, продвинуть их к более интересным проектам и более успешным и качественным результатам.

Есть множество хороших источников типа вузовских программ, курсов, видео и книг, которые дают знания. Моя цель немного в другом. Помимо блога в этом телеграм-канале и видео на Ютубе я придумал консультационный цикл, что-то типа лекций, где все основные принципы, шаблоны и аббревиатуры выстраиваются в одну систему знаний с причинно-следственными связями, логичным объяснением что, зачем и почему — это именно то, что чаще всего не объясняют, превращая всё в догмы.

И конечно, раз я критикую примеры на кошечках-собачках и автомобилях, я хочу также показать, как теория реализуется на реальной практике.

На первой встрече 25-го мая в 12:00 МСК будем говорить про ООП, в частности, разбирать:
— декомпозицию и абстракцию,
— распределение ответственности,
— отношения между классами (а не только наследование),
— связанность и связность (a.k.a. «зацепление»).

Это — первый шаг из 4 в построении такой системы понимания, которая продвинет от «теории плоской земли» в ООП к нормальной такой «модели солнечной системы», где всё на своих местах.

Промокод для своих (больше никому не даю его): CIENTO даёт царскую скидку 40% до 7 мая включительно.

Записаться на лекцию

Как я создал Студенческий центр разработки и собственную методику

В 2010-е я был техлидом аутсорсинговой компании, которую мы с коллегой вырастили от двух (нас самих) до 20 разработчиков. Моя задача была в организации разработки, создании и наборе команды, в управлении проектами.

Очень быстро стало понятно, что кадры с рынка набирать было долго, иногда не по карману, поэтому чаще всего приходилось «подтягивать» ребят до необходимого уровня, а глобально — научиться эффективно и результативно работать с теми, кто есть на рынке, кого можем себе позволить. Сначала у работал с новыми членами команды индивидуально, прокачивая каждого по индивидуальным планам.

Потом возникла идея, что можно делать это работая со студентами старших курсов в группах. В те времена в вузах уже развились учебные центры крупных компаний от Эпама до 1С. Это были учебные центры с полноценными программами подготовки, скажем, Java-программистов, или дотнет, т.е. сильно «вширь». В других центрах были и варианты подготовки узких специалистов под конкретные задачи компаний, т.е. узко, но «вглубь».

По имеющимся ресурсам и в сочетании с нашими потребностями, нам не совсем подходило ни то, ни другое. Мне нужны были разработчики с инженерным мышлением, пусть не сильно опытные или вообще без опыта. Но имеющие прочную базу, позволяющую легко развиваться при работе над задачами проектов. Так я создал свою собственную методику: дать не абстрактные знания о технологиях, как обычно делают при обучении (вот есть такое, сякое, это, а ещё, смотри, и вот это есть!), а заложить основы системы, на которую потом легко и понятно ложатся дальнейшие знания и опыт. Моя цель всегда была в том, чтобы разработчику было понятно то, что и зачем он делает, с самого начала карьеры джуниора и далее.

Весь мой опыт показывает, что это всегда работает просто отлично: в моих командах большинство разработчиков растут очень быстро и довольно самостоятельны. С тех пор и моё понимание, что и в какой момент важно объяснить, выкристаллизовалось.

Я собираю на основе своей методики свежий актуальный цикл из 4 лекций с, который закладывает такую систему мышления, чтобы объектно-ориентированный анализ, проектирование и программирование были понятным и интересным процессом, а не сумбуром и рутиной. Запись на первую лекцию продолжается. Вопросы — пишите в каментах, я помогу определиться, подходит ли вам этот материал, и какую ценность он сможет вам дать.

Как можно применить на практике шаблон Interpreter

#ВопросПодписчика

Ярослав задал в комментариях интересный вопрос про шаблон проектирования Интерпретатор, где можно применить его в реальных проектах. Не самый частый шаблон, согласен.

Если исключить историю с полноценными DSL, навскидку припомнил 2 случая. Первый был вдохновлён утилитой artisan от Laravel. Это было веб-приложение, но которое при этом при передаче определённых команд работало как консольное и выполняло сервисные функции с более естественным синтаксисом, чем традиционные для консольных утилит ключи.

Второе применение как раз довольно типичное. Если поисковая строка на форме может работать в продвинутом режиме с поддержкой какого-то языка запросов (как в примере на скрине ниже), код будет куда чище и понятнее с шаблоном, чем с вереницей split-for-if-ов. Важно: если оно того стоит, конечно.

#Шаблоны

Не войти в айти

Кибернетике как науке ~80 лет. Изначально и первые лет 40 те, кто сейчас называется программистами, были выходцами из математики. Можно сказать, это было специальным разделом математики по работе с данными и информацией. Тогда ученые пошли по ошибочному пути, и вместо генерации мемов с котиками (или на худой конец «репродукции Джоконды» как в фильме «Служебный роман») решали задачи промышленности. Построение самого быстрого маршрута в автомобильном навигаторе с учётом пробок или же выбор роботом-упаковщиком в Амазоне оптимальной коробки для упаковки товара — это всё задачи, решённые в середине прошлого века. Если образно, инженер в исполнении Антона Лапенко — так я себе представляю по своим университетским преподавателям тех самых математиков-кибернетиков.
* * *
В 1980-е/1990-е появились и стали массово распространяться персональные компьютеры для офиса и домашнего использования. Появилась целая индустрия производства программного обеспечения, она и развивалась как самостоятельная новая индустрия с математическими корнями. Появлялись языки программирования новых поколений, которые позволяли разрабатывать ПО быстрее и качественнее, формировались методологии (технологические процессы). Но в данном случае для нас важно, что появился спрос на автоматизацию всего на свете и, как следствие, увеличение количества обучающихся профессии в вузах. Я причисляю себя к этому второму поколению программистов. У меня специализированное высшее техническое образование: я изучал и математику, и кибернетику, и промышленную разработку ПО.
* * *
В 2010-е масштабы автоматизации ещё увеличились с широким распространением смартфонов и так называемого Веб 2.0. Все пришли в интернет и стали потреблять цифровые услуги через интернет. Как вы понимаете, снова увеличился и спрос на ещё большее количество программистов. В индустрию нужно было привлекать массово рабочие руки, и туда пришли уже не как в науку-математику или увлечение компьютерными науками, а, по выражению моего друга, за «гигантскими айтишными зарплатами». Появился новый способ «войти в айти» через стажировки в учебных центрах айти-компаний и обучение на онлайн-курсах.
* * *
Как вы наверняка слышали, сейчас идут массовые сокращения в крупных компаниях за счёт внедрения ИИ. На мой взгляд пока что это больше оптимизация неэффективного раздутого штата этих самых крупных компаний. Но дальше будет круче. Это завершение периода, когда экономически эффективно было «закрывать позиции» привлечением почти любого, кто худо-бедно способен решать задачи. Надежды возлагаются на ИИ-агентов, которые «худо-бедно» решат типовые задачи и без толпы программистов, только сформулируй задачу грамотно. Про это отдельно напишу.
Вместе с этим всё больше статей пишут о том, что дабы оставаться в обойме, в профессии и как минимум в прежнем уровне дохода, придётся гораздо больше работать, приносить больше ценности работодателю. Как лайфхак появился микро-тренд на монетизацию знаний: для дополнительного источника дохода можно делиться знаниями. Те, кто учат учить, любят использовать факт сокращения спроса у работодателей и при этом потребности в сохранении прежнего уровня дохода у программистов как аргумент, что поезд почти уходит, надо успевать учить и монетизировать навык. По-моему, тот поезд ушёл в 2010-х, как я описал выше в своём историческом экскурсе. Если и будет востребовано обучение и консультирование в айти, то скорее обучение робота, и то, если это какой-то не очень распространённый навык. Ни обучение людей айти, ни даже обучение роботов, кроме нескольких крупных олигополий, не может быть бизнесом с горизонтом в 10 лет, а разве что предприимчивым краткосрочным проектом.

История сделала круг, и вхождение в айти-профессию снова обретает высокий порог специализированных или даже околонаучных знаний.