Один из величайших парадоксов разработки программного обеспечения заключается в том, что программисты используют простые текстовые файлы для своего самого ценного актива - кода; тогда как они редко использовали бы эту «технологию» для хранения данных о своих продуктах.

Почти каждый программист, даже самый непреклонный, который никогда бы не подумал об использовании чего-либо, кроме реляционной базы данных для хранения данных, использует базу данных NoSQL при разработке программного обеспечения: файловой системы. А файловая система беспорядочная и неструктурированная.

Почти каждый программист, даже самый непреклонный, который никогда не подумает об использовании нетипизированного или динамически типизированного языка, использует нетипизированные вещи, называемые «файлами», для хранения своего кода. Какого типа ваши файлы? Все ваши файлы имеют следующий тип: String!

Все файлы также имеют некоторые метаданные. Имя файла - это наиболее распространенные метаданные. Имя файла отсутствует внутри файла. Ни его создания, ни дат доступа. И это более или менее то, что предоставляет эта база данных, в которой мы храним наш код, файловая система. Не могли бы вы сделать лучше? Как насчет того, чтобы у каждого символа в нашем коде были какие-то метаданные? Это есть в очень немногих языках, и даже те, у кого есть эта встроенная функция, например Clojure, редко ее используют.

Вы можете возразить, что Git - это своего рода база данных для хранения кода, и в определенной степени это верно. Он хранит данные после некоторого преобразования и оптимизации, а также старые версии данных, но это в значительной степени об этом. В качестве метаданных у него есть «теги», но теги - это метаданные для коммитов, а не для конкретных файлов. В качестве базы данных Git не хватает многих функций, которые предоставляют обычные реляционные базы данных.

Подумайте обо всей организации кода, которую делает разработчик программного обеспечения: перемещение файлов, требование файла из другого файла в виде модулей или типов. Подумайте о запросах, которые мы делаем для нашей кодовой базы: поиск текстового экземпляра или получение списка функций в нашей кодовой базе, или получение зависимых символов для текущего класса или функции. Чаще всего они готовятся в полусыром виде и по запросу. Хотите получить список функций: позвольте вашей среде IDE или языковому серверу проанализировать ваш код и представить вам варианты, только чтобы он в конце концов их забыл. Это почти похоже на то, что метаданные все время регенерируются через компилятор.

Подумайте обо всех дискуссиях об организации кода: должен ли этот файл попадать в эту папку и в эту папку? У вас есть выбор! Вы выполняете операцию «записи», которая строго ограничивает ваши операции «чтения».

Каждый раз, когда вы дважды щелкаете папку в своей системе, вы фактически выполняете запрос для этой таблицы. Каждый раз, когда вы входите в другую папку в этой папке, вы выполняете частичный выбор.

Вы хотите сохранить дополнительные данные о конкретном файле? Куда вы его положили? Внутри комментариев в этом файле? Не было бы лучше, если бы вы могли поместить эти данные как настоящие метаданные, чтобы вы могли их искать?

Разве нам не было бы лучше, если бы наш код хранился в базах данных? Я не защищаю только реляционные базы данных, но даже правильная база данных NoSQL на основе JSON может быть лучше для некоторых операций запроса.

Недостатки этого предлагаемого подхода: вы теряете большую часть функциональности инструментов Unix. В Unix все является файлом, и это хорошая мысль, которая выполнила свою задачу и пока сдерживает нас.

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

Только представьте, как было бы лучше, если бы мы относились к нашему коду так же, как и к нашим данным!

Несколько полезных указателей для дальнейшего исследования:

  • OS / 400 и AS400, где код хранится внутри базы данных как объекты: http://www.wikiwand.com/en/IBM_System_i
  • WinFS: Когда-то Microsoft решила решить эту проблему с помощью WinFS. Для всего были метаданные, но от этого отказались. Этот проект - одно из самых больших сожалений Билла Гейтса: https://www.zdnet.com/article/bill-gates-biggest-microsoft-product-regret-winfs/
    - Кодирование на основе изображений или на основе файлов кодирование: Smalltalk и некоторые Lisp'ы имеют это. Не попал в основной поток. См. Http://wiki.c2.com/?ImageBasedLanguage
    - Datomic и Codeq: Создатель Clojure Рич Хики и база данных его компании Cognitect - это неизменяемая база данных, в которой записываются все изменения. Хики также вкратце поэкспериментировал со сторонним проектом под названием Codeq, который анализировал бы ваш код и добавлял его в базу данных, чтобы вы могли выполнять такие запросы, как: Какие функции были изменены этим коммитом? В каких коммитах эта функция была изменена? См. Https://www.datomic.com и http://blog.datomic.com/2012/10/codeq.html
    - SQLite как формат данных приложения: представьте, что вы храните свой код внутри SQLite чтобы вы могли его запросить? См. Https://www.sqlite.org/appfileformat.html

Смотрите также:

Обо мне: Я консультант и инженер по программному обеспечению, специализируюсь на современных веб-приложениях, с большим опытом работы с архитектурой программного обеспечения, внутренними и интерфейсными технологиями. Следуйте за мной в Твиттере по адресу https://twitter.com/ustunozgur