- kkolyan
- Постоялец
1 frag / 2 deaths
> Его даже не сразу обнаружишь.
Ты делаешь ПО для спутников или медоборудовпния? В вебе чаще другие приоритеты. Если у тебя 3000000 юзеров и ни один не жалуется, если баг не открывает уязвимостей - значит ничего плохого и нет что обнаружат не сразу. Не потому что плевать на баги, а потому что всегда есть что-то важное, что нужно конкретным пользователям (за что они готовы платить) и на что более рационально тратить усилия разработчиков.
1 frag / 2 deaths
> А косяки лучше обнаруживать как можно раньше
При прочих равных - да. Но когда ценой раннего обнаружения не супер-важного пользовательского бага является полный отказ сервиса для значительной группы пользовптелей... Репутационный и финансовый урон явно того не стоит.
1 frag / 2 deaths
диллема fail-fast vs fail-safe не решается так универсально как ты говоришь - она зависит от многих факторов.
kkolyan
> Если у тебя 3000000 юзеров и ни один не жалуется, если баг не открывает уязвимостей - значит ничего плохого и нет что обнаружат не сразу.
Да просто будет "ой чёто галочка не работает ну и пофиг"...
1 frag / 2 deaths
окей, будет, в чем проблема? не все сводится к городости программистов, этож коммерческий софт.
kkolyan
Будут годами незамечаемые проблемы в минорных багах
Короче как с хвостиками массивов
1 frag / 2 deaths
> Будут годами незамечаемые проблемы в минорных багах
а лучше чтоб каждое обновление было русской рулеткой с отказом сервиса для значительного кол-ва пользователей? если на каждую потенциальную проблему вместо минорного бага закладывать отказ сервиса - так и будет.
kkolyan
> а лучше чтоб каждое обновление было русской рулеткой с отказом сервиса для значительного кол-ва пользователей?
Да, тогда больше шансов на тестировании заметить
1 frag / 2 deaths
> Будут годами незамечаемые проблемы в минорных багах
> Короче как с хвостиками массивов
Не будет годами, если в логах будут желтые ворнинги. Будет только если вообще молча обходить.
1 frag / 2 deaths
Разработкой какого рода продуктов ты занимаешься, если не секрет?
kkolyan
25 см в холодной воде
1 frag / 2 deaths, он же тебя не про опыт, а про область спросил. Потому что если десктопные приложения, типа игр - то правильнее твоя стратегия.
А если сервисы на серверах, то в сумме предпочтительнее все же "пусть с ошибками, но работает, чем гарантированно без ошибок, но с простоем в несколько суток после добавления новых фич".
Dmitry_Milk
Статические анализаторы кода
А вот тот эпичный тред: https://gamedev.ru/flame/forum/?id=122958
1 frag / 2 deaths
> А вот тот эпичный тред
Ну как бы да. Если круглосуточно обслуживающие сервисы - то владельцы сервиса охотнее пойдут на костылирование (пусть хоть хвостиками массивов), чем на детальный разбор с остановом обслуживания.
Блин, ребята, в вебе оба подхода нормально работают — очень зависит от конкретной задачи, контекста, команды.
Иногда действительно лучше упасть, чем долго держать ошибку работаютщей:
1. На порядки быстрее обратная связь от вселенной.
2. Софт поддерживается ~100% рабочим — упали, пофиксили, опять считаем рабочим.
3. Скрытые баги накапливаются и сказываются на SLA (и значит бабле), морали команды, искажают метрики, жрут время саппорта, команды, клиентов — всех.
4. Вы хрен сделаете метрики под каждый возможный косяк, это вообще нереально.
5. В прод критический софт отправляется итерационно, расскатывается на небольшую часть юзеров, потом на большую, потом на всех.
Я бы даже сказал, что для критического ософта лучше упасть, чем годы сношать мозги тысячами косяков, которые возникают по цепочкам зависимостей и неотслеживаемы.
Соответственно, чего там у них упало — это не проблема конкретного разработчика или языка, а проблема процессов в которых происходили изменения, приведшие к проблеме: анализаторы кода, код-ревью, юнит-тесты, интеграционные тесты, тестирование изменений конфигов на изолированных стендах, раскатка на небольшой процент юзеров, мониторинг и алертинг, дублирование ключевых систем — вот это всё (которое в каком-то виде есть скорее всего) пропустило косяк — бывает — это ж вероятностный процесс. Все ошибаются, если вы держите на себе половину интернета — ваши косяки будут ярче заметны. Упали — встали — отряхнулись — пошли дальше.
Это софту для марсоходов падать нельзя, потому что его фиг обновишь, а интернетам можно.
Вернитесь к обсуждению Rust :-D
Tiendil
> зависит от конкретной задачи, контекста
Вот и я так считаю. Но контекст-то известен.
https://www.cloudflare.com/business-sla/
> 1.1 100% Uptime. The Service will serve Customer Content 100% of the time without qualification.
Tiendil
> Скрытые баги накапливаются и сказываются на SLA (и значит бабле)
лол, что это за SLA, в рамках которого даунтайм лучше минорных багов?
Tiendil
> для критического ософта лучше упасть, чем годы сношать мозги тысячами косяков
для критического - да. но справедливости ради - выбор не такой. выбор между "годы сношать мозги тысячами косяков" и "внезапный даунтайм каждый второй релиз". для каких-то задач может быть все еще приоритет для второго, но все же.