Подогнали все условия, чтобы Ребекка проиграла, хотя ничего подобного в статье не было. И альфа у нее сырая, и приложение дороже, и расходы больше, и сроки она затянула, а бюджеты одинаковые. Конечно, Ребекка проиграет, о чем тут говорить вообще?
«Антихрупкость» Нассима Талеба. Позволяет совершенно по новому увидеть, как правильно управлять любыми рисками и чем живые/развивающиеся системы отличаются от мертвых/стагнирующих. Плюс куча очень интересных фактов и рассуждений по ходу повествования.
Часто бизнес понятия не имеет, что «быстро» и «качественно» как-то связаны. Для него детали разработки находятся «под капотом». Адские костыли, отсутствие тестов, плохая архитектура, велосипедостроение — все это для бизнеса, как правило, не видно вовсе, пока все работает как должно и новые фичи пилятся быстро. Проблема в том, что бизнесу обычно не с чем сравнить — что означает «быстро» при разработке новых фич и «работает как надо» при сопровождении. Все, что видно бизнесу, — это как все устроено с его личным продуктом. Разве что сравнить с конкурентами, у которых почему-то новые фишки появляются быстрее, регрессии и баги — реже, а высокая нагрузка не приводит к даунтаймам. Но это обычно достаточно закрытая информация, а то, о чем бизнес знает — это как обстоят дела с его собственным продуктом (который «под капотом» кривой, косой, плохо масштабируемый и ужасный в сопровождении).
Это как если вы сдаете машину в аренду какому-то водителю, интересуясь только количеством заказов и прибылью, и однажды обнаруживаете, что автомобиль не просто почти не приносит прибыли, а с трудом ездит и убит в хлам, потому что водитель экономил на ГСМ и запчастях, ни разу не делал техобслуживания и был крайне неразборчив в выборе пассажиров и грузов. Вполне возможно, что к моменту обнаружения истинного положения дел автомобиль будет уже не в том состоянии, когда его рентабельно восстанавливать — придется покупать новый.
С плохим кодом та же самая история. Если бизнес не понимает, что от качества кода, архитектуры, культуры разработки зависит способность итогового продукта приносить деньги, то однажды бизнес обнаружит, что продукт не просто не прибылен, а что он убыточен и уже не может стать прибыльным снова — дешевле переписать его с нуля или заменить на готовое решение от третьей стороны.
Еще один подводный камень, с которым вы, скорее всего, столкнетесь при работе с JSON RPC на стороне клиента — довольно скудный набор клиентских библиотек. Если же вы используете JSON-RPC over HTTP и хотите применять стандартную клиентскую библиотеку для сетевых запросов, вы столкнетесь с необходимостью переопределить то, что считается ошибкой и что — успешным запросом: в HTTP-клиенте эти ситуации различаются обычно по HTTP-коду (2хх и 3хх — все ОК, 4хх и 5хх — ошибка), а в JSON-RPC код будет почти всегда равен 200, а для различения error/success придется проанализировать тело ответа: если в наличии поле result — то запрос завершился успехом, если поле error — ошибкой.
Вполне устраивает. Просто для REST у меня была готовая реализация от фреймворка, где в случае ошибок валидации формы сериализатор выставлял в ответе нужный HTTP-код (422) и формировал нужную структуру массива ошибок полей формы. А в случае JSON-RPC пришлось писать подобный сериализатор самому.
Как в JSON-RPC реализовать валидацию форм — удобную и без велосипедов? В REST можно прислать общий код «Форма не верна» (422, например), а в теле ответа — массив/объект с информацией обо всех полях, заполненных ошибочно, после чего клиент легко и просто отображает ошибки на соответствующих полях.
Какая best practise для этого в JSON-RPC? Присылать по одной ошибке для каждого неверно заполненного поля, пока все они не окажутся заполненными правильно? Или изобрести свой формат поля data для подобного случая? Есть ли примеры готовой реализации?
В каком-то смысле shared database очень схожа с другим «табу» разработки — использованием глобальных переменных. В случае глобальных переменных ответственность за данные не ограничена областью видимости переменной, а «размазана» тонким слоем по всему коду проекта: в любом месте переменную могут не просто прочитать, но еще и перезаписать. В случае shared database все даже хуже: ответственность за БД размазана по коду множества различных проектов, к многим из которых у вас даже может не быть доступа.
Shared database — один из таких архитектурных антипаттернов. Да, база данных может быть спроектирована безобразно: каша в именах полей, отсутствие гайдлайнов по именованию, семантические ошибки, кривая схема, денормализация, и т.п… Это может быть серьезной проблемой. Но еще хуже то, что если у вас shared database, то вы очень сильно ограничены в решении этой проблемы, потому что к схеме общей БД привязано целое множество других приложений, кроме вашего, и хорошо еще, если у вас на руках есть полный их список.
Идеально спроектировать что-то с первого раза удается не всегда, но даже если удалось — продукт растет, развивается, меняется: может оказаться, что сделанные в процессе проектирования и разработки допущения не совсем хорошо описывают реальный бизнес-процесс, или бизнес-процесс поменялся; а может, разработчики что-то забыли или поняли неправильно, и приходится переделывать часть работы. В любом случае — изменения возможны, и они обязательно будут. Это нормальный процесс. Помимо рефакторинга кода, бывает, требуется вносить изменения и в схему базы данных.
Но бывают ситуации, когда этот процесс непрерывного изменения и совершенствования продукта сильно затрудняется или даже замораживается определенными архитектурными решениями, заложенными в проект на заре его становления.
Вы чрезмерно упрощаете. То, что вы называете «сбоем» — это не некое дискретное состояние: вот была у нас здоровая клетка, а вот она стала «сбойной», больной. Это не совсем так. Пока клетка может поддерживать гомеостаз, выполнять свою функцию и не становиться раковой — она де-факто здорова: на 100%, на 90% или на 60% от некого «эталона». Да, она может быть не здорова на все 100 (подозреваю, что таких клеток может оказаться сильно меньше, чем нам представляется), но она делает то, что нужно, хотя и не так хорошо, как прочие, потому что немного поизносилась. Предлагаете заменить все, что не идеал на 100%? Многовато клеток придется убить, имхо, — возможно, что и большую часть.
Но допустим, вы можете это сделать. Ок. Что считать «эталоном», с которым вы сравниваете клетки, решая, сбойные они или нет? Клетки без ошибок в ДНК — а много ли таких найдется, если ошибки происходят постоянно, длина спиралей ДНК огромна, а большинство таких ошибок безвредны или успешно «чинятся» встроенными механизмами клетки? Или клетки, в которых экспрессируются «правильные» гены — но из-за дифференциации клеток и различного действия факторов среды количество вариантов астрономически велико даже в пределах одного и того же органа. Может быть, клетки, где синтезируемые белки точь-в-точь сделаны по чертежу — но белков миллионы, мутации генов могут и не ломать белок, а просто делать его менее эффективным, а перебирать все молекулы белков в каждой клетке слишком долго.
Ок, не будем трогать клетку, которую оставили в живых встроенные механизмы защиты организма. Это не отменяет того факта, что она находится в шаге от того, чтобы «сломаться» — переродиться в раковую или перестать выполнять свою функцию. Или в двух шагах. Или больше. Или сценариев, которые могут сделать из абсолютно здоровой клетки больную, сильно больше единицы, и какой из них реализуется — вы не можете знать, это процесс случайный и во многом непредсказуемый. А может, и вообще никакой из этих сценариев не реализуется, а вы уже убили такую клетку, посчитав подозрительной.
Короче, на клетке не висит ярлык — «исправно на 57 и восемь десятых процента, рекомендуется уничтожить, вероятность озлокачествления более 50% в ближайший год». И такой ярлык в большинстве случаев невозможно наклеить по результатам исследования клетки (там, где это возможно, это делают встроенные системы защиты, которые и уничтожают подобные клетки). В это упирается надежность детектирования сбоев: что считать сбоем (какой порог) и как такой сбой обнаружить (учитывая все многообразие возможных причин)?
Чем глубже лезут ваши нанороботы, тем меньше полезной информации вы от них получаете. И самое главное, о чем не стоит забывать: вам придется исследовать не просто гены, белки и молекулы (что даже для одной клетки дает огромные числа, а клеток триллионы), вам придется учитывать, куда все пойдет под воздействием среды (а тут вариантов намного, намного больше).
Может оказаться, что на определенном возрастном этапе новые поломки будут появляться чаще, чем вы будете обнаруживать и чинить старые. Разве что в какой-то стазис вводить организм на время антивозрастной терапии.
Даже самая простая клетка на много порядков сложнее тормозной колодки. Скорее, это огромный завод, где производятся новые автомобили и все запчасти к ним, и где эти автомобили непрерывно ездят, а каждая запчасть на едущем автомобиле автоматически проверяется другими машинами и заменяется по мере износа. И какое-то время вся эта махина успешно работает и даже может порождать другие такие же заводы. Но однажды количество ошибок становится чуть больше, чем то, с которым завод может нормально функционировать. Эффект сильно нелинеен и случаен. Где-то уронили в конвейер гаечный ключ, а конвейер оказался единственным на линии (остальные сломались раньше, но благодаря многократному дублированию это не было критично), и из-за этого не пришли запчасти к одной из машин по починке тормозных колодок, и тормозные колодки стали заменяться чуть реже, и автомобили из-за этого начали въезжать в препятствия на 2% чаще, и однажды две таких аварии произошли одновременно в одном и том же месте, и образовалась пробка, и завод встал. Все, клетка умерла. И такое происходит везде, и в каждой из миллиардов клеток организма — свои сбои, свои нарушения, свои ошибки, своя история от «я еще молода, мне эти мелкие ошибки нисколько не вредят» до «о боже, кажется, я умираю».
Вам bkar очень хорошо расписал, что вы упускаете из виду. От себя добавлю, что вы вряд ли захотите, чтобы в вашем организме происходило то, что происходит с зародышем при его развитии, когда изначально «новорожденные», очень простые и прошедшие жесткий отбор на «чистоту» две клетки сливаются и начинают делиться. У взрослых подобное называется «рак», и в статье хорошо описано, что именно для предотвращения озлокачествления клеток в них встроены ограничительные механизмы, которые и вызывают в итоге старение и смерть клетки.
Это как если вы сдаете машину в аренду какому-то водителю, интересуясь только количеством заказов и прибылью, и однажды обнаруживаете, что автомобиль не просто почти не приносит прибыли, а с трудом ездит и убит в хлам, потому что водитель экономил на ГСМ и запчастях, ни разу не делал техобслуживания и был крайне неразборчив в выборе пассажиров и грузов. Вполне возможно, что к моменту обнаружения истинного положения дел автомобиль будет уже не в том состоянии, когда его рентабельно восстанавливать — придется покупать новый.
С плохим кодом та же самая история. Если бизнес не понимает, что от качества кода, архитектуры, культуры разработки зависит способность итогового продукта приносить деньги, то однажды бизнес обнаружит, что продукт не просто не прибылен, а что он убыточен и уже не может стать прибыльным снова — дешевле переписать его с нуля или заменить на готовое решение от третьей стороны.
Какая best practise для этого в JSON-RPC? Присылать по одной ошибке для каждого неверно заполненного поля, пока все они не окажутся заполненными правильно? Или изобрести свой формат поля data для подобного случая? Есть ли примеры готовой реализации?
Но бывают ситуации, когда этот процесс непрерывного изменения и совершенствования продукта сильно затрудняется или даже замораживается определенными архитектурными решениями, заложенными в проект на заре его становления.
Но допустим, вы можете это сделать. Ок. Что считать «эталоном», с которым вы сравниваете клетки, решая, сбойные они или нет? Клетки без ошибок в ДНК — а много ли таких найдется, если ошибки происходят постоянно, длина спиралей ДНК огромна, а большинство таких ошибок безвредны или успешно «чинятся» встроенными механизмами клетки? Или клетки, в которых экспрессируются «правильные» гены — но из-за дифференциации клеток и различного действия факторов среды количество вариантов астрономически велико даже в пределах одного и того же органа. Может быть, клетки, где синтезируемые белки точь-в-точь сделаны по чертежу — но белков миллионы, мутации генов могут и не ломать белок, а просто делать его менее эффективным, а перебирать все молекулы белков в каждой клетке слишком долго.
Ок, не будем трогать клетку, которую оставили в живых встроенные механизмы защиты организма. Это не отменяет того факта, что она находится в шаге от того, чтобы «сломаться» — переродиться в раковую или перестать выполнять свою функцию. Или в двух шагах. Или больше. Или сценариев, которые могут сделать из абсолютно здоровой клетки больную, сильно больше единицы, и какой из них реализуется — вы не можете знать, это процесс случайный и во многом непредсказуемый. А может, и вообще никакой из этих сценариев не реализуется, а вы уже убили такую клетку, посчитав подозрительной.
Короче, на клетке не висит ярлык — «исправно на 57 и восемь десятых процента, рекомендуется уничтожить, вероятность озлокачествления более 50% в ближайший год». И такой ярлык в большинстве случаев невозможно наклеить по результатам исследования клетки (там, где это возможно, это делают встроенные системы защиты, которые и уничтожают подобные клетки). В это упирается надежность детектирования сбоев: что считать сбоем (какой порог) и как такой сбой обнаружить (учитывая все многообразие возможных причин)?
Чем глубже лезут ваши нанороботы, тем меньше полезной информации вы от них получаете. И самое главное, о чем не стоит забывать: вам придется исследовать не просто гены, белки и молекулы (что даже для одной клетки дает огромные числа, а клеток триллионы), вам придется учитывать, куда все пойдет под воздействием среды (а тут вариантов намного, намного больше).