Про переусложнение простого
Начинающие сениоры и архитекторы часто страдают болезнью переусложнения. Почему-то они считают, что простое решение недостойно звания старшего специалиста и в него нужно добавить изюминку. Помню, как в давние времена разработчики лепили паттерны из GoF в каждом первом проекте. Там были сигнлтоны, которые порождали абстрактные фабрики, которые создавали стратегии. Для дебага и поиска ошибок в этом поделии нужно было хорошо так залезать на Балмеровский пик.
Для меня признаком зрелости спеца - это умение делать сложное простым. Поэтому для код-ревью я использую "Критерий уставшего мидла". Если уставший после пятницы мидл в три часа ночи может починить упавший прод, поправив багу в незнакомом ему коде - это хороший, годный код.
Это критично для устойчивости проекта во времени. Потому что ваши сениоры уйдут на повышения, на их место придут новенькие и ваш код сразу станет черным ящиком - работает, но непонятно как и который никто не хочет трогать.
Даже годовалый проект таким образом может стать легаси.
Начинающие сениоры и архитекторы часто страдают болезнью переусложнения. Почему-то они считают, что простое решение недостойно звания старшего специалиста и в него нужно добавить изюминку. Помню, как в давние времена разработчики лепили паттерны из GoF в каждом первом проекте. Там были сигнлтоны, которые порождали абстрактные фабрики, которые создавали стратегии. Для дебага и поиска ошибок в этом поделии нужно было хорошо так залезать на Балмеровский пик.
Для меня признаком зрелости спеца - это умение делать сложное простым. Поэтому для код-ревью я использую "Критерий уставшего мидла". Если уставший после пятницы мидл в три часа ночи может починить упавший прод, поправив багу в незнакомом ему коде - это хороший, годный код.
Это критично для устойчивости проекта во времени. Потому что ваши сениоры уйдут на повышения, на их место придут новенькие и ваш код сразу станет черным ящиком - работает, но непонятно как и который никто не хочет трогать.
Даже годовалый проект таким образом может стать легаси.
👍4
Байка про переусложнение
Немедленно вспомнился один релиз, который мы делали 30 декабря. Все были на позитивчике, готовятся к праздникам, шутят шутки. Хотели закончить на позитиве год, порадовать заграничного заказчика свеженьким функционалом.
Наш лид-бекенд пушит код и уходит в закат. Лид был грамотным, поэтому никто в его рабочести не сомневался. Но конечно же, на стейдже нашлась сотня строчек в базе, на которых код падал. Так как лид был грамотным, два миллиона записей обрабатывались одним Java стримом с лямбдой внутри. Лямбда была строчек на 10, в ней вселенные росли и рушились, а падала она после 20 минут работы.
Продолбавшись пару часов, мы откатили все обратно и пошли выпивать уже с горя. С тех пор сложный код я не пропускаю...
Немедленно вспомнился один релиз, который мы делали 30 декабря. Все были на позитивчике, готовятся к праздникам, шутят шутки. Хотели закончить на позитиве год, порадовать заграничного заказчика свеженьким функционалом.
Наш лид-бекенд пушит код и уходит в закат. Лид был грамотным, поэтому никто в его рабочести не сомневался. Но конечно же, на стейдже нашлась сотня строчек в базе, на которых код падал. Так как лид был грамотным, два миллиона записей обрабатывались одним Java стримом с лямбдой внутри. Лямбда была строчек на 10, в ней вселенные росли и рушились, а падала она после 20 минут работы.
Продолбавшись пару часов, мы откатили все обратно и пошли выпивать уже с горя. С тех пор сложный код я не пропускаю...
👍1
Зачем нужно два саб-лида
В любой долгоживущей команде от 5 человек нужно заводить себе заместителя. Он может принимать решения от моего имени, имеет полномочия и ответственность. Это нужно на случай:
- отпуска
- карьерного роста
- смены проекта
- личностного кризиса, когда все надоело
- ухода из компании/проекта
Про это учил еще Стратоплан в 2010-х годах, но почему-то для многих лидов сейчас это становится инсайтом....
Но эта структура хрупкая. Заместитель сам может уволиться, уйти на другой или просто не справиться. Поэтому я всегда завожу двух подлидов. Оно надежней с точки зрения рисков, распределения нагрузки и антихрупкости.
Потому что самая устойчивая фигура - это треугольник.
В любой долгоживущей команде от 5 человек нужно заводить себе заместителя. Он может принимать решения от моего имени, имеет полномочия и ответственность. Это нужно на случай:
- отпуска
- карьерного роста
- смены проекта
- личностного кризиса, когда все надоело
- ухода из компании/проекта
Про это учил еще Стратоплан в 2010-х годах, но почему-то для многих лидов сейчас это становится инсайтом....
Но эта структура хрупкая. Заместитель сам может уволиться, уйти на другой или просто не справиться. Поэтому я всегда завожу двух подлидов. Оно надежней с точки зрения рисков, распределения нагрузки и антихрупкости.
Потому что самая устойчивая фигура - это треугольник.
Микросервисы: байка с собеседования
Как-то я собеседовался на Solution Architect к одному большому, но не особо интересному мне заказчику. Настроение было хорошим и я решил отвечать не по стандартному STAR, а по настроению.
И на стандартный вопрос "Ваше самое сложное решение в архитектуре" я ответил - "Уговорил заказчика переехать с микросервисов на монолит". Потому что его желание сделать модно и отрапортавать о внедрении подхода прямо конфликтовало с нефункциональными требованиями и fit for purpose. А так как само приложение было важнее, чем фейковые микросервисы, мы быстро его написали и укатили в прод.
Неожиданно для меня, CTO на той стороне оказался нашим человеком и понимающе заулыбался. Для меня это было как осознать, что мы не одни во вселенной.
Как-то я собеседовался на Solution Architect к одному большому, но не особо интересному мне заказчику. Настроение было хорошим и я решил отвечать не по стандартному STAR, а по настроению.
И на стандартный вопрос "Ваше самое сложное решение в архитектуре" я ответил - "Уговорил заказчика переехать с микросервисов на монолит". Потому что его желание сделать модно и отрапортавать о внедрении подхода прямо конфликтовало с нефункциональными требованиями и fit for purpose. А так как само приложение было важнее, чем фейковые микросервисы, мы быстро его написали и укатили в прод.
Неожиданно для меня, CTO на той стороне оказался нашим человеком и понимающе заулыбался. Для меня это было как осознать, что мы не одни во вселенной.
😁3
Собеседования как казино
К слову, за свою карьеру я провел под тысячу собеседований и сам прошел под сотню. Имею сказать, что собеседование - это полное казино. Безусловно, готовиться к собесам надо и можно провалидировать себя через какие-то сервисы или людей. Но вот оценивать себя только через них - нельзя, ибо уроните самооценку и уверенность в себе. Потому что честный фидбек вам никогда не дадут.
Топ моих забавных причин. когда-то отказывали мне:
1. Я не знаю, как создать команду с нуля (ответил на вопрос поверхностно). К этому моменту у меня было два выступления на TLC про создание команды и я кидал рекрутерам статьи.
2. Я плохо отношусь к людям и в Scrum-мастера не подойду.
3. Я не умею запускать потоки в Java Swing.
4. Я никогда не вел к общей цели большие команды. То, что я был программом на 50+ человек - это не считается, потому что у каждой команды цели были свои.
За этими отказами может стоять все, что угодно:
- с женой утром поругался
- не состоялась химия
- отвечал слишком уверенно
- отвечал неуверенно
- резюме слишком большое
- человека уже заофферили на позицию и тебя собеседуют как запасной аэродром
При случае расскажу, по каким странным причинам отказывали коллеги.
К слову, за свою карьеру я провел под тысячу собеседований и сам прошел под сотню. Имею сказать, что собеседование - это полное казино. Безусловно, готовиться к собесам надо и можно провалидировать себя через какие-то сервисы или людей. Но вот оценивать себя только через них - нельзя, ибо уроните самооценку и уверенность в себе. Потому что честный фидбек вам никогда не дадут.
Топ моих забавных причин. когда-то отказывали мне:
1. Я не знаю, как создать команду с нуля (ответил на вопрос поверхностно). К этому моменту у меня было два выступления на TLC про создание команды и я кидал рекрутерам статьи.
2. Я плохо отношусь к людям и в Scrum-мастера не подойду.
3. Я не умею запускать потоки в Java Swing.
4. Я никогда не вел к общей цели большие команды. То, что я был программом на 50+ человек - это не считается, потому что у каждой команды цели были свои.
За этими отказами может стоять все, что угодно:
- с женой утром поругался
- не состоялась химия
- отвечал слишком уверенно
- отвечал неуверенно
- резюме слишком большое
- человека уже заофферили на позицию и тебя собеседуют как запасной аэродром
При случае расскажу, по каким странным причинам отказывали коллеги.
👏2
Про Agile-коучей
В среде разработчиков Agile-коучей часто считают лучезарными п*здаболами, которые мешают писать код. Раньше я на эгегей начинал объяснять, что это сопротивление переменам и вообще они все скоро поймут как были неправы.
Только вот они правы. Agile-коуч - это такое же расплывчатое наименование, как разработчик. Если мы делим разрабов по технологиям, направлениям, фокусам, то почему такого нет с коучами?
Для себя я выделяю следующие породы агилистов:
- новичек-процессник - умеет выстраивать Scrum или SAFe как по книжке.
- коуч-фасилитатор - задает мощные вопросы и делает все через фасилитацию. Закончил Эриксона. В технике полный ноль.
- технарь-девопёс - настраивает технический поток ценности, JIRA всякие и прочие автоматизации. Фасилитировать не любит, с топами общаться не умеет.
- Труъ-коуч - может комбинировать любые из этих ролей, умеет найти корень проблемы. Вот он - ваш бро и принесет пользу. Стоит как крыло самолета и на рынке не валяется.
- еще 300 гендеров видов и названий себя, которые являются попыткой сделать Уникальное Торговое Предложение, но с своей сути относятся к первым трем.
Если по счастливой случайности HR'ы выбрали правильную породу, то происходит матч и кейс схлопывается. А вот если не повезло, то коуч выдрючивает команду на то, что сам умеет. В лучшем случае выходит локальная субоптимизация. В худшем - ломается текущий статус-кво и команда перестает нормально деливерить.
Поэтому выбирайте инструменты под ваши цели, а не по инсте/фоточкам/цене. Вы же не посадите писать Java код специалиста по микроконтроллерам, хотя и тот и тот - программисты.
В среде разработчиков Agile-коучей часто считают лучезарными п*здаболами, которые мешают писать код. Раньше я на эгегей начинал объяснять, что это сопротивление переменам и вообще они все скоро поймут как были неправы.
Только вот они правы. Agile-коуч - это такое же расплывчатое наименование, как разработчик. Если мы делим разрабов по технологиям, направлениям, фокусам, то почему такого нет с коучами?
Для себя я выделяю следующие породы агилистов:
- новичек-процессник - умеет выстраивать Scrum или SAFe как по книжке.
- коуч-фасилитатор - задает мощные вопросы и делает все через фасилитацию. Закончил Эриксона. В технике полный ноль.
- технарь-девопёс - настраивает технический поток ценности, JIRA всякие и прочие автоматизации. Фасилитировать не любит, с топами общаться не умеет.
- Труъ-коуч - может комбинировать любые из этих ролей, умеет найти корень проблемы. Вот он - ваш бро и принесет пользу. Стоит как крыло самолета и на рынке не валяется.
- еще 300 гендеров видов и названий себя, которые являются попыткой сделать Уникальное Торговое Предложение, но с своей сути относятся к первым трем.
Если по счастливой случайности HR'ы выбрали правильную породу, то происходит матч и кейс схлопывается. А вот если не повезло, то коуч выдрючивает команду на то, что сам умеет. В лучшем случае выходит локальная субоптимизация. В худшем - ломается текущий статус-кво и команда перестает нормально деливерить.
Поэтому выбирайте инструменты под ваши цели, а не по инсте/фоточкам/цене. Вы же не посадите писать Java код специалиста по микроконтроллерам, хотя и тот и тот - программисты.
🔥1
Не используйте микросервисы в глухом энтерпрайзе
Это небольшой тизер статьи про микросервисы.
Интегрировался как-то мой друг с одним микросервисом в большом энтерпрайзе. Контракт описан JSON схемой, по ней сгенерирован класс. Казалось бы, напишет такое даже восьмилетний ребенок. Но как-то все время получается, что микросервис отдает всегда пустой ответ (контрактом не запрещено, аналог 404). Коллега c другой стороны говорит, что все работает и данные отдаются.
В общем, надо было залезть в дебаг и посмотреть ответ (см. картинка 2). Автор микросервиса с тиой стороны утверждает, что все ок и иногда он будет слать ошибки. А чтобы было проще читать (?) он свалили все поля в optionalParameters.
Именно поэтому я всегда говорю, что микросервисны крайне требовательны к команде/культуре и то, что не нужно их пихать где придется.
Это небольшой тизер статьи про микросервисы.
Интегрировался как-то мой друг с одним микросервисом в большом энтерпрайзе. Контракт описан JSON схемой, по ней сгенерирован класс. Казалось бы, напишет такое даже восьмилетний ребенок. Но как-то все время получается, что микросервис отдает всегда пустой ответ (контрактом не запрещено, аналог 404). Коллега c другой стороны говорит, что все работает и данные отдаются.
В общем, надо было залезть в дебаг и посмотреть ответ (см. картинка 2). Автор микросервиса с тиой стороны утверждает, что все ок и иногда он будет слать ошибки. А чтобы было проще читать (?) он свалили все поля в optionalParameters.
Именно поэтому я всегда говорю, что микросервисны крайне требовательны к команде/культуре и то, что не нужно их пихать где придется.
Про диктатуру архитектората и техлидеротората
Самоорганизация команды вокруг требований, intentional архитектура - это правильно и модно. Я даже такое на тренингах советую. Но есть ряд вещей, которые должен решать только архитектор/техлид с группой избранных.
В основном, это касается явных (масштабируемость, скорость, нагрузка) и неявных (мониторинг, майнтейнабилити) нефункциональных требований. Для контроля исполнения обязателен архитектурный надзор, потому что разработчики на все ваши требования положат огромный болт. А разгребать это все придется вам.
Вот вам живой пример заваленного NFR
Поэтому, если вы техлид или архитектор:
1. NFR всегда становятся частью Code Review. За несоблюдение - жесткая кара
2. То же логирование можно проверять на уровне анализаторов кода. Тогда карать будет бездушная железка.
Правила возводятся в абсолют, пока это не станет частью инженерной культуры.
А критерий проверки хороших логов - дать их почитать рандомному суппорту 2-3 уровня. Если он поймет где ошибка и что с ней делать, то логи годные.
Самоорганизация команды вокруг требований, intentional архитектура - это правильно и модно. Я даже такое на тренингах советую. Но есть ряд вещей, которые должен решать только архитектор/техлид с группой избранных.
В основном, это касается явных (масштабируемость, скорость, нагрузка) и неявных (мониторинг, майнтейнабилити) нефункциональных требований. Для контроля исполнения обязателен архитектурный надзор, потому что разработчики на все ваши требования положат огромный болт. А разгребать это все придется вам.
Вот вам живой пример заваленного NFR
Observability. C ошибкой падает один из микросервисов, в логах одна строчка IllegalArgumentException: Invalid Data без указания чего бы то ни было. Ей богу, лучше бы стектрейс выплюнули. Воспроизводится, конечно же, только на окружении. А логи писать не нужно, потому что ну и так все работает и из кода понятно.Поэтому, если вы техлид или архитектор:
1. NFR всегда становятся частью Code Review. За несоблюдение - жесткая кара
2. То же логирование можно проверять на уровне анализаторов кода. Тогда карать будет бездушная железка.
Правила возводятся в абсолют, пока это не станет частью инженерной культуры.
А критерий проверки хороших логов - дать их почитать рандомному суппорту 2-3 уровня. Если он поймет где ошибка и что с ней делать, то логи годные.
👍3