2022-05-16 11:00:14
Качество ПО в большинстве своём крутится вокруг одной простой штуки — обработки ошибок. Хорошие учебники по программированию учат нас тому, что код, который ты только что научился писать, может сломаться. И обязательно сломается. Сломается сам, и сломает приложение в котором находится — если ты это не предусмотришь. При этом учебники, даже хорошие, обычно показывают, как можно обрабатывать ошибки, но не показывают, как надо. В основном потому, что программисты понятия не имеет, как надо обрабатывать большую часть исключительных случаев.
Все проекты, на которых я когда-либо работал, отличались тем, что в них был полный пиздец с обработкой ошибок. Все вот эти влажные мечты про единую стройную систему, которая заранее предопределяет, что делать, когда что-то пошло не так, не работают на практике. На практике работает вот что — каждая конкретная потенциальная ошибка — это повод хорошенько подумать, сходить к бизнесу, и вылезти далеко за пределы программистской компетенции.
Да, есть ряд очень понятных штук — ну как минимум мы знаем, что ошибки надо логгировать, мы понимаем, что есть те, с которыми дальше работать нельзя и есть те, о которых надо как-то уведомить пользователя, но ин женерал, проблема в том, что поведение приложения при любой ошибке — это не технический, а продуктовый вопрос. При этом ребята, которые продукт продумывают, недостаточно компетнтны, в отличие от нас, чтобы вообще понять — а какие ошибки могут вообще возникнуть.
Получается, что работать оно должно примерно так: ты получил задачу, наебенил код, понял все возможные проблемы, пришёл с ними к бизнесу, вы вместе подумали, проработали поведение на случай каждый из них — и ты пошёл себе доебенивать свой код.
Это процессуально невозможно. Попробуй так жить, и окажешься сидящим на десятке веток недоработанного кода, будешь сидеть и ждать, пока чертов бизнес даст тебе ответы на вопросы, а разработка двигаться не будет.
Поэтому мы молчаливо заигнорили проблему. В итоге, какие-то критичные штуки мы и правда утрясаем с бизнесом, а большую часть возможных проблем разруливаем сами — как умеем. А умеем хуёво. Обоорачиваем всё в трайкетчи, проглатываем, выкидываем нотификейшны, видим баги на борде, и снова костылим — системы нет и не предвидится. У тебя сидит условный джун, и принимает на месте решение, как поведет себя гигантская система в случае, если файл, который точно должен быть на диске, на диске отсутствует. Этот джун наебётся. Закономерно. И мы потом получим багу на борде. Вот так оно работает.
Мне кажется, это херня. Мне кажется, не решать проблемы, потому что не знаешь как — это ещё куда не шло, а вот решать их заведомо неправильно, потому что не знаешь как — никуда не годится. Процессы, такие какие они сейчас есть, не результат системного продумывания — оно тупо так сложилась. Я считаю, адекватный бизнес можно убедить в том, что это так не работает — и заставить его давать нам ответы быстро. Думать об ошибках при постановке задач ещё до того, как подумали о самой задаче. Не перекладывать на инженеров продуктовые задачи. Или перекладывать — но учить их решать такие задачи.
Потому что то что получается без этого — вы видите сами: мы тонем в багах. Наши приложения тонут в багах, инструменты, на которых мы их делаем, тонут в багах, основная часть нашей работы — это исправление собственных косяков. И я не верю, что это — нормально, и что по-другому нельзя.
2.7K views08:00
М
