Заявление в духе: надежность софта обеспечивается движением атомов.
Код не самобытен, он зависит от многих факторов. В частности от тестирования не в последнюю очередь.
Если программа «должна» — что угодно(например, работать в условиях нехватки памяти) должна, то и надо ее проектировать с учетом ее особенностей.
Речь же не о специфичном функционале, а об общей обработке исключений.
И в данном случае когда я говорю «исключение» я имею ввиду «ошибку». Ну просто потому, что здесь все обсуждения вокруг исключений-ошибок.
Моя основная мысль — никакие супер-пупер подходы к обработке исключений-ошибок не дадут качественного софта на выходе, если нет нормально налаженного механизма тестирования.
У нас почему-то руководство все чаще и чаще приходит к крамольной мысле, что отдел тестирования не нужен. Я думаю это связано с использованием языков с GC, которые очень многие ошибки сглаживают и софт начинает «выглядеть» надежным.
Кавычки не случайны. То что софт не падает, не означает что он надежный. Это означает что он не падает и не более того. Что с ним происходит внутри — большой вопрос.
Но эффективные-менеджеры довольны и этим: софт отлично работает! ни одного краша или ANR! Отдел тестирования не нужен! А то, что софт работает через *опу — все равно с первого взгляда не видно…
О каком пользователе речь?
Еще раз: надежность софта обеспечивается с помощью QA. Исключительно.
Для QA сложные обработки ошибок не нужны.
До пользователей не должен доходить софт с ошибками.
Все что вы описали делается через стандартные игровые сервисы гугла и эпла. И даже больше, тот же эпл прямо запрещает использовать сторонние API для этих функций.
Да, не хватает обязательного комментирования к минусам…
Иногда сидишь и думаешь, я идиот или тот кто меня минусует… С комментарием было бы сразу понятно. Пусть он даже анонимный был бы. Как минимум это позволило бы совершенствоваться…
Да че уж в Эфиопию ездить.
Россия, Самара, перекресток Кирова и Победы.
У нас туда возят сдающих на права, если завалить хотят. Его в приципе нельзя проехать по правилам.
Именно так.
Поэтому основные законы доносят родители в начале жизни ребенка.
Также в школах проходят основы ПДД и других законов.
Мало того, ГИБДД регулярно пишет разъяснения по ПДД, в том числе в картинках: www.kolesa.ru/article/2012/04/20/gibdd_govorit_pokazyvaet_i_shtrafuet
Странно, что у Вас это удивляет. Это нормальный подход, когда цель донести информацию, а не запутать в юридических терминах.
Ну и да, сколько Вы знаете людей, которые читали УК целиком? Вы сами читали?
Вы хотите чтобы ваше пользовательское соглашение читали? ОТлично — прикрепите к нему краткую выдержку с описанием основных моментов нормальнычм человеческим языком.
Как минимум пользователь увидит общую картинку и если уже возникнут вопросы — полезет детально читать конкретный пункт соглашения.
Моей жизни(как и большинства людей) не хватит чтобы детально прочитать все соглашения с которыми приходится иметь дело.
Да и ладно прочитать. Понять юридический язык призванный затыкать все лазейки стоит весьма не малых затрат времени и сил, особенно у людей далеких от юриспуреднции.
Отдельный способ, который позволит значительно улучшить восприятие пользователями лицензионного соглашения — это интерактивный тест.
К примеру вот тест для публикации в AppStore: www.makayama.com/checklist.html
Хотите чтобы пользователи читали соглашение? Нет проблем, сделайте его удобочитаемым.
Паблишеры очень бережно относятся к своей собственности.
Многие закрытые проекты и просто права на вселенные лежат взакромах, даже если ничего не стоят.
Что-то вроде: «А вдруг когда нибудь пригодится».
Паблишеру нет никакого смысла открывать материалы, тем более если есть хотя бы 0.000001 шанса, что материалы могут пригодиться.
0.00001 — это все равно больше чем 0, который будет получен в результате открытия материалов.
Код не самобытен, он зависит от многих факторов. В частности от тестирования не в последнюю очередь.
Речь же не о специфичном функционале, а об общей обработке исключений.
И в данном случае когда я говорю «исключение» я имею ввиду «ошибку». Ну просто потому, что здесь все обсуждения вокруг исключений-ошибок.
Моя основная мысль — никакие супер-пупер подходы к обработке исключений-ошибок не дадут качественного софта на выходе, если нет нормально налаженного механизма тестирования.
У нас почему-то руководство все чаще и чаще приходит к крамольной мысле, что отдел тестирования не нужен. Я думаю это связано с использованием языков с GC, которые очень многие ошибки сглаживают и софт начинает «выглядеть» надежным.
Кавычки не случайны. То что софт не падает, не означает что он надежный. Это означает что он не падает и не более того. Что с ним происходит внутри — большой вопрос.
Но эффективные-менеджеры довольны и этим: софт отлично работает! ни одного краша или ANR! Отдел тестирования не нужен! А то, что софт работает через *опу — все равно с первого взгляда не видно…
Простите за сумбур. Накипело.
Еще раз: надежность софта обеспечивается с помощью QA. Исключительно.
Для QA сложные обработки ошибок не нужны.
До пользователей не должен доходить софт с ошибками.
Никакая обработка ошибок не сможет заменить QA-отдел.
В час пик там вообще делать нечего.
Иногда сидишь и думаешь, я идиот или тот кто меня минусует… С комментарием было бы сразу понятно. Пусть он даже анонимный был бы. Как минимум это позволило бы совершенствоваться…
Россия, Самара, перекресток Кирова и Победы.
У нас туда возят сдающих на права, если завалить хотят. Его в приципе нельзя проехать по правилам.
Поэтому основные законы доносят родители в начале жизни ребенка.
Также в школах проходят основы ПДД и других законов.
Мало того, ГИБДД регулярно пишет разъяснения по ПДД, в том числе в картинках:
www.kolesa.ru/article/2012/04/20/gibdd_govorit_pokazyvaet_i_shtrafuet
Странно, что у Вас это удивляет. Это нормальный подход, когда цель донести информацию, а не запутать в юридических терминах.
Ну и да, сколько Вы знаете людей, которые читали УК целиком? Вы сами читали?
Единственное что хромает, ИМХО, так это цена…
Как минимум пользователь увидит общую картинку и если уже возникнут вопросы — полезет детально читать конкретный пункт соглашения.
Моей жизни(как и большинства людей) не хватит чтобы детально прочитать все соглашения с которыми приходится иметь дело.
Да и ладно прочитать. Понять юридический язык призванный затыкать все лазейки стоит весьма не малых затрат времени и сил, особенно у людей далеких от юриспуреднции.
Отдельный способ, который позволит значительно улучшить восприятие пользователями лицензионного соглашения — это интерактивный тест.
К примеру вот тест для публикации в AppStore:
www.makayama.com/checklist.html
Хотите чтобы пользователи читали соглашение? Нет проблем, сделайте его удобочитаемым.
Многие закрытые проекты и просто права на вселенные лежат взакромах, даже если ничего не стоят.
Что-то вроде: «А вдруг когда нибудь пригодится».
Паблишеру нет никакого смысла открывать материалы, тем более если есть хотя бы 0.000001 шанса, что материалы могут пригодиться.
0.00001 — это все равно больше чем 0, который будет получен в результате открытия материалов.