Последние комментарии
Для меня эта страница - это удобный способ смотреть, что нового происходит в комментариях и сразу находить заметку, не заходя в админку. Думаю, она будет полезна и тебе.
DiDimus
Насколько мне известно, число циклов заряда относится к полному циклу, т.е. заряд от 0 до 100% - есть полный цикл.
То есть, если аккумулятор заряжен на 50% и его начать заряжать до конца, то это будет половина цикла заряда, и от гипотетического значения в 20 оставшихся зарядок останется 19,5. Если заряжен на 25% - цикл будет равен 0,75 и т.п.
Сергей
Ставь BolgenOS и не парься.
Kastor
Я пишу юнит тесты. Более того стараюсь и других приучить.
Для этого настроил сборку так, что если кто-то понизил своими комитами уровень покрытия, то сборка валится.
http://www.kastordriver.one/2017/02/keep-code-coverage-on-radar.html
А так же я разделяю юнит и интеграционные тесты, т.к. юнит тесты я запускаю довольно часто и они не должны быть тормознутыми.
http://www.kastordriver.one/2017/02/separate-and-rule-your-tests.html
В дальнейшем планирую освоить и ввести в практику UI тесты (смотрю на http://ru.selenide.org/)
Более того, практикую TDD и даже делал доклад на эту тему.
https://dou.ua/calendar/14483/
Моя далекая мечта - это continuous delivery.
Короче, я серьезно отношусь к тестам =)
MasDen
Обычно на проектах пишу тесты на важный функционал или сложную логику. Однако на текущем проекте заказчик требует чтобы тесты писались везде, где есть смысл. Потому текущие проекты имеют кучу полезных тестов.
Влад
Покрывать юнит тестами все подряд - бестолковая трата времени и порою эти тесты ничего не делают и не о чем не говорят. Я считаю, что покрывать каждый метод контроллера, сервиса для сохранения в БД, каждый репозиторий - просто нет смысла и это лишняя трата времени.
Я, к примеру, покрываю только те места, где происходят некие просчеты, какая-то сложная валидация бинов и т.д. и т.п. В общем где происходит какая-то критичная бизнесс логика
Леонид
Эх, эт самое трудное - жить в 2 стороны
Ololo
Не пишу по своей воле никогда. Абсолютно бесполезное дело. Требования меняются, код рефакторится после этого тесты не работают, надо их или рефакторить или менять логику после смены требований или удалять нафиг. На них уходит куда больше времени и гораздно больший объём кода чем на сам код который тестируется. Сколько было раз что код работал хорошо, а тест не хотел работать, тратил кучу времени чтобы заставить тест работать, чаще всего в моке какие-то данные неверные забил или забыл за что-то. Они дают только ложную уверенность, что всё хорошо если тест прошёл, в реальности даже программисты-фанаты тестов не проверяют все варианты, тест показывает, что всё ок, а в реальности там баги. Затраченные силы и время на написание тестов не окупают эффектиность тестов, КПД низкий грубо говоря. Тратишь больше времени чем на разработку на фигню которая не даёт никаких гарантий. Если тесты после кода ещё хоть какой-то минимальный смысл, то ТДД вообще бесполезная чушь собачья.
Михаил Фленов
Ко мне родители не хотят, переезжать.
Леонид
Эт понятно, а родители не хотят к тебе переехать?
О блоге
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
severvam
Автомаппер ужасное зло. У нас используется сплошь и рядом, для конвертаций обьектов которые на бекенде в обьекты которые на фронтэнде. Не спрашивай зачем, архитекторы так нарисовали.
Так вот. Маппить обьект в обьект еще не страшно, там если что-то сломалось - найти где это и починить достаточно просто. Но вот когда маппишь сложные структуры, например, обьекты с коллекциями в которых находятся обьекты которые тоже маппятся, то вот тут начинается жесть. Ведь ты можешь удалять обьекты из коллекции, модифицировать их и добавлять. И во время маппинга у нас была куча проблем. И лишние обьекты появлялись и нулы пролезали и мержилось криво. И если нулы отловить и тут тоже не сильно большая проблема, то кривой маппинг ударяет по бизнес логике и после нескольких раундов калькуляций получаешь неправильный результат. И сиди ищи почему посчиталось неправильно.
Короче, лучше просто написать бойлерплейт с ручным маппингом, чем разбираться с автомагией.