Как стать автором
Обновить
102
0.2
Slava Vedenin @vedenin1980

Java developer

Отправить сообщение
1,2) тогда да, assert имеет смысл, хотя другой вариант сделать примерно так
if(logger.isDebug() && условие) {
logger.debug(" Assert error ....");
}
С последующим ручным или автоматическим анализом логов. Плюс в том, что в отличии от assert'ов никто не мешает включать logger debug на продакшене для поиска особо сложным проблем. Но это все-таки редкая ситуация, когда используются хитрые способы.

3) Да, если тест/сценарий не выполняется при загрузке и т.п. вещах. Можно пописать новые фичи, но достаточно неприятное чувство когда человек 50 разработчиков хочет тебе лично попинать ногами за то что они не могут сделать свою срочную работу, а должны программировать в уме.
2) Можно, но вы считаете что хорошая идея захламлять рабочий код обработкой случаев возможных только для отладки у разработчика?
3) Не всегда, error это фатальная ошибка которая не обещает сохранения данных. Но проблема assert'ов не в этом, а в том что падение assert'ов в отличии от остальных тестом в том что они мешают остальным разработчикам в команде, в отличии от unit, интеграционных и модульных тестов и в том что чрезмерное их использование увеличивают сложность «рабочего» кода (особенно при создании дополнительных методов проверки), в отличии от всех других методов тестирования,
Assert'ы имеют свои проблемы:
1) чрезмерное их использование приводит к захламлению рабочего кода, в то время как unit тесты и интеграционные тесты традиционно находятся в других пакетах модулях/режимах сборки. На мой взгляд мешать в рабочих классах ещё и методы тестирования (как описано в статье) скорее вредно. Одно дело редкая проверка с помощью assert'a в особо критичных случаях, другое дело вставка кусков кода только для «отладки»,

2) вместо assert'ов лучше использовать unit тесты, интеграционные тесты, системы непрерывного тестирования, которые не захламляют код, но при этом тестируют не менее надежно,

3) в относительно большой команде, тактика «чуть что все система падает» очень неудобна, так как будет мешать остальным разработчикам и тестерам работать с системой, вы сталкивались с ситуациями в большой команде, когда unit test'ы в системе непрерывного тестирования «шумят» (падают по непонятной причине)? Даже при этом, разработка всей команды становится не очень комфортной, потому что невозможно выкладывать изменения. Падение assert'ов потенциально может сделать недоступной разработку остальной команде на какое-то время. Даже полчаса -час простоя ВСЕЙ команды, может вылиться в потерю несколько человеко-дней,
Падение кода — это прекрасно. Это значит, что баг не привел к тихому неправильному поведению, деньги/заказы в интернет магазине/заявки не потеряли и т. д.

1) Assert'ы не предназначены для продакшена,
2) Совсем не обязательно ронять всю систему, если можно выкинуть checked exception, правильно его обработать, откатить транзакцию и сообщить клиенту что именно эта функция, не работает,
3) Как раз. уронив систему до записи заявки, её легко потерять,
С assert'ами есть ряд проблем при достаточно большой команде. Так как при включенных assert система падает, может сложиться ситуация при очень «щедром» использовании assert'ов, система упадет у товарищей по команде, так что они не смогут вообще работать с системой. Если assert'ы включаются у QA команде может быть ещё хуже ситуация, когда QA вообще не сможет ничего тестировать из-за падения assert'a в начале тестов.
их можно и нужно расставлять по коду как можно щедрее

Не согласен. assert выкидывает AssetionError, который сложно обрабатывать и пользователю ничего не скажет. AssetionError наследуется от Error, то есть не перехватывается catch(Exception exp) и все система упадет целиком без какой-то работы над ошибками.

Надо понимать, что assert это что-то вроде вся бизнес логика сломалось и ничего с системой сделать нельзя. Для реальной системе намного лучше использовать классическое:
if(условие не выполняется) {
throw new Подходящий_Exception(«Ваше сообщение об ошибке»);
}
Если пользователь увидит сообщение «Диск системы переполнен», он намного быстрее поймет что нужно сделать, чем непонятный AssertError.

assert хорош в unit-test'ах (но обычно у библиотек unit тестирования есть свои assert'ы вроде assertTrue, assertEquals и т, п.), но в реальном мало-мальски крупном приложении я бы assert использовать не стал.
Не совсем понимаю, как вы делаете объединение токеннов в одно слово? Скажем, в английском большой проблемы нет, там просто можно взять, отбросить часть в конце и получится правильное слово, а в русском, насколько знаю, автоматические методы работают плохо, например есть у вас токены

путы,

и

пути, путей, путь

При всей похожести это совершенно разные слова (путь и путы), а любой автоматический способ приведения (ну за исключением кропотливого ввода всех возможных правил склонения русского языка или использования словаря всех русских слов) будет делать ошибки на подобных словах. А их достаточно много, чтобы сделать подобный автоматический разбор не очень полезным для большинства применений.
Дело в том, что вы описали практически классический алгоритм асимметричной схемы ЭП с участием внешнего прокси сервера-посредника без особых деталей реализации. Правда, обычно там ещё должна быть хеш функция для проверки что исходный документ не поменялся.
А можно несколько вопросов:
1) В чем тут отличие от обычного алгоритма электронной подписи документов пользователем?
2) Кто мешает пользователю удалить приложение с мобильного клиента (или вообще сделать удаление всех данных с устройства) и проголосовать на сайте хоть сто раз, хоть тысячу?
Можно после фидер, поставить редкое слово сидер и возможно удастся пойти ещё дальше.

