пятница, ноября 28, 2008

Time to live

У каждого предмета есть определенное время жизни. Рано или поздно он устареет, износится и потребует замены новым. Или просто исчезнет проблема, ради решения которой этот предмет создавался, как исчезли мундштуки, подстаканники, пресс-папье и буфеты. Это касается не только материальных объектов, но и информации, в том числе и информационных систем. У каждой строчки кода, у каждого килобайта данных есть собственное время жизни. Время жизни есть даже у таких неосязаемых сущностей, как идеи или соглашения. Для того, чтобы научиться оценивать характерное время жизни, нужно хорошо понимать механизмы разрушения объектов. Например, автомобиль может разрушится в результате аварии, физического износа или морального устаревания. Если известно, что автомобиль морально устареет через 10 лет, нецелесообразно обеспечивать его надежную работу в течение большего срока. Все равно к тому времени он уже окажется под прессом. Знание характерного времени жизни позволяет поддерживать качество на необходимом уровне, не больше и не меньше. Зачем делать автомобиль надежным, если через 10 лет он все равно окажется на помойке, где не важно работает он или нет.

Данные

Оставим за скобками временные данные, которые на то и временные, что их время жизни невелико. Для данных постоянных время жизни составляет от 25 лет до бесконечности. Данные редко становятся не нужны, a накопленные за долгие годы данные невозможно ничем заменить. Например снимки допоптопных аппаратов советской серии Венера, несмотря на отвратительное качество будут жить еще долго. Сперва в качестве основного источника информации, затем для сравнения с современными снимками и анализа изменений. Обычно, вменяемые люди стараются не уничтожать данные, мало ли что еще пригодится. Вдруг завтра из них удастся извлечь новую информацию. Мне доводилось работать с базами, которые пережили три поколения бизнес-кода и переживут еще как минимум столько же. Поэтому к проектированию баз данных нужно относиться особо внимально. Любое ваше сиюминутное решение в угоду производительности или простоте кодирования будут с матюками вспоминать через много лет. Изменить что-то в унаследованной базе, в которой уже накопились гигабайты данных нереально сложно.

Протоколы и стандарты

Две причины, по которым устаревают стандарты и протоколы: они перестают отвечать изменившимся требованиям или появляется способ сделать то же самое проще. Поскольку технологии непрерывно меняются и то, что раньше требовало дестятка PhD, сегодня доступно школьнику, редкий стандарт проживет больше 10 -- 15 лет. Затем, если представится возможность, он отправится на помойку истории. К сожалению это происходит не всегда. Очень часто изменения уже внедренного стандарта, процесс настолько болезненный, что стандарт активно используется не смотря на то, что они окончательно устарели. В качестве вопиющих примеров можно вспомнить Z39.50, SMTP, FTP и HTTP. К проектированию стандартов имеет смысл относиться даже более внимательно, чем к проектированию баз данных. "Внимательно" в данном случае означает не "предусмотреть все возможные случаи", а обеспечить возможность изменений. Все равно предусмотреть все не удастся, а если и удастся, то этим все равно не станут пользоваться из за непомерной сложности.

Код

Срок жизни кода определяется сроком жизни требований и сроком жизни платформы. В любом случае, срок жизни прикладного кода составляет 5 -- 10 лет. К этому моменту он оказывается практически полнотью переписанным с нуля. Часто, код преписывают весь сразу, одновременно с переходом на современную платформу. Конечно, бывают и исключения. Чаще всего они связаны либо с неизменными в течение десятилетий требованиями, либо с очень высокой ценой апгрейда. Например, связанного с высокой ценой миграции данных. Код ядра живет дольше в силу того, что зависит не от зыбких пользовательских требований, а от технических ограничений. Однако и технические ограничения меняются: если раньше несколько процессоров встречались только в серьезных серверах, то теперь многоядерные процессоры добрались до ноутбуков. Даже если завтра ваши алгоритмы и не изменятся, не исключено, что им придется работать совсем в другой среде, что влечет за собой переписывание кода.

Абстракции и модели данных

Абстракции живут от нескольких минут до тех пор, пока их помнят или пока не придумают что-то получше. Двойная бухгалтерская запись была изобретена в XV веке, а используется по сей день, несмотря на то, что в эпоху компьютеров без нее легко можно обойтись. Даже если абстракция хреновая, она все равно не умирает. Слишком много всего от нее зависит. Тут и код, и привычки людей, и их внутрення картина мира. Если вы предложите бухгатерам отказаться от двойной записи, они вас съедят. Будьте осторожны, если ваша абстракция получит распространение, вы ее уже не остановите.

Пользовательский интерфейс

Пользовательский интерфейс протухает за 3-5 лет. Он подвержен тем же изменениям требований что и код, вдобавок новые интерфейсные технологии появляются ничуть не реже программных. Даже отличный интерфейс пятилетней давности выглядит малость устаревышим, а десятилетним интерфейсом современному человеку пользоваться неудобно, да и глаз режет. Метафоры за 10 лет успели сильно измениться. Если пользователи не могут сбежать, устаревший интерфейс удается сохранить два-три срока. Затем начинаются проблемы уже с поиском операторов, способных работать на таком старье.

6 комментариев:

kleptos комментирует...

что не так с http?
алсо, юниксовому шеллу уже скоро сороковник стукнет.

Miroff комментирует...

