Антипаттерн «Кадастровый инженер»

Хочет всё размежевать, чтобы не слиплось. Считает, что разделение по репозиториям и приложениям — панацея от скверны лапшекода. Мол, щас всё растащим, и никто не сможет использовать Х в У.

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

Крайнее проявление — вынести в отдельный репозиторий каждый компонент единой системы: тесты, вёрстку, сервисы, скрипты миграций и т.д. Тогда вашей работой становится жонглирование ветками и толкание локтями коллег в репозиториях в попытках собрать всё воедино хотя бы на CI-сервере.

Чтобы разрез сильно не болел, нужно научиться искать логические границы и уметь пресекать нарушения. Потом дать границам устояться, и только потом отрезать. Попытка что-либо отрезать в бардаке приводит к ещё большему бардаку.

Как понять, что разделили неправильно? Когда для одной задачи вам приходится коммитить сразу в несколько репозиториев и в строгой последовательности. У репозиториев оказался слишком высокий coupling. Да, представьте coupling и cohesion применим и в рамках git-репозитория.

Небольшая заметка о стрессоустойчивости и вреде гиблых проектов https://vk.com/@-200496256-timlid-ozverel

Ребята из Postgres Professional написали неплохую книгу «PostgreSQL 16 изнутри»

Какие темы охватывает книга:
— Устройство shared buffer
— Как работает WAL
— Как выполняются запросы
— Зачем нам вакуум
— Как работают индексы
— Как устроен MVCC
— etc

Всего 665 страниц годноты на русском. Кому лень читать — у ребят есть ютуп-канал, посвящённый той же теме

Просвещайтесь!

#полезнота

Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг:

Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно.

В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.

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

Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3

К посту про SQL. Пока лазил на сайте Postgres Professional, наткнулся ещё на одну интересную книгу — «Путеводитель по базам данных».

Что внутри:
— Какие структуры данных используются для построения СУБД
— На каких алгоритмах построены распределённые СУБД
— Репликация и бекапы
— Журналирование
— Управление доступом

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

#полезнота

На следующей неделе планируем провести стрим на тему «Внедрение DDD на практике — профиты и проблемы».

К нам в гости придет наш товарищ Константин Шибков, старший Java разработчик СДЕК, автор курсов и статей по разработке, соорганизатор митапа про бережливые бизнес процессы AgileUfa и клуба разработчиков JavaKeyFrames.

Мы обсудим как Константин внедрял архитектурные подходы и паттерны и узнаем, что из этого вышло.

Ссылку пришлем позже, приходите и задавайте вопросы 🙂

Предварительно, запланировали стрим в четверг 31 октября в 18:00 МСК

Напоминаем, что сегодня состоится встреча. Ссылку скинем перед началом. Не пропустите!

Погнали! https://youtube.com/live/HYI5XzQFE3U?feature=share

Мы не знаем кто автор, но это просто шедеврально

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

Если видос показался полезным — поделитесь с братюнями. И подпишитесь на канал, конечно же

Приятного просмотра!

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

⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать).

Приятного просмотра!

Инфляция тайтлов: 18-летние синьоры уже реальность
(*пост не ставит целью оскорбить или унизить кого-либо)

И к сожалению эта напасть касается нас всех.

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

(Продолжение ниже)

В продолжение поста

Громкому тайтлу можно меньше платить

Громкий тайтл может перекрыть разницу в деньгах, так что получать Principal Software Architect & Visionary Technologist может меньше, чем обычный Developer. Ну и ещё это престижно звучит: уезжал из деревни студентом, а вернулся тем, кого и назвать сразу не получается. Почёт и уважение обеспечены, — думает уязвимый к брехне человек и принимает офер.

Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией.

И теперь ничего не понятно

Нельзя наверняка сказать, чем занимается Senior Staff Software Engineer. Где как. Одни компании требуют писать код в 2 раза быстрее, чем Senior Developer. Другие ждут на эту позицию динозавра с 15 годами опыта. В общем, пока не допросишь HR, не поймёшь, что скрывается за названием позиции. А увидя должность Associate Vice President, типичный разработчик вообще пройдёт мимо, подумав, что не про него. И совершенно зря.

Только Executive Director не пишет код. Даже Сеньер Вице-Президент код писать должен.

Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂

Ещё один способ оценки квалификации

Если вы руководите не только собой, вам рано или поздно потребуется как-то оценивать и называть квалификацию сотрудников. Самая живучая практика — модель Junior/Middle/Senior/Principal/etc. Но, как мы все понимаем, эти слова мало что говорят о человеке:

— В каждой конторе свой уровень сложности проектов, и что для одних Senior, для других — Middle+

— Инструментов много, владеют ими все по-разному. Вполне нормально, когда Senior не владеет чем-то, что на конкретном проекте не нужно.

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

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

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

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

Наше ретро. Вопрос к читателям: а вы его проводите? ИМХО лучше проблемы фиксировать и решать по мере поступления, а не устраивать сеанс групповой психотерапии на котором все поноют и разойдутся с нулевым результатом