Технологи любят разрушать другие отрасли. У нас есть банковские услуги, ориентированные на приложения, беспилотные поезда, пылесосы с одним щелчком мыши и кошки на базе технологии Blockchain - все потому, что технолог не удовлетворен существующим положением дел.
Единственная отрасль, которую мы боимся подорвать, - это наша собственная.
В программистах есть что-то такое, что делает нас невероятно консервативными, когда дело касается программирования. Мой любимый текстовый редактор Spacemacs - красивый скин поверх 40-летнего, я не могу жить без своего репозитория сценариев оболочки, и если бы не гифки Иззи 🐶 , Я бы сразу бросил Slack.
У цепляния за прошлое определенно есть свои недостатки, но я не могу придумать ни одного места, где это было бы хуже для нашей производительности, чем скромная файловая система.
Древовидная структура слева от меня является обычной - по сути, это часть дерева файлов для prodo.dev, нашего нового продукта. Некоторые файлы мы написали, некоторые были сгенерированы или загружены. Есть компоненты React, функциональность приложения, таблицы стилей, маленькие вспомогательные виджеты… что угодно. Но в основном я вижу беспорядок.
Файловая система - это ограничитель, мешающий мне. Это древняя часть инфраструктуры, созданная по сотне различных причин, по которым мне нужно ориентироваться и понимать каждый раз, когда я что-то делаю. И обещанное преимущество - то, что любой инструмент может работать с файлами - не выдерживает критики, когда мы теперь работаем на уровне репозиториев, проектов, компонентов и функции.
Вот лишь несколько причин, по которым файловая система меня подводит.
- Сохранение файла несколько атомарно. Работа с несколькими файлами - нет. Если я переименую компонент в нескольких файлах, все, что просматривает эти файлы - горячая перезагрузка для моего веб-сайта, моя программа для выполнения тестов и т. д. - будет запускаться несколько раз. Шутка, особенно, настоящая боль, запускать мои тесты несколько раз всякий раз, когда моим редактором создаются временные файлы.
- Между файлами, которые мне нужны, и файлами, которые мне не нужны, очень мало различий. Первые я хочу, чтобы управлять версиями, создавать резервные копии и предоставлять к ним доступ моим коллегам. Мои node_modules, не так уж и много. Их размещение в одном каталоге со всем остальным приносит больше вреда, чем пользы.
- Файлы находятся в виде дерева, но мой код представляет собой график. Вышеупомянутые файлы были разделены, чтобы все компоненты пользовательского интерфейса работали вместе, что в некоторой степени полезно, если я работаю с компонентами и вообще бесполезен, если я работаю с одним компонентом и его состоянием. В таком случае я хочу увидеть код компонента, его тестовый код (который находится далеко-далеко) и все, что находится в каталоге redux. Переход между файлами в репозитории - это уровень когнитивных затрат, который мне не нужен.
- Файлы можно отсортировать по пути. Незначительно полезно, когда я чего-то ищу, но это стало костылем. В запросе на вытягивание GitHub сортирует по пути к файлу, даже если это бессмысленно. Почему мои модульные тесты не отображаются рядом с кодом реализации? Потому что я помещаю их в каталог test, потому что этого требует мой исполнитель тестов.
- Мои исходные файлы содержат текст. Текст хорош, потому что он универсален, но в остальном это ужасный способ представления кода. Он может быть полностью недействительным или неправильно сформированным (например, вы можете сослаться на несуществующую функцию), и его необходимо проанализировать, прежде чем вы сможете сделать с ним что-нибудь полезное. Мой код взаимосвязанный граф модулей, функций, классов, переменных и других концепций, и представление их в виде текста означает, что все мои инструменты - моя тестовая среда, сборщик, линтер и т. д. - в 10 раз медленнее, чем они должны быть.
- Предполагается, что код, который расположен ближе друг к другу, более связан и связан, а код, расположенный дальше, разъединен. Это далеко от истины. Это кажется таким, потому что мы так это визуализируем, но обычно наши приложения представляют собой мешанину циклических зависимостей, которые работают в основном случайно. Наша файловая система обманывает нас.
Я мог бы продолжить, но я думаю, вы поняли идею.
Как программисты, мы работаем с мыслями, превращая их в нечто конкретное и четко определенное и кодируя их таким образом, чтобы компьютер мог реализовать наши желания. Мы используем такие концепции, как функции, модули и репозитории, для представления этих мыслей, называем их, чтобы мы могли их найти и повторно использовать, а также разрабатываем тестовые примеры, чтобы мы могли убедиться, что они работают.
Где файлы играют в это?
В Prodo мы работаем над чем-то другим. Когда вы используете наш новый продукт prodo.dev для создания компонента React, вы создаете компонент. Вы пишете JSX, а не файл .jsx; сантехника неактуальна.
Перестаньте думать о средствах, с помощью которых компьютер сериализует ваш код на диск, и начните думать о самом коде.
Попробуйте prodo.dev.