С HTTP все так, в том смысле, что раздавать статичные данные он годится. Вот только интернет ужел далеко вперед с тех пор. Сегодня ему требуется:
а) идентификация пользователя на уровне протокола (сейчас для этого требуются приседания с куками, непрозрачные и череватые уязвимостями)
б) безопасная аутентификация (сейчас либо аутенификация средствами браузера, либо передача пароля в открытом виде через GET/POST запрос либо какое-то рукопашное решение на JS)
С юниксовым шеллом та же фигня. Он был неплох 20 лет назад, но с тех пор сложность решаемых задач радикальна возрасла. Шелл все еще отлично годится для старых задач типа поиска и перименования файлов, но не для что-то более сложное требует тонн "клея" вроде perl или awk. Это ситуация из разряда "на безрыбье", а не "меняется потому что идеален".
Навскидку, из того, что я бы изменил в шелле:
а) Можно гонять по пайпам не plaintext, а типизованные данные. Это на порядок уменьшит необходимое количество "клея"
б) Можно упростить синтексис шелл скриптов, приблизив его к соременным скриптовым языкам, вроде ruby или python. Это уменьшит размер скиптов и упростит поддержку.
в) Еще бы неплохо интегрировать в шелл scp, чтобы шариться по удаленной машине, как у себя дома.

Юникс шелл давно уперся в тупик и перестал развиваться. Проблема в том, что на кардинальные изменения сообщество не пойдет, просто потому, что не договорятся, а мелкие ченджи ситуации не исправят. Тем временем Microsoft зарелизила PowerShell...

kleptos комментирует...

http это transport layer, не надо в его стандарт пихать application семантику.
если так приспичило - его расширябельность в этом поможет. алсо, не стоит забывать про ssl, который снимает много головной боли про секурность.

пассаж про scp смешной очень.
в modern шеллах это уже давно есть, навскидку - tcsh, zsh, bash.
есть некоторые проблемы конечно (а у кого их нет?) например отсутствие единого стандарта описания метаданных комплита.
со скриптингом - примерно то-же самое, современные шеллы в этом плане значительно удобнее.

тайпед пайпы - таки да, было-бы удобнее. и многое упростило-бы.
идея в некотором смысле лежит на поверхности, для того, кто хоть сколько-то времени про шелл думал.
что забавно, оно реализуется поверх существующего стэка щелла, не сложнее того, как это сделано с комплитом.
но почему-то до сих пор не, наверное потому-что за последние 10-20 лет появилась груда языков, которые значительно удобнее для решения таких больших задач, а для мелких шелл fits perfectly.

а в целом идеи интегрировать аутентификацию в http и scp в шелл наводят на мысли о монстрах сложности вроде emacs или Ws-DeathStar, а не о простых, гибких и стакабельных стандартах и реализациях - именно таких, какими они должны быть.

Miroff комментирует...

Если HTTP это transport layer, то так и стоит декларировать. А заодно явно определить полноценный стек протоколов работающий поверх HTTP. Есть такое? Нет, нету, хотя было бы неплохо. Зато аутентификация и многие другие application domain фичи в HTTP уже имеется. Тут уж, Рабинович, или синмите крестик или наденте трусики.

С scp я, наверное, что-то пропустил. Неужели современные шеллы позволяют cat scp://miroff@example.org/proc/cpuinfo или что-то подобное? Максимум, что я видел, это автокомплит.

Опять же интеграция чего-то с чем-то это совершенно необязательно монстр. Идея вообще ортогональна реализации. В тот же шелл вполне можно встроить поддержку вритуальных файловых систем и будет вполне просто, гибко и стакабельно. Заодно можно будет делать так: vim backup.zip/some_file или так: vim ftp://example.com/other_file

С тем же автокомплитом фигня, потому что работает от от силы для 5 процентов программ, для которых удосужились прописать метаданные. Если тем же путем реализовать типизованные пайпы, получится та же полурабочая фигня. Зато будь вывод команды --help типизованным, автокомплит мог бы основываться на них и работать вообще всегда. С другой стороны пофиг как реализовывать, работы все равно много. До тех пор, пока какой-нибудь дистрибутив не захочет сделать из этого маркетинговой фичи, никто этим заниматься не станет.

kleptos комментирует...

Hypertext Transfer Protocol - уже вроде в названии задекларировано.

cat scp://miroff@example.org/proc/cpuinfo это вообще не к шеллу, это к cat.

и виртуальные fs нафиг не нужны, когда есть реальные.

про комплит - наверное у меня какой-то глобус другой, но у меня наоборот, для ~80% софта есть.

алсо, не надо делать типизированый вывод команды help, его ещё людям читать.
такие вещи можно и нужно складывать в отдельные файлики.

Miroff комментирует...

Вот только название не соответствует реальности уже с выходом HTTP 1.0 Вот тогда-то он и протух.

Именно к шеллу. Не переписывать же все команды чтобы они понимали scp. А вот научить шелл качнуть файл а потом подменить параметр команды cat вполне реально.

Может я что-то пропустил. Я могу посредством шелла ковыряться в архиве или другом формат-контейнере не распаковывая его? Или работать с удаленной файловой системой? Почему-то user level тулзы вроде windows explorer, far, krusader, konqueror или nautilus это позволяют, а шеллы, даже самые модерновые, нет. Не потому ли что шелл безнадежно устарел?

Из типизованого вывода легко сделать плейнтекст автоматически. А вот "держать информацию в специальном файле" мы уже проходили. В результате этот файл мейнтейнится по остаточному принципу и в конце концов протухает. Все движется в обратном направлении: держать метаданные в файле, документацию в коде, а типизацию ввода/вывода логично осуществлять на уровне системной библиотеки. Используешь либу -- автоматически получаешь типизацию для пайпов. Парсишь параметры сам -- злобный буратино.