вообще обычно указывают интервал значений и указывают с какой вероятностью точное значение в него должно попадать. скажем, на пальцах 90-95%. просто иногда бывает что эти интервалы даже не перекрываются у разных ученых. просто ошиблись в оценке самой ошибки
да каждый президент снова начинает разговоры о лунной программе, реально НАСА в прошлый раз грохнуло на нее порядка полутриллиона, президент одобряет в лучшем случае 10% от нужного бюджета и все опять закисает в непонятном состоянии
Я говорю, что хороший дизайн существует. Вы — ему нет четких однозначных правил, поэтому он не может существовать. Я — если отсуствие таких правил является для вас основанием для отрицания существования, то вам придется так же отрицать существование, например, рукописных цифр. Вы — нет.
нууу, что я могу тут возразить. считайте, как хотите. нельзя же спорить с человеком, который сам себе противоречит и не видит проблемы в этом.
к тому же не то, чтобы я хотел спорить, я скорее хотел обьяснить. чтобы понять, почему я так борзо разговариваю, можете посмотреть на linkedin на мой опыт и откуда я вообще сделал подобные выводы.
то есть раз нет обьективных четких общепринятых правил, чем собаки отличаются от кошек, то и собак и кошек тоже нет? :)
если нет четких правил описания рукописных цифр, достаточных для четкого и однозначного их распознавания, то и цифр тоже нет?
почти все понятия современного мира описываются некоторыми нечеткими правилами, для каждого из которых есть исключение, но в совокупности они все равно достаточно точно описывают обьект. почитайте что-нибудь из 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 по критерию из большой базы это совершенно узенькая конкретная задача из веба и она решается формированием запроса к базе, а не горожением велосипедов.
нууу, что я могу тут возразить. считайте, как хотите. нельзя же спорить с человеком, который сам себе противоречит и не видит проблемы в этом.
к тому же не то, чтобы я хотел спорить, я скорее хотел обьяснить. чтобы понять, почему я так борзо разговариваю, можете посмотреть на linkedin на мой опыт и откуда я вообще сделал подобные выводы.
если нет четких правил описания рукописных цифр, достаточных для четкого и однозначного их распознавания, то и цифр тоже нет?
почти все понятия современного мира описываются некоторыми нечеткими правилами, для каждого из которых есть исключение, но в совокупности они все равно достаточно точно описывают обьект. почитайте что-нибудь из 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 внутри? и так далее. ну там просто фундаментальные ошибка на ошибке в дизайне