Да, в сумме, как не проектируй и какие патерны не применяй, количество вызовов методов практически не меняется. Ладно, убеждать вас ни в чем не буду.
И да, что такое legacy системы мне прекрасно знакомо, и как в них внедрять более современные правила проектирования тоже.
Если бы нашел 100400 мест, где используются getAllPayment, прибил бы архитектора. Шутка. Вызовы getAllPayment на 2 млн. entity, скорее всего могут должны использоваться только для задач интеграции, обслуживание БД и т.п. Если такой метод используется в обычных модулях это уже повод понять зачем.

Если есть куча мест где используется getPaymentByQuery(«name = ?»), то это повод выделить его в отдельный метод getPaymentByName, создать индекс по полю name, сделать тест производительности метода на реальной базе и т.д. Также для всех подобных методах, в результате большинство частых запросов можно будет выделить в отдельные методы. А дальше всегда можно использовать профайл и т.п. методики на отдельных методах. Метод getPaymentByQuery имеет смысл именно для действительно уникальных случаев и опять-таки ловится профайлером, логированием времени работы и т.п. методами

Ну, например что будет узнаете ли вы когда нибудь, что у вас используется в 100400 мест запросы вида «Payment.name = ?», но индекс по поля name вы сделать забыли, отчего вся ваша система дико тормозит? Ни один профайлер не сможет собрать такие запросы из 100400 мест, насколько я знаю.
Тут скорее всего имели в виду, если есть супер программа вычисляющая курсы валют для Форбса и значительная часть следует её указаниям, то с большой вероятностью даже совершенно случайные прогнозы будут сбываться.
Ну, смотрите делаем, например, грубо говоря такой сервис

public interface ServicePayment {
  Payment getPaymentById(String id);
  Payment getAllPayment();
  Payment getPaymentByQuery(String query);
}

Теперь нам не нужно искать вообще все Payment'ы, достаточно сделать поиск по getAllPayment и getPaymentByQuery и понять где программисты промахнулись. Крайне редко проблема будут в цикле с getPaymentById.
Но как узнать, где порождается такое большое количество объектов? Искать по коду? Не вариант, придется делать поиск по всей системе, а времени в обрез – заказчик уже весь синеет.

Я конечно извиняюсь, но вроде бы, поднятие общих бизнес сущностей выносят в отдельные классы, тогда и связность системы понизилась бы, поиск с модификацией кода работающего с entity стали куда проще, да и необходимость у программистов сто первый раз писать велосипед, вроде того поднятия entity не было бы. Плюс часто делают свои обертки над классами JPA'а, вроде entityManager'a, чтобы, например, было проще отлаживать и профилировать поднятие entity (на самом деле, так ещё куча других полезных вещей). Тогда не нужно было делать всех этих хаков с конструктором.

Не идеальный продукт, я имел в виду немного другое. Например, делал я как-то я во фрилансе некоторый парсер данных в один интернет магазин, сделал по-правильному, чтобы парсер висел, постоянно проверял обновление и допарсивал новые данные, а оказалось что заказчик вообще-то рассчитывал на одновременный перенос данных, а за доработку парсера, чтобы он мог обновлять данные, хотел заплатить ещё примерно столько же позже. В результате, я получил некий абстрактный плюс в «репутацию», но потерял в деньгах.

В большом бизнесе примерно также, подозреваю, что сделать не ломающиеся и не требующие расходников пылесосы возможно, но производители никогда на это не пойдут.
Да, сталкивался с ситуациями когда куча народа неделю и больше обсуждает и планирует функционал (причем каждый тянет в свою сторону), который за пару дней силами одного разработчика можно сделать, отладить, выкинуть, пару раз переписать и выдать уже готовый и отлаженный продукт, учитывающих косяки, которые никаким планированием не поймать. ИМХО, чрезмерное планирование, такое же зло, как и быдлокодирование без всякого плана.
Иногда, сделав изначально слишком хороший продукт даже за тоже время/деньги, есть риск в бизнесе проиграть. Идеальный продукт не глючит и его не нужно дорабатывать, следовательно заказчику нет смысла платить за сопровождение и доработки, следовательно можно потерять изрядную сумму от этого заказчика (правда получив некий плюс к репутации).
Статья интересная, но на мой взгляд автор все-таки уходит в другую крайность от тяп ляп и в продакт. Вспоминается эпизод в «автостопом по галактике», про разбившийся корабль менеджеров и рекламных агентов, где они бесконечно планировали и проводили совещания вместо того чтобы просто нарубить дров и собрать еду. Перепланирование, так же плохо как и попытка все решить наскоком.
Перефразируя Энштейна «объяснять надо просто настолько это возможно, но не проще», «разрабатывать надо быстро насколько это возможно, но не быстрее», в смысле скорость разработки должна быть максимальной, но только пока она не влияет на качество разработки.
Возникает чувство что все модели предсказывают одинаково плохо (а точнее вообще никак не предсказывают), просто для одной из моделей результаты случайно оказались более близки к реальности. Tbats, на мой взгляд, кстати в целом показывает картину лучше ARIMA, так как Tbats предсказывает падение, а ARIMA стабильность цены и цена на 6 день очень близка с реальностью (важен не столько график скачков, сколько тенденция прогноза). Увы, сложность экстрополяции на коротких промежутках в том что даже просто генерируя абсолютно случайные графики рано или поздно можно найти похожий на реальность, но это ничего не говорит о качестве модели, модель можно будет считать проверенной если она будет близка к реальности хотя в 2-3 разных временных промежутков.

Информация

В рейтинге
2 489-й
Откуда
Luxemburg, Luxembourg, Люксембург
Дата рождения
Зарегистрирован
Активность