Байка про переусложнение
Немедленно вспомнился один релиз, который мы делали 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
Тест на профессионализм скрам-мастера
Если скрам-мастер не умеет сам настраивать JIRA/Trello/YouTrack, то это не повелитель скрама, а п*здабол. Для инспекции процесса, создании прозрачности и фокуса, таск трекер обязан быть! Исключение - оффлайн доска в офисе (что-то на древнем сказал).
По опыту скажу, что разработчики ругаются на JIRA если:
- она не отображает текущий процесс разработки
- доска не настроена поэтому не имеет ценности
- процесс бюрократизирован
Редкая команда знает, как на самом деле надо, поэтому и считает JIRA отстоем по-умолчанию. А виноват-то на самом деле неквалифицированный кое-кто. Но не бойся мой друг, я скоро выпущу статью про базированную JIRA и твоя доска станет самой лучшей в компании.
А пока протестируй себя или своего скрам-мастера!
Дано: команда фигачит так, что перья летят и закрывает задачи вовремя. Даже берет что-то из беклога. Но её бёрндаун выглядит как на картинке (как в 90% случаев во всех командах).
Вопрос: как сделать так, чтобы берндаун отображался правильно?
Если скрам-мастер не умеет сам настраивать JIRA/Trello/YouTrack, то это не повелитель скрама, а п*здабол. Для инспекции процесса, создании прозрачности и фокуса, таск трекер обязан быть! Исключение - оффлайн доска в офисе (что-то на древнем сказал).
По опыту скажу, что разработчики ругаются на JIRA если:
- она не отображает текущий процесс разработки
- доска не настроена поэтому не имеет ценности
- процесс бюрократизирован
Редкая команда знает, как на самом деле надо, поэтому и считает JIRA отстоем по-умолчанию. А виноват-то на самом деле неквалифицированный кое-кто. Но не бойся мой друг, я скоро выпущу статью про базированную JIRA и твоя доска станет самой лучшей в компании.
А пока протестируй себя или своего скрам-мастера!
Дано: команда фигачит так, что перья летят и закрывает задачи вовремя. Даже берет что-то из беклога. Но её бёрндаун выглядит как на картинке (как в 90% случаев во всех командах).
Вопрос: как сделать так, чтобы берндаун отображался правильно?
👍6
Как и обещал, статья по настройке JIRA и по базированному процессу. Пользуйся, мой юный скрам-мастер и тимлид. https://telegra.ph/Bazirovannaya-JIRA-dlya-timlidaskram-mastera-10-10
Telegraph
Базированная JIRA для тимлида/скрам-мастера
Без таск-трекера (aka JIRA) вы не построите ни скрам, ни канбан, ни херак-херак-в-продакшен. На курсах тимлидов и скрам-мастеров такие низменные вещи не преподают (они сами не знают, это же не цикл Такмана). А без этого инструмента ты теряешь прозрачность…
👍9🔥2
Стоит ли работать с коллегами-м*даками?
Частый вопрос на тренингах скрам-мастеров и тимлидов - "Что делать со сложными подчиненными?". Мой ответ всегда однозначный - если человек м*дак, то убирайте его с горизонта команды. Даже если вы его закоучите и зафасилитируйте до полусмерти, он все равно будет портить атмосферу и командную динамику. Из-за него группа будет меньше общаться, меньше поднимать острых вопросов, не будет доверия.
Что делать, если твой начальник м*дак?
Тут все не так однозначно. Если он - пустышка, то меняйте его безжалостно. Я, обычно, ухожу сам в другую команду/компанию. Просто терпеть и игнорировать у вас долго не получится - вы потеряете мотивацию к работе и получите выгорание. Я в таком случае сразу дистанцируюсь и сворачиваю общение и начинаю искать варианты.
A если вам есть чему поучиться у этого человека, то можно заключить договор с совестью и стиснуть зубы. Гениальность и сумасшествие - они хотят вместе. Больше всего знаний и опыта я получил от крайне сложного человека, который меня практически довел до дурдома. Но оно того точно стоило. Только чтобы не выгореть, нужно вовремя соскочить. Лучше всего поставить себе какие-то четкие критерии по времени или по своему состоянию. Иначе - дурка.
Частый вопрос на тренингах скрам-мастеров и тимлидов - "Что делать со сложными подчиненными?". Мой ответ всегда однозначный - если человек м*дак, то убирайте его с горизонта команды. Даже если вы его закоучите и зафасилитируйте до полусмерти, он все равно будет портить атмосферу и командную динамику. Из-за него группа будет меньше общаться, меньше поднимать острых вопросов, не будет доверия.
Что делать, если твой начальник м*дак?
Тут все не так однозначно. Если он - пустышка, то меняйте его безжалостно. Я, обычно, ухожу сам в другую команду/компанию. Просто терпеть и игнорировать у вас долго не получится - вы потеряете мотивацию к работе и получите выгорание. Я в таком случае сразу дистанцируюсь и сворачиваю общение и начинаю искать варианты.
A если вам есть чему поучиться у этого человека, то можно заключить договор с совестью и стиснуть зубы. Гениальность и сумасшествие - они хотят вместе. Больше всего знаний и опыта я получил от крайне сложного человека, который меня практически довел до дурдома. Но оно того точно стоило. Только чтобы не выгореть, нужно вовремя соскочить. Лучше всего поставить себе какие-то четкие критерии по времени или по своему состоянию. Иначе - дурка.
👍11❤2
По моему личному опыту, скрам-мастер НЕ технарь раскрывается только при наличии технического лидера в команде или если команда сама по себе сильная (типа, мотивированные профессионалы). В в таком случае он делает из хаоса систему и его помощь с фасилитацией очень в тему.
А в среднего уровня команде, ты хоть до смерти закоучи, результата не будет.
А в среднего уровня команде, ты хоть до смерти закоучи, результата не будет.
👍5
Как не деградировать в слабой команде
Где-то с середины моей карьеры я стараюсь не работать в слабых командах. Работа в них - это время в никуда. Научиться у таких коллег нечему, научить и подтянуть их - практически невозможно, да и незачем. Для менеджмента это не видно, денег за это не дают, а твои коллеги на своем перформанс ревью не будут упоминать твои старания.
В слабые команды стоит вписываться только если у тебя есть четкий план и цель. Например:
- Отдохнуть после сложного проекта/поделать дела - работаешь три-четыре часа, остальное время играешь в игры, ходишь в зальчик, готовишься к собесам. Твое раздолбайство все равно никто не заметит.
- Деньги - золотую клетку никто не отменял, семью кормить надо.
- Отрабатываешь навыки - нужна строчка в CV, хочешь потрогать технологию или побыть тимлидом.
Чтобы не выгореть и не деградировать, я себе ставил некоторые критерии выхода. Это помогает в особо тяжелые случаи, когда хочется все послать подальше.
- Временной промежуток - годик поработаю, посмотрю, что дальше будет.
- Критерий выполнения цели, ради которой пошел на дауншифтинг
- "Стоп-слово" - какой-то четкий критерий, что нужно валить. Например, явное выгорание или падение мотивации в плинтус даже для выполнения своих целей.
Мне этот прием помогает не выгорать и держать мотивацию и фокус.
Где-то с середины моей карьеры я стараюсь не работать в слабых командах. Работа в них - это время в никуда. Научиться у таких коллег нечему, научить и подтянуть их - практически невозможно, да и незачем. Для менеджмента это не видно, денег за это не дают, а твои коллеги на своем перформанс ревью не будут упоминать твои старания.
В слабые команды стоит вписываться только если у тебя есть четкий план и цель. Например:
- Отдохнуть после сложного проекта/поделать дела - работаешь три-четыре часа, остальное время играешь в игры, ходишь в зальчик, готовишься к собесам. Твое раздолбайство все равно никто не заметит.
- Деньги - золотую клетку никто не отменял, семью кормить надо.
- Отрабатываешь навыки - нужна строчка в CV, хочешь потрогать технологию или побыть тимлидом.
Чтобы не выгореть и не деградировать, я себе ставил некоторые критерии выхода. Это помогает в особо тяжелые случаи, когда хочется все послать подальше.
- Временной промежуток - годик поработаю, посмотрю, что дальше будет.
- Критерий выполнения цели, ради которой пошел на дауншифтинг
- "Стоп-слово" - какой-то четкий критерий, что нужно валить. Например, явное выгорание или падение мотивации в плинтус даже для выполнения своих целей.
Мне этот прием помогает не выгорать и держать мотивацию и фокус.
👍9
Не учите джунов лидами
Делал я недавно код-ревью у соседнего микросервиса . Код был с душком, я честно давал комментарии почти к каждой строчке. Минут через 15 появилось желание все реджектнуть с резолюцией "нах*р все переписать", потому что так и надо было сделать. В итоге, я сделал approve и merge. Микросервис не мой, а если совсем много проблем будет, то быстрее с нуля все переписать самому.
То рассказ не только про то, что я ленивый зажравшийся чудак, тут есть глубокая мысль.
Менторинг и обучение младшего специалиста лучше всего проводит специалист максимум на одну-две ступеньки выше. Для него это в новинку, он сам учится чему-то новому в процессе. Опытный лид будет это делать либо крайне грубо, либо на отвали. Ему банально скучно объяснять азы кодирования и очень дорого с точки зрения времени.
Есть единственное исключение - это инициатива старшего товарища. То может быть либо личная симпатия, либо обучение обучению (грубо говоря, лид учит сениора делать код-ревью без матов на примере джуна).
Так что если вы лид - не совершайте таких ошибок. Правда, если тебе лень ревьювить код, это совсем не значит, что ты мегасениор. Может, ты и правда лентяй (как я).
Делал я недавно код-ревью у соседнего микросервиса . Код был с душком, я честно давал комментарии почти к каждой строчке. Минут через 15 появилось желание все реджектнуть с резолюцией "нах*р все переписать", потому что так и надо было сделать. В итоге, я сделал approve и merge. Микросервис не мой, а если совсем много проблем будет, то быстрее с нуля все переписать самому.
То рассказ не только про то, что я ленивый зажравшийся чудак, тут есть глубокая мысль.
Менторинг и обучение младшего специалиста лучше всего проводит специалист максимум на одну-две ступеньки выше. Для него это в новинку, он сам учится чему-то новому в процессе. Опытный лид будет это делать либо крайне грубо, либо на отвали. Ему банально скучно объяснять азы кодирования и очень дорого с точки зрения времени.
Есть единственное исключение - это инициатива старшего товарища. То может быть либо личная симпатия, либо обучение обучению (грубо говоря, лид учит сениора делать код-ревью без матов на примере джуна).
Так что если вы лид - не совершайте таких ошибок. Правда, если тебе лень ревьювить код, это совсем не значит, что ты мегасениор. Может, ты и правда лентяй (как я).
👍5
К концу года сделал гайд, как получить максимальную пользу от Performance Review.
https://telegra.ph/Gajd-po-prohozhdeniyu-Performance-Review-10-23
https://telegra.ph/Gajd-po-prohozhdeniyu-Performance-Review-10-23
Telegraph
Гайд по прохождению Performance Review
Наступает конец года и работяги косяками потянулись на PPR - Personal Performance Review (aka Posideli Pogovorili Razoshlis). Поэтому я и решил написать небольшой гайд по его прохождению. Сам я провел под пару сотен таких встреч как манагер, лид и обучающий…
👍7🔥1
Про стандартизацию архитектуры и кодовой базы
Когда я был молодым и горячим, я люто горел от корпоративных стандартов в разработке. Приходишь ты такой в Кровавый Энтерпрайз, а там огромная портянка требований к коду, совершенно идиотские правила Sonarqube и покрытия тестами.
Я небезосновательно считал это помехой для быстрой и качественной разработки. Ну что за идиотизм, когда сборка заваливается от пары идиотских Code Smellов и нужно тратить время на прописывание эксклюдов. В ту же степь - test coverage 85%.
К чему я про это пишу? Сейчас я сижу и вылизываюяйтесты своего микросервиса до характерного блеска, пока коллеги в пожаре дописывают свою часть. Потому что я не могу быстро переключиться и напилить фичу в их кодовой базе - на вникание и банальный дебаг кода у меня неделя уйдет. Потому что у нас же микросервисы и каждый из разрабов пишет свое уникальное видение этого паттерна.
Так что опытные коллеги были тогда правы. И в любом проекте, где я имею власть, я прописываю эти самые стандарты. Это можно делать через документы (самый плохой способ) или через quickstart/backbone (это когда можно запулить код и начать писать функционал).
Когда я был молодым и горячим, я люто горел от корпоративных стандартов в разработке. Приходишь ты такой в Кровавый Энтерпрайз, а там огромная портянка требований к коду, совершенно идиотские правила Sonarqube и покрытия тестами.
Я небезосновательно считал это помехой для быстрой и качественной разработки. Ну что за идиотизм, когда сборка заваливается от пары идиотских Code Smellов и нужно тратить время на прописывание эксклюдов. В ту же степь - test coverage 85%.
К чему я про это пишу? Сейчас я сижу и вылизываю
Так что опытные коллеги были тогда правы. И в любом проекте, где я имею власть, я прописываю эти самые стандарты. Это можно делать через документы (самый плохой способ) или через quickstart/backbone (это когда можно запулить код и начать писать функционал).
👍6