Здравствуйте, _newcomer_, Вы писали:
__>>>Вы в своем уме? __>>>Или вы студент, пишущий учебные приложения или бесполезный софт под андроид? __>>>Какой нахрен убивать приложение? Мы о продакшене и промышленном ПО говорим от которого сотни и тысячи людей, выходящих каждый день на работу, на заводы, зависят?
vsb>>Поэтому приложение, которое ведёт себя неправильно, должно умереть как можно быстрее. По крайней мере та его часть, которая может перезапуститься с чистого листа. Иначе оно испортит файлы, БД, выдаст неверный диагноз, отпилит голову рабочему.
__>>>Приложение должно жить в идеале бесконечно, при любых обстоятельствах, иначе "приедут дяди из службы безопасности заказчика и убьют вас".
vsb>>Приложение может выбросить ошибку в любой точке. Например из-за out of memory. Если ваши системы перестают обслуживать людей из-за out-of-memory, это неправильно. Есть много способов перезапускать приложение или thread или задачу при возникновении ошибок.
__>Давайте не будем валить в одну кучу OutOfMemory и непроверенные параметры функций из-за отключенных ассертов. __>devcoach предлагает использовать их повсеместно и, как следствие, поведение системы будет непредсказуемым в куче мест.
Я знаю про две разные позиции в этом споре. Одни хотят отключать все проверки и уповать, что даже если что-то пойдёт не так, авось кривая вывезет и нормально будет продолжать работать. На самом деле надежда не тщетная, многие программы так работают и вроде обычно всё нормально, кривая вывозит, в джаве это тем более работает, т.к. память сложно испортить и целый класс undefined behaviour исчезает. Но я всё равно считаю, что приложение или его кусок должен умирать как можно быстрее при обнаружении неверного функционирования. Естественно, если это нужно, оно должно перезапускаться тут же, необслуженные запросы должны продолжать обслуживаться и т.д. Это всё реализуемо. Если мы говорим про web app, например, достаточно просто выйти из метода сервлета, залоггировав все доступные данные для анализа, а там app server поймает исключение, проигнорирует его и продолжит выполнять следующие запросы.
__>И даже если что-то идет совсем "не так" приложение должно выдать вразумительное диагностическое сообщение, являющееся руководством к действию для пользователя/администратора.
Вразумительное диагностическое сообщение это "в программе обнаружен баг, обратитесь к разработчикам, приложив содержимое папки logs".
__>Как вы собираетесь подробно информировать пользователей (и разработчика через лог) о случившемся, если полагаетесь на ассерты и перезапуск приложения по каждому чиху?
Не понял вопроса и замечания про каждый чих. Сработал assert — вылетает Error, его ловим в нужном месте, логгируем и кидаем дальше или завершаем выполнение. По каждому чиху они не должны срабатывать в нормально написанном приложении, потому что это прямая индикация бага.
Здравствуйте, devcoach, Вы писали:
D>Здравствуйте, StanislavK, Вы писали:
SK>>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае. D>Вот это ваше утверждение есть ни что иное, как непонимание классической мудрости "premature optimization is root of all evil". Тут дело вот в чем.
Ах вот оно...
D>Дилетант считает, что premature optimziation — это любая оптимизация кода, которая сделана до того, как в этом месте появилась проблема с перфомансом.
Да, есть я нами, дилетантами такая проблема... все потому, что книжкам мало верим.
D>Опытный же программист знает, что premature optimziation — это оптимизация кода, которая сделана до того, как в этом месте появилась проблема с перфомансом И на эту оптимизацию было затрачено много усилий. Что такое "много" — зависит от контекста конкретной задачи.
Вот тут я ничего не понял. Это к чему? Хотя нет, понял. Просто вместо того, чтобы говорить о том, о чем я, гораздо проще подменить понятия и поговорить об определених, ну и заодно вспомнить какие все вокруг делетанты... Если все же прочитать то, что я написал — там не слова про "premature optimization". Я про то, что не надо говорить о перформансе вне контекста. Не надо утверждать, что что-то чего-то там замедляет без указания _конкретного_ случая и влияния этого _конкретного_ случая на приложение.
D>Поэтому, если я знаю, что я уже вроде как все отвалидировал в паблик методах, то я не буду это валидировать еще 100500 раз в своих внутренных методах. Вместо этого я просто поставлю внутри ассерт, и все. Формально это "оптимизация", так как в продакшне вмеcто 100500 + 1 раз валидация будет вызвана 1 раз. Но это ни в коем случае не "premature optimization", так как я не затратил на это сил. Я ничего не рефакторил, не делал новые тикеты, не писал никакие дополнительные тесты, и т.д. Я просто следовал здравому смыслу, потратив на это 1 минуту своего времени.
Как вам уже говорили — лучше валидировать, тем более, что все равно валидируете. Как к этой рекомендации отнестись — ваще дело. К счастью, не думаю, что мне придется поддерживать вашу систему...
Здравствуйте, devcoach, Вы писали:
D>Никаких .... Так же, как не мои проблемы, если он ...
Я это изначально и предполагал
Как видно, вы не несете никакой ответственности перед заказчиком руководством, так что проблемы продакшена от вас далеки.
На этом считаю и надо закончить разговор.
Здравствуйте, devcoach, Вы писали:
D>Здравствуйте, StanislavK, Вы писали:
SK>>Почему не вызывать второй раз? В чем проблема? D>Зачем дважды вызывать одно и то же? Про DRY слышали? А с перформанс проблемами когда-нибудь сталкивались? То, что хорошо в девелопменте, не всегда хорошо в продакшне, ваш кэп.
Куда нам... у нас весь перфоманс параметры валидирует
SK>>Насчет, дублирование кода, вообще не понял. В вашем примере код вполне дублируется. То, что вы что-то выразили другим синтаксисом, это не значит, что дублирования нет. У вас там все те же проверки, только вместо того, чтобы их везде делать одинаково, вы решили, что простым быть не модно, надо те же проверки делать по-разному, в зависимотри от модификатора на методе... D>Эээ, нее, это не дублирование кода. Это тест внутри кода, да. Это "активный комментарий" внутри кода, да. Но это ни в коем случае не повторение логики из публичного метода. Хотя бы потому, что эта "повторяющаяся логика", как вы говорите, не будет вызвана в продакшне.
В вашем примере явное дублирование. Давайте другой пример, обсудим.
Здравствуйте, _newcomer_, Вы писали:
__>Как вам помогут отключенные в продакшене ассерты от такого неправильного использования? __>Вы как раз и получите непроверенные параметры в своей функции, которая рассчитывала, что их "ну никак не может быть". __>И ваш продакшен накроется медным тазом.
Никакого противоречия нет. У меня есть билд сервер, который при каждом комите/сборке гоняет тесты. Разумеется, на нем выставлен -ea. Если я хреново покрыл тестами новую логику, и у меня нет ассертов, то мне никто не поможет. Если же у меня есть ассерты в каком-то общем внутреннем методе, то они могут оказать мне дополнительную помощь. А могут и не оказать. Но уж точно не повредят.
__>Продолжите мысль, что будет тогда в продакшене с отключенными ассертами?
То же, что будет в продакшне с отлюченными тестами — ничего страшного.
__>зачем же. Достаточно, исходя из описанного вами, иметь в команде хотя бы одного разработчика, который понятия не имел, __>что перед вызовом вашей функции нужно проверить 100500 параметров, которые нужны вам там внутри и вы это чекаете через ассерты, __>а ему было невдомек, потому что лично ему они нафиг не уперлись и вам он их только пробрасывает.
Во-первых, есть описание задачи. Во-вторых, есть code review. В-третьих, есть юнит-тесты. Он хорошо покрыл свою задачю юнит-тестами — они свалились, он добавил явные недостающие явные проверки. Он плохо покрыл свою задачу юнит-тестами — они не свалились, но может быть помогут ассерты.
Неправильное выполнение задачи программистом — не повод 100500 раз дублировать код.
Здравствуйте, vsb, Вы писали:
vsb>Я знаю про две разные позиции в этом споре.
Предлагаю внимательно перечитать топик "по ролям" и кто, что предлагал.
StanislavK и я высказывались за неиспользование ассертов, т.к. "поведение должно быть одинаковым и при разработке и в продакшене", а с отключаемыми ассертами в продакшене это не так.
Кроме того, если их не отключать, то это как раз упование на "само вывезет", что недопустимо в промышленных системах.
Если ты предполагаешь что тут может быть проблема = обработай ее явно, а не кидай исключение, которое никто не перехватит.
devcoach же предлагал повсеместно "правильно" использовать ассерты, отключая их в продакшене. Якобы ассерты позволяют ему тестировать приложения, находя баги.
И основной моей мыслью было, что его упование на нахождение багов при разработке — ошибочно.
А отключение ассертов приводит к "само вывезет", что недопустимо.
Напомню вам, что я выступаю за отказ от использования ассертов вообще, в пользу явных проверок и реагирования.
Мне без разницы, включены они в продакшене или нет, так как по мне их вообще быть не должно.
А то складывается впечатление, что вы забили с чем спорите.
D>Никакого противоречия нет. У меня есть билд сервер, который при каждом комите/сборке гоняет тесты. Разумеется, на нем выставлен -ea. Если я хреново покрыл тестами новую логику, и у меня нет ассертов, то мне никто не поможет. Если же у меня есть ассерты в каком-то общем внутреннем методе, то они могут оказать мне дополнительную помощь. А могут и не оказать. Но уж точно не повредят.
Отличная логика. Сделаю что-то, что может помочь, а может не помочь.
Но все равно сделаю, создав у себя (и еще кого-то) мнимую уверенность что я что-то проверил... или не проверил....
Отличный подход в промышленных системах.
D>Во-первых, есть описание задачи. Во-вторых, есть code review. В-третьих, есть юнит-тесты. Он хорошо покрыл свою задачю юнит-тестами — они свалились, он добавил явные недостающие явные проверки. Он плохо покрыл свою задачу юнит-тестами — они не свалились, но может быть помогут ассерты. D>Неправильное выполнение задачи программистом — не повод 100500 раз дублировать код.
Вы когда говорите, такой впечатление, что не в реальном мире девелопментом занимаетесь, а начитались книжек и из них умные мысли высказываете.
Или еще студент. Бррр.....
Вас почитать, так падание системы — это что-то само собой разумеещееся, перезапустил и все.
Я по этому вас и спрашивал (но вы не ответили), из какой области ваше ПО, что оно из себя представляется.
Не надо про NDA, описать в общем можно всегда.
Здравствуйте, vsb, Вы писали:
SK>>Еще один. Может тогда расскажете про цель и про красивый синтаксис? Только без повторений "devcoach"-а, плз, не поленитесь прочитать ветку. vsb>Цель — проверять инварианты и убивать приложение как можно раньше при их нарушении, чтобы предотвратить дальнейшее некорректное поведение и упростить поиск бага.
Да вы что? И правда, ни один "if" с таким не справится, надо срочно ассерты делать.
vsb>Красивый синтаксис — про него можно прочитать в любом учебнике.
не знаю, не читал. Вообще не красиво отсылать к таким источникам. Мы тут все, я надеюсь, взрослые люди. Просто поясните, что вы имели ввиду. Я немного удивлен данным утверждением, так как это примерно то же что сказать, что у "if" красивый синтаксис. Сказать это, конечно можно, но звучит странно...
Насчет того, насколько assert удобен для отлова ошибок, вообще — он не позволяет добавить никакой информации, кроме самого условия, что его делает менее полезным при отдадке проблем, чем нормальные проверки.
SK>>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае. vsb>Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать.
Если так подходить к перфомансу, то ява не для вас. Пишите на на чем-то без gc и vm оверхедов. Они отъедают гораздо больше, чем проверка на null.
vsb>Если проверки сложные, может и ощутимо замедлять. Кому то это важно, кому то нет. Можно отключать выборочно для классов.
Все правда.
vsb>Отличный инструмент, гибкий и удобный, что тут ещё можно сказать.
Проверка, сама по-себе, да отличный инструмент, но assert — в баню.
On 10.01.2014 13:25, _newcomer_ wrote: > D>Никаких .... Так же, как не мои проблемы, если он ... > > Я это изначально и предполагал > Как видно, вы не несете никакой ответственности перед заказчиком > руководством, так что проблемы продакшена от вас далеки.
Мил человек, а ты кто такой-то сам, безотносительно к обсуждаемой
тематике? Хоть название фирмы озвучь, где работаешь. А то тут и
командировки к заказчикам уже прозвучали, и персональная ответственность
и "служба безопасности приедет, всех убьёт" и заводы остановятся и небо
на землю рухнет. И всё из-за какого-то чудака, который зачем-то запустит
приложение с -ea, проигнорировав даденные ему инструкции. Какой-то прям
1C-франчайзи-стайл, интересно что за софт вы разрабатываете такой.
--
WBR,
Serge.
P.S. Ассерты сам не использую, хотя определённые резоны в этом вижу.
Здравствуйте, _newcomer_, Вы писали:
vsb>>Я знаю про две разные позиции в этом споре.
__>StanislavK и я высказывались за неиспользование ассертов, т.к. "поведение должно быть одинаковым и при разработке и в продакшене", а с отключаемыми ассертами в продакшене это не так.
Ну очевидно это не может быть так вообще. Есть такие понятия как debug сборка и release сборка. Есть обфускаторы. Никогда не будет одинаковым поведение в разработке и в продакшне.
__>Кроме того, если их не отключать, то это как раз упование на "само вывезет", что недопустимо в промышленных системах.
Почему?
__>Если ты предполагаешь что тут может быть проблема = обработай ее явно, а не кидай исключение, которое никто не перехватит.
Почему никто не перехватит? Кто это запрещает?
__>devcoach же предлагал повсеместно "правильно" использовать ассерты, отключая их в продакшене. Якобы ассерты позволяют ему тестировать приложения, находя баги.
Тестировать приложение ассерты очевидно помогают. Заменять ассерт на if (!cond) throw MyAssertException("cond is false") можно, но это уродливо и глупо смотрится. Идею с выключением всех ассертов в продакшне я не поддерживаю. Если это очень сильно надо и без этого никак, можно и отключить.
__>И основной моей мыслью было, что его упование на нахождение багов при разработке — ошибочно. __>А отключение ассертов приводит к "само вывезет", что недопустимо.
Не знаю, допустимо или не допустимо, ошибочно или не ошибочно, в разных проектах разные требования. Но мне вариант с отключением ассертов не нравится.
Здравствуйте, hrensgory, Вы писали:
H>Мил человек, а ты кто такой-то сам, безотносительно к обсуждаемой H>тематике? Хоть название фирмы озвучь, где работаешь. А то тут и H>командировки к заказчикам уже прозвучали, и персональная ответственность H>и "служба безопасности приедет, всех убьёт" и заводы остановятся и небо H>на землю рухнет.
Озвучивать название не буду, не зачем.
Заказчиков много из российской промышленности (сотни предприятий).
И крупные и мелкие. Командировки по всей стране от Калининграда до Владивостока.
Есть немного клиентов и за рубежом. В бизнесе более 15 лет. Не 1С.
H>И всё из-за какого-то чудака, который зачем-то запустит H>приложение с -ea, проигнорировав даденные ему инструкции.
Вы хотите быть еще одним, кто "книгу не читал, но осуждаю"?
Перечитайте еще раз, о чем говорил я. Мне без разницы, включены
ассерты или нет. Мое мнение — в промышленной системе их быть не должно.
и не потому что они отключены в продакшене, а потому что разработчики
должны обрабатывать все явно.
Здравствуйте, StanislavK, Вы писали:
SK>>>Еще один. Может тогда расскажете про цель и про красивый синтаксис? Только без повторений "devcoach"-а, плз, не поленитесь прочитать ветку. vsb>>Цель — проверять инварианты и убивать приложение как можно раньше при их нарушении, чтобы предотвратить дальнейшее некорректное поведение и упростить поиск бага. SK>Да вы что? И правда, ни один "if" с таким не справится, надо срочно ассерты делать.
В приложении много if-ов. Разные if-ы служат разным целям. А assert служит вполне конкретной цели и при чтении кода assert помогает понять быстрее, для чего он тут нужен. Так можно и for выкинуть и do-while, одного while хватит всем. Был бы goto, можно было бы и while выкинуть, есть же if, чего тут разводить зоопарк, в самом деле.
vsb>>Красивый синтаксис — про него можно прочитать в любом учебнике. SK>не знаю, не читал. Вообще не красиво отсылать к таким источникам. Мы тут все, я надеюсь, взрослые люди. Просто поясните, что вы имели ввиду. Я немного удивлен данным утверждением, так как это примерно то же что сказать, что у "if" красивый синтаксис. Сказать это, конечно можно, но звучит странно...
Я тогда не понял вопрос.
assert x == y; выглядит очевидно красивее, понятнее и читабельнее, чем if (!(x == y)) { throw new MyAssertionException("Assertion x == y failed"); }
SK>Насчет того, насколько assert удобен для отлова ошибок, вообще — он не позволяет добавить никакой информации, кроме самого условия, что его делает менее полезным при отдадке проблем, чем нормальные проверки.
Информация добавляется вторым аргументом, если надо. То, что он не добавляет само условие в текстовом виде это да, неудобно, но номера строки в принципе хватает, чтобы понять, о чём идёт речь.
SK>>>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае. vsb>>Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать. SK>Если так подходить к перфомансу, то ява не для вас. Пишите на на чем-то без gc и vm оверхедов. Они отъедают гораздо больше, чем проверка на null.
Java во многих местах используется и имеет достаточно хорошую производительность, чтобы её почти всегда хватало. Если это короткий цикл с математикой на 10 минут, там пара лишних сравнений может дать замедление на процент-другой и отключить assertions в этом цикле, считая, что он хорошо протестирован, проще, чем переписывать его на С или ассемблере.
vsb>>Отличный инструмент, гибкий и удобный, что тут ещё можно сказать. SK>Проверка, сама по-себе, да отличный инструмент, но assert — в баню.
Пока аргумент вижу только один — глупый админ может отключить в рантайме ассерты и получить неконтролируемое поведение. Аргумент не убеждает меня.
Здравствуйте, vsb, Вы писали:
vsb>Ну очевидно это не может быть так вообще. Есть такие понятия как debug сборка и release сборка. Есть обфускаторы. Никогда не будет одинаковым поведение в разработке и в продакшне.
В обсуждаемой теме это отличия "бросаем исключения или не бросаем или бросаем, но сами не знаем где, т.к. пропустили неверные параметры".
Различий такого уровня быть не должно, иначе непонятно что мы вообще тестируем.
__>>Кроме того, если их не отключать, то это как раз упование на "само вывезет", что недопустимо в промышленных системах. vsb>Почему?
Потому что пока в этой теме их никто не собирался явно ловить.
__>>Если ты предполагаешь что тут может быть проблема = обработай ее явно, а не кидай исключение, которое никто не перехватит. vsb>Почему никто не перехватит? Кто это запрещает?
В обсуждаемой теме я явно задавал вопрос devcoach про методику использования ассертов.
Во-первых он не собирался их включать в продакшене, а также упомянул, что уповать на ловлю AssertionError тоже не надо, типа это неправильно.
Если ваша методология и шаблоны разработки обязывают включать ассерты в продакшене и ловить AssertionError, то это уже отдельный разговор.
vsb>Заменять ассерт на if (!cond) throw MyAssertException("cond is false") можно, но это уродливо и глупо смотрится.
Логика в том, чтобы у методов было предсказуемой поведение.
Не важно как вы его добиваетесь.
Если вы хотите использовать ассерты в продакшене и ловить исключения, то, как я уже сказал — это отдельный разговор.
Но это влечет жесткие требования ко всем разработчикам и CodeReview.
И встает вопрос, что надежнее — постоянно контролировать использование ассертов всеми разработчиками
в команде (т.к. по сути надо контролировать использование методов, где они вставлены, а не сами ассерты)
или просто их не использовать, чтобы все проверки были локализованы в тех местах, где они
реально требуются.
Здравствуйте, _newcomer_, Вы писали:
__>Здравствуйте, hrensgory, Вы писали:
__>Мое мнение — в промышленной системе их быть не должно. и не потому что они отключены в продакшене, а потому что разработчики должны обрабатывать все явно.
Да да да, все потенциальные баги надо обрабатывать явно. Я уже дал рецепт для такой ситуации:
1) Вам необходимо выпилить все тесты, ибо разработчики должны все обрабатывать явно, а не полагаться на что-то, что не запускается в рподакшне;
2) Введите в своей команде правило: после каждой полезной строчки кода должны идти проверки всех видимых из данного участка переменных на все возможные невалидные состояния.
On 10.01.2014 14:26, _newcomer_ wrote:
> Озвучивать название не буду, не зачем.
Ну как это незачем, вы же наезжаете на оппонента, причём довольно
невежливым образом — то он у вас студент и книжек начитался, то вы не
поймёте что за хрень у них с процессами, строго спрашиваете "Из какой
области это ПО, сколько пользователей и какие последствия падения ПО с
неработоспособностью хотя бы один час?", "Сколько человек у вас работает
над одним проектом?" Вот и вызывает интерес персона ткзть вопрошающего.
> Заказчиков много из российской промышленности (сотни предприятий). > И крупные и мелкие. Командировки по всей стране от Калининграда до > Владивостока. > Есть немного клиентов и за рубежом. В бизнесе более 15 лет. Не 1С.
Это неконкретно всё, не отвечает на действительно интересный вопрос о
том, что за софт вы такой разрабатываете на яве, что исповедуете столь
радикальные взгляды и прям готовы головой своей и другими частями тела
за него перед заказчиком лично ответить. Согласитесь, нечасто такое
встретишь в мире лицензий типа the software is provided "as-is". Ну и
ваша роль в этом процессе интересна — вы девелопер, лид, ПМ, ЛПР?
> H>И всё из-за какого-то чудака, который зачем-то запустит > H>приложение с -ea, проигнорировав даденные ему инструкции. > > Вы хотите быть еще одним, кто "книгу не читал, но осуждаю"? > Перечитайте еще раз, о чем говорил я. Мне без разницы, включены > ассерты или нет. Мое мнение — в промышленной системе их быть не должно. > и не потому что они отключены в продакшене, а потому что разработчики > должны обрабатывать все явно.
Звучит просто прекрасно ) Но в анонимной подаче как-то малоубедительно,
нужен какой-нибудь пример крупного продукта на яве, разработанного вашей
компанией где "разработчики обработали всё явно". Ну, чтоб на него
равняться.
Здравствуйте, hrensgory, Вы писали:
H>On 10.01.2014 14:26, _newcomer_ wrote:
>> Озвучивать название не буду, не зачем. H>Ну как это незачем, вы же наезжаете на оппонента, причём довольно H>невежливым образом
А, т.е. вы вступились за честь другого, так сказать, защищаете тех,
кого на ваш взгляд обижают? Интересно интересно
H>Это неконкретно всё, не отвечает на действительно интересный вопрос о H>том, что за софт вы такой разрабатываете на яве
Софт не только на Джава, но и на других языках. И серверное и клиентское ПО.
И мобильные и десктопные и веб-приложения.
H>Согласитесь, нечасто такое встретишь в мире лицензий типа the H>software is provided "as-is".
А кто вам сказал какая у нашего софта лицензия?
В общем случае проприетарное ПО за приличные деньги.
H>Ну и ваша роль в этом процессе интересна — вы девелопер, лид, ПМ, ЛПР?
Ну проектов много, где-то ПМ, где-то лид.
Какое это все отношение к обсуждаемой теме ассертов имее?
H>Звучит просто прекрасно ) Но в анонимной подаче как-то малоубедительно, H>нужен какой-нибудь пример крупного продукта на яве, разработанного вашей H>компанией где "разработчики обработали всё явно". Ну, чтоб на него H>равняться.
Не вижу смысла вас в чем-то убеждать.
Вижу что вас "возмутил" этот спор и вы решили добавить веса в нем одной из сторон своими обратными наездами и переходом на личности.
Ваше право — к обсуждаемой теме отношения не имеет.
Вы напоминаете деревенского забияку, в разгаре спора вскакивающего с фразой "...а ты кто вообще такой?...".
Забавно
On 10.01.2014 15:38, _newcomer_ wrote: >>> Озвучивать название не буду, не зачем. > H>Ну как это незачем, вы же наезжаете на оппонента, причём довольно > H>невежливым образом > > А, т.е. вы вступились за честь другого, так сказать, защищаете тех, > кого на ваш взгляд обижают? Интересно интересно
Не вижу почему бы одному благородному дону не указать другому на то, что
не стоит себя вести в приличном обществе подобным образом.
> А кто вам сказал какая у нашего софта лицензия? > В общем случае проприетарное ПО за приличные деньги.
Если вы своими деньгами прямо отвечаете за убытки заказчиков, которые
являются результатом действия или бездействия вашего ПО, то это достойно
удивления. И даже, честно сказать, с трудом в это верится без конкретных
фактов-то. Максимум на что хватает моей фантазии — это то, что вы может
быть подписываетесь на бесплатную техподдержку и штрафы за невыполнение SLA.
> H>Ну и ваша роль в этом процессе интересна — вы девелопер, лид, ПМ, ЛПР? > > Ну проектов много, где-то ПМ, где-то лид. > > Какое это все отношение к обсуждаемой теме ассертов имее?
Самое прямое. Вы вообще на яве-то, извиняюсь, пишете?
> Вы напоминаете деревенского забияку, в разгаре спора вскакивающего с > фразой "...а ты кто вообще такой?...".
Здравствуйте, hrensgory, Вы писали:
H>Если вы своими деньгами прямо отвечаете за убытки заказчиков, которые H>являются результатом действия или бездействия вашего ПО, то это достойно H>удивления. И даже, честно сказать, с трудом в это верится без конкретных H>фактов-то. Максимум на что хватает моей фантазии — это то, что вы может H>быть подписываетесь на бесплатную техподдержку и штрафы за невыполнение SLA.
Ну есть разные способы держать рядом с собой клиентов. Ради этого нужно удовлетворять
их потребности в непрерывной работе нашего софта. Много работников компаний-клиентов начинают
и заканчивают свой день запуском/выключением/входом/выходом нашего софта, так что простой —
считайте что человек не выполнял свои прямые обязанности.
Прямо, конечно деньгами, не отвечаем, но косвенно конечно — недовольство клиента — не будет
продолжения использования софта, оплаты ежегодной техподдержки и кучи дополнительных договоров
по внедрению, доработкам и интеграции. Где-то же надо брать кучу денег на содержание
девелоперов и плюшки владельцам компании
H>Вы вообще на яве-то, извиняюсь, пишете?
Эээээ.... да не, просто так, форум местный почитываю....
Максимум — писал на бейсике в школе
H>Ну я так понял названий-то не будет?
Поняли? Ок....
...Да.. не будет
Давайте что ли отдельно попереписываемся, если интересно. Оффтопик же.
Здравствуйте, Hard_Club, Вы писали:
H_C>Недавно прочитал в одной книге, что с помощью assert нельля проверять аргументы в публичных методах, т.к. его можно оключить, а public-методы должны всегда проверять входящие параметры. Откуда взялось такое правило? Кто его установил?
Assertions are designed to be cheap to write, you can use them almost everywhere and I'm using this rule of thumb: the more an assertion statement looks stupid, the more valuable it is and the more information it embeds. When debugging a program that does not behave the right way, you will surely check the more obvious failure possibilities based on your experience. Then you will check for problems that just cannot happen: this is exactly when assertions help a lot and save time.
согласен с выделенным, сдается мне что именно из этих соображений Блох и компания добавила их в язык.
