то есть раз нет обьективных четких общепринятых правил, чем собаки отличаются от кошек, то и собак и кошек тоже нет? :)
если нет четких правил описания рукописных цифр, достаточных для четкого и однозначного их распознавания, то и цифр тоже нет?
почти все понятия современного мира описываются некоторыми нечеткими правилами, для каждого из которых есть исключение, но в совокупности они все равно достаточно точно описывают обьект. почитайте что-нибудь из ml
Говоря по простому, я своими глазами наблюдал, когда компании были вынуждены закрывать востребованный продукт из-за невозможности его больше поддерживать. Все это — результат плохого дизайна.
игра без сейва это все равно игра. хабр без базы статей, юзеров и комментов никому не нужен. всегда есть что-то центральное, вокруг чего все вертится, а остальное делается по остаточному принципу
за очень редким исключением все изменения функицональности разумны, раз делают продукт лучше для пользователей. я лишь хотел подчеркнуть это. что проблема не в том, что изменения нужно делать.
бывает, что проблемы возникают при любом дизайне. просто в хорошом их на порядок меньше. то есть грубо говоря у вас от мерседеса отвалится 1 гайка на 1000км, а от запорожца 100 гаек.
если изменений нет, то всем без разницы. пока их не нужно будет вносить или не вылезет критическая уязвимость и не выяснится, что продукт проще поменять, чем что-то с ним делать, если дизайн плохой
автор пишет: смотрите, я пишу вполне разумный код. мне выдвигают вполне разумные запросы на изменения. и тут я понимаю, что мои изменения потенциально опасные. хороший дизайн, это когда разумные изменения не являются потенциально опасными. есть люди, которые говорят — это невозможно, мой дизайн уже хорош. люди делятся на тех, кто считает, что такова жизнь и на тех, кто пытается все-таки разобраться, как делать так, чтобы изменения не вносили проблем. на это уходит ну минимум 10 лет опыта и минимум, там 30-40 проектов. + теория. и даже если у вас это есть, то не факт, что это будете уметь. нужен сначала волевой факт признания, как у автора, что есть проблема в том коде, который он пишет. он молодец, он признал проблему. еще 10 лет в ней будет разбираться и научится писать хороший код. и после этого он сам начнет сразу бить людей по башке за Action::getProductsByActionId(actionId)
если вас интересует какой-то более-менее научный подход, то возьмите как бы «хотспоты» тех мест, в которых были найдены баги либо же которые приходилось менять для решения проблем и соберите некую генерализацию этого. то же самое опытный программист проделывает у себя в голове, просто на это ему нужно там, лет 15 хотя бы, но то же самое можно проделать и просто ручками. хреновый дизайн это не субьективное мнение. он создает хотспоты проблем. если вы вдруг решите в машину ставить пластиковые гайки, то они станут хоспотами кучи проблем, с которыми вы столкнетесь, поэтому использование пластиковых гаек это не вкусовщина, это просто реально хреновое решение, если на пальцах
я не сталкивался с понятием репозитория в дизайне, может, это чисто вебовская штука, остальным понятная. бывают же там всякие датасорсы, например, viewmodel или dataprovider. это все как по мне исключительно вебовские велосипеды. если они понятны веб-программистам, почему бы и не использовать.
под «вебом» я имею в виду задачу, когда у нас есть база, к ней обращаются пользователи, которым нужно показать на экран или еще куда какое-то подмножество этой базы и дать потыкать по кнопочкам
за много лет практики мне приходилось исследовать причины багов или странных поведений. я не знаю. ну, тысячи. и в итоге я как-то для по крайней мере уяснил, что хреновый дизайн это не вкусовщина, и именно неплохой такой стабильный источник багов. плохой код почти неподдерживаемый и в этом его основная проблема, а не в том, что он мне лично не нравится. соб-но автор и говорит, что пишет неподдерживаемый код. и причина этого — он ничего не понимает в дизайне.
например, подбор коллизий sha1 или подобного сводится к решении систем уравнений примерно как
x1 | x2 ^ x3 | x4… = 1 или что-то в этом духе. получается у нас запутанное состояние, когда мы тянем за одно, а это затрагивает все. и нахождение решение перебором всех xN займет бесконечно времени. а вот аналоговое устройство вполне себе может это сделать очень быстро, надо только заставить xN запутаться, дать им ограничения и заставить систему «устаканиться» и посмотреть к чему она пришла
один один из классических косяков дизайна — смешение двух классов в один. наблюдается в основном у 23летних сеньеров. кто наткнулся потом на кучу грабель после никогда так больше не делает
по уму это xxxController, ну или хотя бы xxxManager. Util — тоже отстой, но самый чемпион отстоя это конечно же xxxHelper
и тут я согласен. просто автор статьи дает пример, как он думает, достаточно абстрактной задачи по дизайну, демонстрирующей некие фундаментальные проблемы, но по факту никаких проблем нет из-за узости этой задачи. это примерно если бы кто-то жаловался, что у него дома на клавиатуре клавиша enter залипает и на основании этого бы делал вывод о неудобстве современных устройств ввода информации
автор предлагает, как ему кажется разумный код, но на самом деле лично мой бы code review он бы не прошел, начиная вообще с первой строчки Product::getProducts — что это за фигня вообще? почему один продукт может выдавать список продуктов?
Action::getProductsByActionId(actionId)
— тоже хрень. что, action должен иметь switch чтоли по action id внутри? и так далее. ну там просто фундаментальные ошибка на ошибке в дизайне
ну не знаю, ну я кодеки, например, писал. или потоковый фильтр входящих данных на, грубо говоря, ненужное. мне приходилось делать реальный нейборинг, условно говоря, продуктов по «топ 100 похожих», но там проблема в сжатии пространства, там все дико сложно индексируется и ес-но, руками. писал код для gpu еще. короче, select по критерию из большой базы это совершенно узенькая конкретная задача из веба и она решается формированием запроса к базе, а не горожением велосипедов.
сводится-сводится. причем чем меньше велосипедов будет нагорожено и больше стандартных инструментов использовано, тем меньше придется переделывать с новой сменой этих самых инструментов
а я уж надеялся… а там просто кто-то данные с oxford nanopore на телефоне анализирует. ну, удобно, конечно, но без оригинального девайса, которому уже сто лет в обед ничего работать не будет
я на самом деле не очень шарю в веб программировании. мне оно всегда казалось очень скучным, так как просто сводится к отображению части информации базы данных на экран. и не то, чтобы ты сам реально писал код select_by_product_name, это все равно все сводится к ручной настройке ключей, построению правильного селекта и передачу всего этого реальному коду, который и делает всю работу.
Тогда это просто кривость реализации бесключевого доступа. Если бы человек всегда руками нажатием на ключ инициировал открытие дверей, то взлом машины в таких случаях — всегда кривость реализации криптографии, которая решается в лоб использованием одноразовых блокнотов ключей для машины и ее ключа.
Борьба с удлиннением ключа в случае бесключевого доступа должна по идее решаться периодическим пингом машины и замером времени отклика. Жалко, что не подумали над этим. Зато теперь будет время подумать
Если есть физическая возможность взять ключ и исследовать его под микроскопом или сделать его копию, то тут уже ничем не поможешь.
Но самый-самый надежный и тупой способ любой криптографии это одноразовые ключи. Их остается только копировать физически, больше никак.
Так как Теслу обычно открывают смартфоном, то, есхи хранить ключ в надежном месте, задача вообще сводится только к взлому смартфона. Никакие мегаалгоритмы и криптостойкие функции нафиг не нужны с одноразовыми ключами. Там абсолютно детсадовская и совершенно непробиваемая криптография.
если нет четких правил описания рукописных цифр, достаточных для четкого и однозначного их распознавания, то и цифр тоже нет?
почти все понятия современного мира описываются некоторыми нечеткими правилами, для каждого из которых есть исключение, но в совокупности они все равно достаточно точно описывают обьект. почитайте что-нибудь из ml
бывает, что проблемы возникают при любом дизайне. просто в хорошом их на порядок меньше. то есть грубо говоря у вас от мерседеса отвалится 1 гайка на 1000км, а от запорожца 100 гаек.
если изменений нет, то всем без разницы. пока их не нужно будет вносить или не вылезет критическая уязвимость и не выяснится, что продукт проще поменять, чем что-то с ним делать, если дизайн плохой
под «вебом» я имею в виду задачу, когда у нас есть база, к ней обращаются пользователи, которым нужно показать на экран или еще куда какое-то подмножество этой базы и дать потыкать по кнопочкам
x1 | x2 ^ x3 | x4… = 1 или что-то в этом духе. получается у нас запутанное состояние, когда мы тянем за одно, а это затрагивает все. и нахождение решение перебором всех xN займет бесконечно времени. а вот аналоговое устройство вполне себе может это сделать очень быстро, надо только заставить xN запутаться, дать им ограничения и заставить систему «устаканиться» и посмотреть к чему она пришла
по уму это xxxController, ну или хотя бы xxxManager. Util — тоже отстой, но самый чемпион отстоя это конечно же xxxHelper
автор предлагает, как ему кажется разумный код, но на самом деле лично мой бы code review он бы не прошел, начиная вообще с первой строчки Product::getProducts — что это за фигня вообще? почему один продукт может выдавать список продуктов?
Action::getProductsByActionId(actionId)
— тоже хрень. что, action должен иметь switch чтоли по action id внутри? и так далее. ну там просто фундаментальные ошибка на ошибке в дизайне
и передавайте туда любые предикаты которые хотите
Борьба с удлиннением ключа в случае бесключевого доступа должна по идее решаться периодическим пингом машины и замером времени отклика. Жалко, что не подумали над этим. Зато теперь будет время подумать
Но самый-самый надежный и тупой способ любой криптографии это одноразовые ключи. Их остается только копировать физически, больше никак.
Так как Теслу обычно открывают смартфоном, то, есхи хранить ключ в надежном месте, задача вообще сводится только к взлому смартфона. Никакие мегаалгоритмы и криптостойкие функции нафиг не нужны с одноразовыми ключами. Там абсолютно детсадовская и совершенно непробиваемая криптография.