Т. е. в сигнатурах ваших методов/функций, всегда будет какое-то указание, какие эффекты нужны, но вот писать код протаскивающий интерфейс/делегат/указатель не надо, его сгенерирует уже компилятор
При запросе в котором в in передаётся более 199 аргументов база начинает вести себя иначе и иногда можно получить совсем странные планы выполнения на ровном месте
А можете рассказать подробностей про этот момент? А то у меня в кодовой базе в запрос потенциально может передаваться 950 параметров, теперь вот переживаю
Я думаю, проблема в термине "bug bounty". Просто не очень удачное название, слишком общее и сходу может показаться, что речь идет о любой ошибке в принципе.
На практике же, bug bounty, обычно, значит именно проблемы с безопасностью.
И проблем вида "баг или не баг" там не возникает. Удалось получить доступ к чужим данным - баг!
Остается правда пространство для споров насколько он серьезный (от этого зависит сумма выплаты), но это уже история другая (да и там есть публичные критерии)
Кстати, есть целые сервисы, для организации простой и понятной bug bounty программы.
Вот ради таких комментариев я эту статью и написал. Отдельное спасибо за свой вариант кода.
Правильно ли я понимаю, что "победил" вариант 5 со счетом 1 WTF?
И еще момент.
Как предлагается решать вопросы субъективности WTF-метрики? Лично знаю людей, которые не считают Optional.get проблемой с мотивацией вида "раз метод существует и не помечен устаревшим, то можно пользоваться"
Отлично же :) Тогда давайте я попробую применить ваши критерии.
Первый вариант я написал за 5 минут. Чтобы написать пятый вариант, понадобилось 10 минут.
Цифры условные, никаких замеров я не делал, но по ощущениям на пятый вариант потрачено в два раза больше времени.
Технически, я сначала написал вариант 1, а потом потратил еще столько же времени, чтобы его улучшить и, в итоге, получился вариант 5.
Сколько времени уйдет на внесение изменений в будущем не понятно. Ведь мы не знаем какого рода это будут изменения и кто их будет вносить.
В силу простоты задачи какой-то явно заметной отладки не получилось.
На решение написано 5 тестов:
3 теста на случай когда не передали какой-то из параметров
1 тест когда пользователь не имеет доступа и получает отлуп
1 тест когда все хорошо и доступ есть
Оба варианта успешно проходят все тесты.
Как понять какой вариант лучше? Первый, потому что потребовал меньше времени?
Кстати, если я не знаю сколько времени потрачено на написание кода, например, смотрю на код опенсорсной библиотеки, то получается в рамках этой схемы качество оценить нельзя?
До вашего пояснения я думал что между "понятно" и "академически" существует дихотомия.
Теперь я уже не уверен. В вашей "системе ценностей" код может быть одновременно и "понятным" и "академическим" (варианты 1 и 5), или я что-то понял не так?
Если вам не трудно, могли бы в классифицировать примеры из статьи по системе "понятно"/"академически" с комментариями почему именно так?
Характеристики "понятно" и "академически", сами по себе, довольно абстрактны и каждый человек вкладывает в них какой-то свой смысл.
Когда я обсуждал статью с коллегами внутри компании, то получалась такая ситуация * "простым" считали либо первый, либо пятый * "академическим" считали либо второй, либо третий
Вот лично для вас, на пальцах, что значит "просто", а что "академически"?
Ну какая проделанная работа?
Чел тупо ддосил своего научника бредом от 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 действий в одну строку
ограничиваем предельный размер строки
отделяем пустыми строками важные части
предпочитаем короткие имена вместо ОоченьПодробныхНоСлишкомПримитивных
придерживаемся единообразия в форматировании
Отлично же :) Тогда давайте я попробую применить ваши критерии.
Первый вариант я написал за 5 минут.
Чтобы написать пятый вариант, понадобилось 10 минут.
Цифры условные, никаких замеров я не делал, но по ощущениям на пятый вариант потрачено в два раза больше времени.
Технически, я сначала написал вариант 1, а потом потратил еще столько же времени, чтобы его улучшить и, в итоге, получился вариант 5.
Сколько времени уйдет на внесение изменений в будущем не понятно. Ведь мы не знаем какого рода это будут изменения и кто их будет вносить.
В силу простоты задачи какой-то явно заметной отладки не получилось.
На решение написано 5 тестов:
3 теста на случай когда не передали какой-то из параметров
1 тест когда пользователь не имеет доступа и получает отлуп
1 тест когда все хорошо и доступ есть
Оба варианта успешно проходят все тесты.
Как понять какой вариант лучше? Первый, потому что потребовал меньше времени?
Кстати, если я не знаю сколько времени потрачено на написание кода, например, смотрю на код опенсорсной библиотеки, то получается в рамках этой схемы качество оценить нельзя?
До вашего пояснения я думал что между "понятно" и "академически" существует дихотомия.
Теперь я уже не уверен. В вашей "системе ценностей" код может быть одновременно и "понятным" и "академическим" (варианты 1 и 5), или я что-то понял не так?
Если вам не трудно, могли бы в классифицировать примеры из статьи по системе "понятно"/"академически" с комментариями почему именно так?
На мой взгляд, ваши критерии
позволяет как можно быстрее вносить изменения сохраняя при этом минимально необходимый уровень качества
соответствие реального поведения программы ожидаемому поведению описанному в ТЗ
все равно довольно абстрактны.
Сейчас я не понимаю как их можно свести к числам.
Если вам не трудно, можете провести оценку пары вариантов, например, первого и пятого по своей схеме?
Понятное дело, что это примеры и в жизни все сложнее. Но думаю для общего понимания методики их хватит.
Если нужны какие-то уточнения по ТЗ, или другого плана, то я готов отвечать на вопросы.
А как вы определяете читаемость?
Гипотетически, если бы мне действительно надо было проходить ревью у вас, как бы я мог понять, достаточно ли читаемо написал?
Тут есть ловушка
Дело в том, что "критерии лучшести" часто выражаются абстрактными словами.
Допустим, мы считаем, что хороший код должен быть выразительным и поддерживаемым (и работать правильно, само собой)
А что такое выразительность и поддерживаемость?
Тут есть забавный нюанс.
Характеристики "понятно" и "академически", сами по себе, довольно абстрактны и каждый человек вкладывает в них какой-то свой смысл.
Когда я обсуждал статью с коллегами внутри компании, то получалась такая ситуация
* "простым" считали либо первый, либо пятый
* "академическим" считали либо второй, либо третий
Вот лично для вас, на пальцах, что значит "просто", а что "академически"?
Нет, никакой "технической оценки" вариантов не делали.