Сам проект, причины и ход его реинжиниринга, а также методика получения цифр для оценки результатов приведены у меня в отдельных постах — если интересно, то можно покопаться. Здесь же приведу только выжимку.
В этом фрагменте ссылки ведут куда-то на localhost
Идиоматично, использовать в таком случае комбинацию дефолтных и именованных параметров
class House(
val walls: Int = 0,
val doors: Int = 0,
val windows: Int = 0,
val hasGarage: Boolean = false,
val hasSwimmingPool: Boolean = false
)
fun main() {
val house = House(
walls = 4,
doors = 2,
windows = 6,
hasGarage = true,
)
println("Дом с ${house.walls} стенами, ${house.doors} дверями, " +
"${house.windows} окнами, гараж: ${house.hasGarage}")
}
Т. е. в сигнатурах ваших методов/функций, всегда будет какое-то указание, какие эффекты нужны, но вот писать код протаскивающий интерфейс/делегат/указатель не надо, его сгенерирует уже компилятор
При запросе в котором в in передаётся более 199 аргументов база начинает вести себя иначе и иногда можно получить совсем странные планы выполнения на ровном месте
А можете рассказать подробностей про этот момент? А то у меня в кодовой базе в запрос потенциально может передаваться 950 параметров, теперь вот переживаю
Я думаю, проблема в термине "bug bounty". Просто не очень удачное название, слишком общее и сходу может показаться, что речь идет о любой ошибке в принципе.
На практике же, bug bounty, обычно, значит именно проблемы с безопасностью.
И проблем вида "баг или не баг" там не возникает. Удалось получить доступ к чужим данным - баг!
Остается правда пространство для споров насколько он серьезный (от этого зависит сумма выплаты), но это уже история другая (да и там есть публичные критерии)
Кстати, есть целые сервисы, для организации простой и понятной bug bounty программы.
Вот ради таких комментариев я эту статью и написал. Отдельное спасибо за свой вариант кода.
Правильно ли я понимаю, что "победил" вариант 5 со счетом 1 WTF?
И еще момент.
Как предлагается решать вопросы субъективности WTF-метрики? Лично знаю людей, которые не считают Optional.get проблемой с мотивацией вида "раз метод существует и не помечен устаревшим, то можно пользоваться"
Но мы получили большое снижение требований к писателям софта
Ну слову "билдер", безусловно :)
В этом фрагменте ссылки ведут куда-то на localhost
вы в самом деле считаете что паттерн из статьи и концепт из документации решают одну и ту же проблему?
например?
В
Kotlinнет места билдерам.Идиоматично, использовать в таком случае комбинацию дефолтных и именованных параметров
Это вы предлагаете делать среднестатистическому пользователю?
Ну какая проделанная работа?
Чел тупо ддосил своего научника бредом от chatGPT на теоретической части, а экспериментальную часть по-дедовски тиснул из старого чужого диплома
Взгляд. Свидание будущего
Отчего же, если компания, например, пилит какой-нибудь продукт?
Условный, JetBrains с их IntelliJ IDEA
А как именно обрабатываются?
Что делать, если в зависимости от ошибки нужно показать какое-то сообщение пользователю?
а где в вашем варианте обработка ошибок?
Явно именно что "передавать" не нужно, но декларировать скорее всего нужно.
Как implicit в Scala.
Т. е. в сигнатурах ваших методов/функций, всегда будет какое-то указание, какие эффекты нужны, но вот писать код протаскивающий интерфейс/делегат/указатель не надо, его сгенерирует уже компилятор
Альтернативный пример неявного протаскивания сейчас пытаются сделать в Kotlin
А можете рассказать подробностей про этот момент? А то у меня в кодовой базе в запрос потенциально может передаваться 950 параметров, теперь вот переживаю
Я думаю, проблема в термине "bug bounty". Просто не очень удачное название, слишком общее и сходу может показаться, что речь идет о любой ошибке в принципе.
На практике же, bug bounty, обычно, значит именно проблемы с безопасностью.
И проблем вида "баг или не баг" там не возникает.
Удалось получить доступ к чужим данным - баг!
Остается правда пространство для споров насколько он серьезный (от этого зависит сумма выплаты), но это уже история другая (да и там есть публичные критерии)
Кстати, есть целые сервисы, для организации простой и понятной bug bounty программы.
p.s. мы пользуемся bugcrowd
Вот ради таких комментариев я эту статью и написал. Отдельное спасибо за свой вариант кода.
Правильно ли я понимаю, что "победил" вариант 5 со счетом 1 WTF?
И еще момент.
Как предлагается решать вопросы субъективности WTF-метрики?
Лично знаю людей, которые не считают Optional.get проблемой с мотивацией вида "раз метод существует и не помечен устаревшим, то можно пользоваться"
Так ведь именно это и сделано.
PermissionService используется только в одном месте, в Action
Этот Action силами фреймворка вызывется прежде чем пустить запрос к контроллеру
Контроллеры на которых такая проверка нужна просто помечаются аннотацией RequireAccessToPage
Или я неправильно вас понял?
Так я и пытаюсь договориться об определении :)
Есть задача и есть 5 вариантов решения (ситуация в статье)
Нужно взять самый качественный/лучший/хороший вариант.
И, внезапно, выясняется, что 3 человека выбирая самый качественный/лучший/хороший вариант взяли разные варианты.
Очевидно, что понятие "качественный" у каждого из них свое. Но как понять, из чего оно складывается?
Я решил поспрашивать по-больше людей, чтоб оценить критерии качества в крупную клетку.
Например, что вы думаете о предложенных вариантах?
Какой из них предпочли бы видеть у себя в коде?
Какой видеть не хотели бы?
Я не понял, что вы хотели сказать :(
Не важно, как написан код, главное чтоб задача решалась?
Вообще не надо писать код, надо находить какие-то другие пути?
По-моему, сейчас вы смешиваете "понятность" и "читаемость"
Понятность субъективна, потому что зависит от опыта читающего.
Читаемость же, вполне себе объективная характеристика
на запихиваем 100500 действий в одну строку
ограничиваем предельный размер строки
отделяем пустыми строками важные части
предпочитаем короткие имена вместо ОоченьПодробныхНоСлишкомПримитивных
придерживаемся единообразия в форматировании