Move Fast and Break Things 🤯

Опубликовано 31 июля 2020 г.

Карьера Программирование Соберись, тряпка

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

А я от этого вот прям страдаю. Лучше всего я работаю в условиях, когда моя модель мира достаточно точна для оценки сложности задач и понимания, “куда забить гвоздь”. А тут ровно наоборот. Ничерта не понятно, ещё и меняется всё постоянно. А некоторые решения приняты и вовсе бог знает кем неизвестно когда.

Для справки: мы делаем десктопное приложение на электроне с redux-saga для сайд-эффектов, которое смотрит в локальную sqlite, которая в свою очередь синхронизируется с внешним миром через написанный на C транспорт и C++ прослойку в nodejs. Не сказать, что я не понимаю код — понимаю. Но не вижу big picture за всем этим, особенно когда нужно сделать что-то нетривиальное.

При этом стандартная (и даже логичная) позиция коллег: move fast and break things. Ну то есть лезь напролом и чини, когда сломается. Это действительно позволяет достигать хоть какого-то результата. Немного tech debt тут и там — и готово. В целом работает, хотя и приходится заставлять себя.

Но вот о чём это заставляет меня задуматься: кажется, что всего 5-10% разработчиков в компании процентов на 80 понимают системы, с которыми работают. Остальные плетутся где-то в хвосте, ещё больше спутывая и без того запутанные следы здравого смысла. И бог бы с ним, с кодом — гиганты заплатят со своих сверхприбылей, кто-то придёт и перепишет через пару лет.

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

Или я вообще где-то по пути свернул не туда и вместо принятия чуть ли не экспоненциально растущей сложности систем вдруг решил, что в индустриальном программировании может быть как в сайд-проекте?

Читать дальше