Полиморфизм это…
Anonymous Quiz
95%
Один из основоположных принципов и столпов ООП
5%
Шаблон проектирования
Бескомпромиссность архитектурного идеализма
Вчера с коллегами обсуждали книгу Роберта Мартина «Чистая архитектура». И я заметил, что стремление к основательному, базирующемуся на проектировании хорошей архитектуры походу порой порождает идеализм мышления и полярность мнений: есть «плохой» вариант (на собеседованиях кандидаты часто приводят пример «монолита») и «хороший», правильный с расширяемой и масштабируемой чистой архитектурой.
Это нежизнеспособно.
Всему своё время. Особенно в реалиях гибких методологий. Бывают моменты, когда бизнесу важно получить быстрый результат, проверить гипотезу или застолбить нишу. В условиях, когда ещё ничего не понятно, но важна скорость — детальное и идеальное проектирование может сыграть в минус. В пределе мы получим идеально созданную, но бесполезную вещь в себе, которая ещё и обошлась дорогой ценой.
А дело всё во впадении в крайности. Неправильно в жизни, а не на страницах книги, иметь полярные мнения.
Мне понравилась метафора, которую в дискуссии привёл я. Очутившись на необитаемом острове, у вас не возникнет дилеммы между быстрым результатом сейчас и многообещающим идеальным будущим. Сначала вам нужно решить вопрос, что поесть здесь и сейчас. Найти на этом острове какие-нибудь ягоды, фрукты, что-то не требующее даже обработки. Потом — создать условия для термической обработки. Потом — разнообразить рацион. Очень глупо в условиях пустого желудка на необитаемом острове читать лекции о том, как беспилотные тракторы и современные технологии земледелия могут накормить толпу людей при минимальных затратах и с максимальной урожайностью, устойчивостью к вредителям и болезням. У вас ещё нет трактора (работающей системы) и нет толпы людей (пользователей). Так же и с кровом: вы не станете строить небоскрёб, пока не защищены от дождя.
Но шалаш из подручных средств тоже можно сделать по-разному: чтобы дождь и ветер не проникали внутрь, а не разваливающийся от малейшего ветра; чтобы он был расположен неподалёку от того места, где планируете в дальнейшем поставить избушку, а не где бог на душу положит. Искусство проектирования архитектуры — в том, чтобы находить лучшие решения в текущих условиях и с учётом ближайшей перспективы.
Вчера с коллегами обсуждали книгу Роберта Мартина «Чистая архитектура». И я заметил, что стремление к основательному, базирующемуся на проектировании хорошей архитектуры походу порой порождает идеализм мышления и полярность мнений: есть «плохой» вариант (на собеседованиях кандидаты часто приводят пример «монолита») и «хороший», правильный с расширяемой и масштабируемой чистой архитектурой.
Это нежизнеспособно.
Всему своё время. Особенно в реалиях гибких методологий. Бывают моменты, когда бизнесу важно получить быстрый результат, проверить гипотезу или застолбить нишу. В условиях, когда ещё ничего не понятно, но важна скорость — детальное и идеальное проектирование может сыграть в минус. В пределе мы получим идеально созданную, но бесполезную вещь в себе, которая ещё и обошлась дорогой ценой.
А дело всё во впадении в крайности. Неправильно в жизни, а не на страницах книги, иметь полярные мнения.
Мне понравилась метафора, которую в дискуссии привёл я. Очутившись на необитаемом острове, у вас не возникнет дилеммы между быстрым результатом сейчас и многообещающим идеальным будущим. Сначала вам нужно решить вопрос, что поесть здесь и сейчас. Найти на этом острове какие-нибудь ягоды, фрукты, что-то не требующее даже обработки. Потом — создать условия для термической обработки. Потом — разнообразить рацион. Очень глупо в условиях пустого желудка на необитаемом острове читать лекции о том, как беспилотные тракторы и современные технологии земледелия могут накормить толпу людей при минимальных затратах и с максимальной урожайностью, устойчивостью к вредителям и болезням. У вас ещё нет трактора (работающей системы) и нет толпы людей (пользователей). Так же и с кровом: вы не станете строить небоскрёб, пока не защищены от дождя.
Но шалаш из подручных средств тоже можно сделать по-разному: чтобы дождь и ветер не проникали внутрь, а не разваливающийся от малейшего ветра; чтобы он был расположен неподалёку от того места, где планируете в дальнейшем поставить избушку, а не где бог на душу положит. Искусство проектирования архитектуры — в том, чтобы находить лучшие решения в текущих условиях и с учётом ближайшей перспективы.
👍3🔥1
Короткие циклы обратной связи
Бизнес-аналитики гарантированно расскажут вам, как сильно первоначальные представления — что пользователя, что их собственные — отличаются от итогового результата. Руководители стартап-проектов подтвердят, как важно активно тестировать гипотезы одну за другой, чтобы от этих самых гипотез перейти к реальным представлениям о выбранной нише.
Ничто не высечено из камня. Мир состоит из уникального сочетания случайностей, поэтому любой проект создаётся [почти] как в первый раз.
Рефакторинг архитектуры — это не переделка в один прекрасный момент (обычно при смене команды), а продолжающийся процесс доработки архитектуры под меняющуюся реальность и/или наши уточняющиеся знания о ней.
Никогда нельзя ориентироваться на справочные данные о производительности используемых продуктов, на теоретические выкладки о быстродействии и надёжности, какими бы академичными они ни были. Даже прототип важно подвергать нагрузочному тестированию, и только в той среде, которая сформирована именно на этом проекте. Никакой прошлый опыт не валиден до конца.
И суть TDD тоже в сокращении цикла обратной связи о качестве кода.
Это всё тот же синдром Данилы-мастера, если кажется, что можно долго и упорно, тщательно и «правильно» готовиться, а потом выйти и впечатлить всех монументальностью результатов. Писателю — придётся пройти циклы короткой прозы с обратной связью от читателей и критиков. Спортсмену — пройти систему турниров от местечковых до самых крупных. Предпринимателю — череду убыточных и малоуспешных начинаний.
И именно в этом процессе сформируется наиболее верное представление, о том, как всё устроено, и как должно быть.
Бизнес-аналитики гарантированно расскажут вам, как сильно первоначальные представления — что пользователя, что их собственные — отличаются от итогового результата. Руководители стартап-проектов подтвердят, как важно активно тестировать гипотезы одну за другой, чтобы от этих самых гипотез перейти к реальным представлениям о выбранной нише.
Ничто не высечено из камня. Мир состоит из уникального сочетания случайностей, поэтому любой проект создаётся [почти] как в первый раз.
Рефакторинг архитектуры — это не переделка в один прекрасный момент (обычно при смене команды), а продолжающийся процесс доработки архитектуры под меняющуюся реальность и/или наши уточняющиеся знания о ней.
Никогда нельзя ориентироваться на справочные данные о производительности используемых продуктов, на теоретические выкладки о быстродействии и надёжности, какими бы академичными они ни были. Даже прототип важно подвергать нагрузочному тестированию, и только в той среде, которая сформирована именно на этом проекте. Никакой прошлый опыт не валиден до конца.
И суть TDD тоже в сокращении цикла обратной связи о качестве кода.
Это всё тот же синдром Данилы-мастера, если кажется, что можно долго и упорно, тщательно и «правильно» готовиться, а потом выйти и впечатлить всех монументальностью результатов. Писателю — придётся пройти циклы короткой прозы с обратной связью от читателей и критиков. Спортсмену — пройти систему турниров от местечковых до самых крупных. Предпринимателю — череду убыточных и малоуспешных начинаний.
И именно в этом процессе сформируется наиболее верное представление, о том, как всё устроено, и как должно быть.
Система для системного мышления
Я точно не из тех, кто будет бурчать про «поколение ЕГЭ», падение качества образования, засилье курсов и прочие стариковские установки. Потому что убеждён:
Всё у нас с новыми поколениями разработчиков отлично!
Наша работа — для умных ребят с определённым складом ума, постоянным самосовершенствованием и желанием создавать.
И если я что и могу сделать для этих людей, это помочь пройти путь к более глубокому пониманию профессии, к уверенному достижению результатов, к полному удовлетворению делом, которому мы все отдаём значительную часть времени каждый день.
Я уверен, что системный подход и мышление способны повысить профессиональный уровень junior- и middle-разработчиков, продвинуть их к более интересным проектам и более успешным и качественным результатам.
Есть множество хороших источников типа вузовских программ, курсов, видео и книг, которые дают знания. Моя цель немного в другом. Помимо блога в этом телеграм-канале и видео на Ютубе я придумал консультационный цикл, что-то типа лекций, где все основные принципы, шаблоны и аббревиатуры выстраиваются в одну систему знаний с причинно-следственными связями, логичным объяснением что, зачем и почему — это именно то, что чаще всего не объясняют, превращая всё в догмы.
И конечно, раз я критикую примеры на кошечках-собачках и автомобилях, я хочу также показать, как теория реализуется на реальной практике.
На первой встрече 25-го мая в 12:00 МСК будем говорить про ООП, в частности, разбирать:
— декомпозицию и абстракцию,
— распределение ответственности,
— отношения между классами (а не только наследование),
— связанность и связность (a.k.a. «зацепление»).
Это — первый шаг из 4 в построении такой системы понимания, которая продвинет от «теории плоской земли» в ООП к нормальной такой «модели солнечной системы», где всё на своих местах.
Промокод для своих (больше никому не даю его): CIENTO даёт царскую скидку 40% до 7 мая включительно.
Записаться на лекцию
Я точно не из тех, кто будет бурчать про «поколение ЕГЭ», падение качества образования, засилье курсов и прочие стариковские установки. Потому что убеждён:
Всё у нас с новыми поколениями разработчиков отлично!
Наша работа — для умных ребят с определённым складом ума, постоянным самосовершенствованием и желанием создавать.
И если я что и могу сделать для этих людей, это помочь пройти путь к более глубокому пониманию профессии, к уверенному достижению результатов, к полному удовлетворению делом, которому мы все отдаём значительную часть времени каждый день.
Я уверен, что системный подход и мышление способны повысить профессиональный уровень junior- и middle-разработчиков, продвинуть их к более интересным проектам и более успешным и качественным результатам.
Есть множество хороших источников типа вузовских программ, курсов, видео и книг, которые дают знания. Моя цель немного в другом. Помимо блога в этом телеграм-канале и видео на Ютубе я придумал консультационный цикл, что-то типа лекций, где все основные принципы, шаблоны и аббревиатуры выстраиваются в одну систему знаний с причинно-следственными связями, логичным объяснением что, зачем и почему — это именно то, что чаще всего не объясняют, превращая всё в догмы.
И конечно, раз я критикую примеры на кошечках-собачках и автомобилях, я хочу также показать, как теория реализуется на реальной практике.
На первой встрече 25-го мая в 12:00 МСК будем говорить про ООП, в частности, разбирать:
— декомпозицию и абстракцию,
— распределение ответственности,
— отношения между классами (а не только наследование),
— связанность и связность (a.k.a. «зацепление»).
Это — первый шаг из 4 в построении такой системы понимания, которая продвинет от «теории плоской земли» в ООП к нормальной такой «модели солнечной системы», где всё на своих местах.
Промокод для своих (больше никому не даю его): CIENTO даёт царскую скидку 40% до 7 мая включительно.
Записаться на лекцию
👍1🔥1
Как я создал Студенческий центр разработки и собственную методику
В 2010-е я был техлидом аутсорсинговой компании, которую мы с коллегой вырастили от двух (нас самих) до 20 разработчиков. Моя задача была в организации разработки, создании и наборе команды, в управлении проектами.
Очень быстро стало понятно, что кадры с рынка набирать было долго, иногда не по карману, поэтому чаще всего приходилось «подтягивать» ребят до необходимого уровня, а глобально — научиться эффективно и результативно работать с теми, кто есть на рынке, кого можем себе позволить. Сначала у работал с новыми членами команды индивидуально, прокачивая каждого по индивидуальным планам.
Потом возникла идея, что можно делать это работая со студентами старших курсов в группах. В те времена в вузах уже развились учебные центры крупных компаний от Эпама до 1С. Это были учебные центры с полноценными программами подготовки, скажем, Java-программистов, или дотнет, т.е. сильно «вширь». В других центрах были и варианты подготовки узких специалистов под конкретные задачи компаний, т.е. узко, но «вглубь».
По имеющимся ресурсам и в сочетании с нашими потребностями, нам не совсем подходило ни то, ни другое. Мне нужны были разработчики с инженерным мышлением, пусть не сильно опытные или вообще без опыта. Но имеющие прочную базу, позволяющую легко развиваться при работе над задачами проектов. Так я создал свою собственную методику: дать не абстрактные знания о технологиях, как обычно делают при обучении (вот есть такое, сякое, это, а ещё, смотри, и вот это есть!), а заложить основы системы, на которую потом легко и понятно ложатся дальнейшие знания и опыт. Моя цель всегда была в том, чтобы разработчику было понятно то, что и зачем он делает, с самого начала карьеры джуниора и далее.
Весь мой опыт показывает, что это всегда работает просто отлично: в моих командах большинство разработчиков растут очень быстро и довольно самостоятельны. С тех пор и моё понимание, что и в какой момент важно объяснить, выкристаллизовалось.
Я собираю на основе своей методики свежий актуальный цикл из 4 лекций с, который закладывает такую систему мышления, чтобы объектно-ориентированный анализ, проектирование и программирование были понятным и интересным процессом, а не сумбуром и рутиной. Запись на первую лекцию продолжается. Вопросы — пишите в каментах, я помогу определиться, подходит ли вам этот материал, и какую ценность он сможет вам дать.
В 2010-е я был техлидом аутсорсинговой компании, которую мы с коллегой вырастили от двух (нас самих) до 20 разработчиков. Моя задача была в организации разработки, создании и наборе команды, в управлении проектами.
Очень быстро стало понятно, что кадры с рынка набирать было долго, иногда не по карману, поэтому чаще всего приходилось «подтягивать» ребят до необходимого уровня, а глобально — научиться эффективно и результативно работать с теми, кто есть на рынке, кого можем себе позволить. Сначала у работал с новыми членами команды индивидуально, прокачивая каждого по индивидуальным планам.
Потом возникла идея, что можно делать это работая со студентами старших курсов в группах. В те времена в вузах уже развились учебные центры крупных компаний от Эпама до 1С. Это были учебные центры с полноценными программами подготовки, скажем, Java-программистов, или дотнет, т.е. сильно «вширь». В других центрах были и варианты подготовки узких специалистов под конкретные задачи компаний, т.е. узко, но «вглубь».
По имеющимся ресурсам и в сочетании с нашими потребностями, нам не совсем подходило ни то, ни другое. Мне нужны были разработчики с инженерным мышлением, пусть не сильно опытные или вообще без опыта. Но имеющие прочную базу, позволяющую легко развиваться при работе над задачами проектов. Так я создал свою собственную методику: дать не абстрактные знания о технологиях, как обычно делают при обучении (вот есть такое, сякое, это, а ещё, смотри, и вот это есть!), а заложить основы системы, на которую потом легко и понятно ложатся дальнейшие знания и опыт. Моя цель всегда была в том, чтобы разработчику было понятно то, что и зачем он делает, с самого начала карьеры джуниора и далее.
Весь мой опыт показывает, что это всегда работает просто отлично: в моих командах большинство разработчиков растут очень быстро и довольно самостоятельны. С тех пор и моё понимание, что и в какой момент важно объяснить, выкристаллизовалось.
Я собираю на основе своей методики свежий актуальный цикл из 4 лекций с, который закладывает такую систему мышления, чтобы объектно-ориентированный анализ, проектирование и программирование были понятным и интересным процессом, а не сумбуром и рутиной. Запись на первую лекцию продолжается. Вопросы — пишите в каментах, я помогу определиться, подходит ли вам этот материал, и какую ценность он сможет вам дать.
Как можно применить на практике шаблон Interpreter
#ВопросПодписчика
Ярослав задал в комментариях интересный вопрос про шаблон проектирования Интерпретатор, где можно применить его в реальных проектах. Не самый частый шаблон, согласен.
Если исключить историю с полноценными DSL, навскидку припомнил 2 случая. Первый был вдохновлён утилитой artisan от Laravel. Это было веб-приложение, но которое при этом при передаче определённых команд работало как консольное и выполняло сервисные функции с более естественным синтаксисом, чем традиционные для консольных утилит ключи.
Второе применение как раз довольно типичное. Если поисковая строка на форме может работать в продвинутом режиме с поддержкой какого-то языка запросов (как в примере на скрине ниже), код будет куда чище и понятнее с шаблоном, чем с вереницей split-for-if-ов. Важно: если оно того стоит, конечно.
#Шаблоны
#ВопросПодписчика
Ярослав задал в комментариях интересный вопрос про шаблон проектирования Интерпретатор, где можно применить его в реальных проектах. Не самый частый шаблон, согласен.
Если исключить историю с полноценными DSL, навскидку припомнил 2 случая. Первый был вдохновлён утилитой artisan от Laravel. Это было веб-приложение, но которое при этом при передаче определённых команд работало как консольное и выполняло сервисные функции с более естественным синтаксисом, чем традиционные для консольных утилит ключи.
Второе применение как раз довольно типичное. Если поисковая строка на форме может работать в продвинутом режиме с поддержкой какого-то языка запросов (как в примере на скрине ниже), код будет куда чище и понятнее с шаблоном, чем с вереницей split-for-if-ов. Важно: если оно того стоит, конечно.
#Шаблоны
🔥2
Не войти в айти
Кибернетике как науке ~80 лет. Изначально и первые лет 40 те, кто сейчас называется программистами, были выходцами из математики. Можно сказать, это было специальным разделом математики по работе с данными и информацией. Тогда ученые пошли по ошибочному пути, и вместо генерации мемов с котиками (или на худой конец «репродукции Джоконды» как в фильме «Служебный роман») решали задачи промышленности. Построение самого быстрого маршрута в автомобильном навигаторе с учётом пробок или же выбор роботом-упаковщиком в Амазоне оптимальной коробки для упаковки товара — это всё задачи, решённые в середине прошлого века. Если образно, инженер в исполнении Антона Лапенко — так я себе представляю по своим университетским преподавателям тех самых математиков-кибернетиков.
* * *
В 1980-е/1990-е появились и стали массово распространяться персональные компьютеры для офиса и домашнего использования. Появилась целая индустрия производства программного обеспечения, она и развивалась как самостоятельная новая индустрия с математическими корнями. Появлялись языки программирования новых поколений, которые позволяли разрабатывать ПО быстрее и качественнее, формировались методологии (технологические процессы). Но в данном случае для нас важно, что появился спрос на автоматизацию всего на свете и, как следствие, увеличение количества обучающихся профессии в вузах. Я причисляю себя к этому второму поколению программистов. У меня специализированное высшее техническое образование: я изучал и математику, и кибернетику, и промышленную разработку ПО.
* * *
В 2010-е масштабы автоматизации ещё увеличились с широким распространением смартфонов и так называемого Веб 2.0. Все пришли в интернет и стали потреблять цифровые услуги через интернет. Как вы понимаете, снова увеличился и спрос на ещё большее количество программистов. В индустрию нужно было привлекать массово рабочие руки, и туда пришли уже не как в науку-математику или увлечение компьютерными науками, а, по выражению моего друга, за «гигантскими айтишными зарплатами». Появился новый способ «войти в айти» через стажировки в учебных центрах айти-компаний и обучение на онлайн-курсах.
* * *
Как вы наверняка слышали, сейчас идут массовые сокращения в крупных компаниях за счёт внедрения ИИ. На мой взгляд пока что это больше оптимизация неэффективного раздутого штата этих самых крупных компаний. Но дальше будет круче. Это завершение периода, когда экономически эффективно было «закрывать позиции» привлечением почти любого, кто худо-бедно способен решать задачи. Надежды возлагаются на ИИ-агентов, которые «худо-бедно» решат типовые задачи и без толпы программистов, только сформулируй задачу грамотно. Про это отдельно напишу.
Вместе с этим всё больше статей пишут о том, что дабы оставаться в обойме, в профессии и как минимум в прежнем уровне дохода, придётся гораздо больше работать, приносить больше ценности работодателю. Как лайфхак появился микро-тренд на монетизацию знаний: для дополнительного источника дохода можно делиться знаниями. Те, кто учат учить, любят использовать факт сокращения спроса у работодателей и при этом потребности в сохранении прежнего уровня дохода у программистов как аргумент, что поезд почти уходит, надо успевать учить и монетизировать навык. По-моему, тот поезд ушёл в 2010-х, как я описал выше в своём историческом экскурсе. Если и будет востребовано обучение и консультирование в айти, то скорее обучение робота, и то, если это какой-то не очень распространённый навык. Ни обучение людей айти, ни даже обучение роботов, кроме нескольких крупных олигополий, не может быть бизнесом с горизонтом в 10 лет, а разве что предприимчивым краткосрочным проектом.
История сделала круг, и вхождение в айти-профессию снова обретает высокий порог специализированных или даже околонаучных знаний.
Кибернетике как науке ~80 лет. Изначально и первые лет 40 те, кто сейчас называется программистами, были выходцами из математики. Можно сказать, это было специальным разделом математики по работе с данными и информацией. Тогда ученые пошли по ошибочному пути, и вместо генерации мемов с котиками (или на худой конец «репродукции Джоконды» как в фильме «Служебный роман») решали задачи промышленности. Построение самого быстрого маршрута в автомобильном навигаторе с учётом пробок или же выбор роботом-упаковщиком в Амазоне оптимальной коробки для упаковки товара — это всё задачи, решённые в середине прошлого века. Если образно, инженер в исполнении Антона Лапенко — так я себе представляю по своим университетским преподавателям тех самых математиков-кибернетиков.
* * *
В 1980-е/1990-е появились и стали массово распространяться персональные компьютеры для офиса и домашнего использования. Появилась целая индустрия производства программного обеспечения, она и развивалась как самостоятельная новая индустрия с математическими корнями. Появлялись языки программирования новых поколений, которые позволяли разрабатывать ПО быстрее и качественнее, формировались методологии (технологические процессы). Но в данном случае для нас важно, что появился спрос на автоматизацию всего на свете и, как следствие, увеличение количества обучающихся профессии в вузах. Я причисляю себя к этому второму поколению программистов. У меня специализированное высшее техническое образование: я изучал и математику, и кибернетику, и промышленную разработку ПО.
* * *
В 2010-е масштабы автоматизации ещё увеличились с широким распространением смартфонов и так называемого Веб 2.0. Все пришли в интернет и стали потреблять цифровые услуги через интернет. Как вы понимаете, снова увеличился и спрос на ещё большее количество программистов. В индустрию нужно было привлекать массово рабочие руки, и туда пришли уже не как в науку-математику или увлечение компьютерными науками, а, по выражению моего друга, за «гигантскими айтишными зарплатами». Появился новый способ «войти в айти» через стажировки в учебных центрах айти-компаний и обучение на онлайн-курсах.
* * *
Как вы наверняка слышали, сейчас идут массовые сокращения в крупных компаниях за счёт внедрения ИИ. На мой взгляд пока что это больше оптимизация неэффективного раздутого штата этих самых крупных компаний. Но дальше будет круче. Это завершение периода, когда экономически эффективно было «закрывать позиции» привлечением почти любого, кто худо-бедно способен решать задачи. Надежды возлагаются на ИИ-агентов, которые «худо-бедно» решат типовые задачи и без толпы программистов, только сформулируй задачу грамотно. Про это отдельно напишу.
Вместе с этим всё больше статей пишут о том, что дабы оставаться в обойме, в профессии и как минимум в прежнем уровне дохода, придётся гораздо больше работать, приносить больше ценности работодателю. Как лайфхак появился микро-тренд на монетизацию знаний: для дополнительного источника дохода можно делиться знаниями. Те, кто учат учить, любят использовать факт сокращения спроса у работодателей и при этом потребности в сохранении прежнего уровня дохода у программистов как аргумент, что поезд почти уходит, надо успевать учить и монетизировать навык. По-моему, тот поезд ушёл в 2010-х, как я описал выше в своём историческом экскурсе. Если и будет востребовано обучение и консультирование в айти, то скорее обучение робота, и то, если это какой-то не очень распространённый навык. Ни обучение людей айти, ни даже обучение роботов, кроме нескольких крупных олигополий, не может быть бизнесом с горизонтом в 10 лет, а разве что предприимчивым краткосрочным проектом.
История сделала круг, и вхождение в айти-профессию снова обретает высокий порог специализированных или даже околонаучных знаний.
👍1👌1