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

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

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

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

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

#Шаблоны

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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