как создать сложность
Nov. 18th, 2024 04:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoВот я только что придумал.
Предположим, у нас есть код, который по каким-то описаниям пользователя говорит "да" или "нет" (можно ему или нет).
MVP: fn allow_user(...) -> bool
Теперь мы начинаем его выносить в отдельный сервис. Но, вместо того, чтобы завернуть bool в HTTP, мы ... чуть-чуть увеличиваем вычурность.
Пусть у нас будет не bool а лямбда, причём с частичным замыканием. Лямбда может захватывать параметры, в том числе, переданные в описании пользователя, откладывая момент принятия решения. Часть параметров захватывается в момент формирования лямбды, но часть параметров остаётся свободной и должна быть передана в момент evaluate. Поскольку evaluate не хочет знать про сигнатуру лямбды, мы делаем отдельную систему глобальных переменных, которые захватываются по ссылке, и которые могут меняться (т.е. захват неполный).
Поскольку это всё происходит через сеть, наша лямбда - это RPC, причём RPC вызов allow_user возвращает объект, являющийся RPC (от сервера, исполняющего allow_user в сторону сервера, отправившего запрос за allow_user). Разумеется, нам нужен портабельный механизм описания сериализации RPC-запросов.
И может быть, даже, через XML, с глобальным реестром определений для сущностей в запросах.
(И назад этот фарш не провернуть)
Предположим, у нас есть код, который по каким-то описаниям пользователя говорит "да" или "нет" (можно ему или нет).
MVP: fn allow_user(...) -> bool
Теперь мы начинаем его выносить в отдельный сервис. Но, вместо того, чтобы завернуть bool в HTTP, мы ... чуть-чуть увеличиваем вычурность.
Пусть у нас будет не bool а лямбда, причём с частичным замыканием. Лямбда может захватывать параметры, в том числе, переданные в описании пользователя, откладывая момент принятия решения. Часть параметров захватывается в момент формирования лямбды, но часть параметров остаётся свободной и должна быть передана в момент evaluate. Поскольку evaluate не хочет знать про сигнатуру лямбды, мы делаем отдельную систему глобальных переменных, которые захватываются по ссылке, и которые могут меняться (т.е. захват неполный).
Поскольку это всё происходит через сеть, наша лямбда - это RPC, причём RPC вызов allow_user возвращает объект, являющийся RPC (от сервера, исполняющего allow_user в сторону сервера, отправившего запрос за allow_user). Разумеется, нам нужен портабельный механизм описания сериализации RPC-запросов.
И может быть, даже, через XML, с глобальным реестром определений для сущностей в запросах.
(И назад этот фарш не провернуть)
no subject
Date: 2024-11-21 12:09 pm (UTC)Нет.
Он решил не ВСЕ проблемы. Он решил достаточно проблем достаточно хорошим образом, чтобы его можно было задеплоить и продать развертывание проджект-менджеру. Это совершенно не значит, что он решил все проблемы и даже не значит, что он решил их хорошо.
Я хорошо понимаю, что лучшее - враг хорошего, но здоровые амбиции - вещь достаточно полезная.
>Повторю: уважай чужой продакшен, и будут уважать тебя.
Продакшн - не человек, а вещь. Нечего там уважать.
no subject
Date: 2024-11-21 04:03 pm (UTC)Уважать результаты чужого труда - часть уважения к людям.
Моё наблюдение в индустрии, что люди, которые с уважением относятся к чужому продакшену, обычно делают больше хорошего, чем плохого. Люди, которые с неуважением относятся к чужому продакшену, обычно делают больше разрушительного и плохого, чем хорошего.
Это моё личное наблюдение. Возможно, у тебя есть другие наблюдения (например, пришёл в существующую команду рыцарь на белом коне и в одно горло переписал 3 человекогода так, что все окружающие это признали). Мне мой опыт говорит, что в такой ситуации "переписавший" будет горд собой, а вот окружающие довольны не будут и будут постоянно всякую ерунду подкладывать. С точки зрения рыцаря на белом коне это будет признак идиотизма окружающих.
Проекты переписывают, иногда успешно, иногда даже более успешно, чем ожидали, но я ни разу не видел успешно переписанного проекта, в отношении которого не было бы уважения.
no subject
Date: 2024-11-21 06:22 pm (UTC)А два - по ссылке не было критики продакшна, если что. Там была критика некоторых подходов и одного случая, который до продакшна не дошел из-за врожденных косяков.