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

Помимо советов которые я привел в посте, я также хочу посоветовать канал моего коллеги и друга Сани. Он у себя в канале «Я Delivery Manager 🚀» простыми словами разбирает:

👉 Как метрики (Lead Time, Cycle Time, WIP) реально помогают?
👉 Зачем нужны процессы (и когда не нужны 👀)?
👉 Как сделать так, чтобы задачи закрывались, а не тухли в бэклоге?
👉 Что работает в продуктовой и заказной разработке?

Помимо этого у него также можно спросить как выбрать "Ниву", ну это так к слову @iDeliveryManager

erid: 2VtzqwpX7WA

За последние 3–4 месяца у меня как минимум пятеро знакомых разработчиков уволились «в никуда», просто в свободное плавание. Именно сами ушли, а не под сокращение попали.

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

Во-вторых, у меня, конечно, это немного в голове не укладывается: с одной стороны, у нас сейчас очень суровый рынок, но при этом часть разрабов такие – «а похуй, я на каникулы».

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

Изучая системный дизайн, у меня родилось ещё одно определение слова "Архитектура ПО". Архитектура ПО – это ответ на вопрос: что будет, когда отъебнёт X. Не если, а когда!

Меня очень забавляют разрабы, которые страшно гордятся тем, что сделали проект "без единой библиотеки". Как вид спорта – выглядит интересно, для пет-проектов даже прикольно. Но если речь про рабочий продакшн – это очень сомнительная история.

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

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

Писать своё стоит тогда, когда у вас уже есть бюджет и вы чётко понимаете, почему готовое вас не устраивает.

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

Сразу уточню: я не имел в виду, что вы на каждый чих должны тащить библиотеку. Подключать зависимость ради одной функции – абсурд. Давайте такие приколы оставим фронтендерам, у них так принято.

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

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

Мне довелось участвовать в проекте, где решили написать свою RxJava. Итог – 10 из 10. Разумеется, я про количество свечек за здравие того разработчика, который это придумал.

И всё равно вы никак не избавитесь от сторонних зависимостей, как бы ни хотели. Вы же не будете писать свой HTTP-клиент с нуля? Или своё решение для асинхронщины? Или собственную БД?

А если смотреть шире, на уровень системного дизайна, то ситуация та же. Вы не начнёте проект со своей аналитики, собственной "выделенной машины" в качестве сервера или своей рекламной системой. Если у вас не корпорация, вы всё равно будете зависеть от сторонних сервисов. И чаще всего это в разы дешевле, чем писать самим.

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

Короче, ребята, смотрите: многие, наверное, пробовали Rust, понимали, что довольно сложно разобраться в модели работы памяти, и забивали на него. Ну, по крайней мере, так было со мной. Плюс я не знал, где его можно применить.

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