💡 Идея: Весь код проекта в одном файле (Плагин для IDE)  Публичный пост

Проблема:

Я не хочу отвлекаться на абстракцию файловой системы, я хочу писать код.

Названия файлов HomePage.js и tasks.py не сильно отличаются от class HomePage или @task() def send_emails семантически, но все равно создают лишнюю нагрузку.

Почему, когда я хочу создать класс, мне нужно:

а) создать новый файл
б) придумать, как его назвать
в) выбрать папку, куда его положить
г) задуматься, какое у него должно быть расширение.

Пускай за меня думает машина?

Концепт:

Весь код лежит в одном большом полотне, где его можно скроллить туда сюда. "Под капотом" это все равно работа с файлами, просто они динамически приклеиваются при скролле.

Плюсы:

  • Создание нового файла это просто нажать три раза на Enter. Если хочется явно указать, что это точно новый файл, есть разделитель типа

// # MARK - src/Home/FeedItem.jsx

  • Вместо поиска нужного файла через дерево директорий можно просто делать Ctrl+F по полотну.

Почему же тогда раньше от этого отказались? Почему сейчас никто не пишет весь код в App.tsx?

Три главных возражения

  1. Если у тебя больше мелких файлов, то у тебя меньше проблем потом с конфликтами в git.

Да, именно поэтому умный шредер сам нарежет мое полотно на файлы. Я пока не знаю, как умно нарезать файлы по директориям, но как промежуточное решение, это можно указывать вручную специальными комментариями.

  1. Один большой файл с маркерами дает только линейную структуру, а для больших проектов нужна древовидная.

Это хороший аргумент, но это полотно не обязано быть статическим. Сразу три варианта решения:

  • Выпадающие списки для каждой директории, как сейчас мы можем "сворачивать" методы, чтоб лучше видеть весь файл (никогда не видел, чтоб кто-то этим пользовался)
  • Двумерный скролл – слева более глобальный вид: директории и названия классов, справа конкретный код
  • Выбирать "галочками", какие файлы отображать в полотне в каждый момент
  1. Один большой файл будет дико тормозить.

Сейчас у нас эта вкладка с текстовым редактором тратит больше ресурсов, чем вся IDE 10 лет назад. Плавно скроллить 20 тысяч строк текста не такая уж сложная задача.

Примерно как Айфон, когда скроллит твиты, на самом деле не выводит все на экран, а незаметно подгружает новые, когда чувствует, что вы почти дошли до предела.

Референсы:

  • В Objective-C так было принято: из-за того, что один файл = один класс, а иногда в класс типа LoginViewController нужно было много чего напихать, там есть штука, которая позволяет быстро ориентироваться в полотне методов класса

// #MARK: - LoginDelegate implementation

code example
code example

  • В Figma весь дизайн лежит на одном полотне. Это удобно по той же причине – можно быстро отойти в сторону и найти нужный кусок.

P.S.

Не знаю, возможно это только у меня такая проблема, но Мак про 2015 года с SSD открывает или сохраняет новые файлы секунд 5-10. Да и в целом, IDE типа Atom или VSCode какие-то не очень приятные, когда дело касается файлов. Может, мне просто нужен новый компьютер ))

18 комментариев 👇
Anna Karpenko, бетонист 29 июня 2020

😱 Комментарий удален его автором...

  Развернуть 1 комментарий
Andrey Bondarenko, Senior System Engineer 29 июня 2020

/dev/sda - тоже файл.

  Развернуть 1 комментарий
Anatoly Shipitsin, Специалист по НЕХ 29 июня 2020

У вас какого размера был последний проект?

  Развернуть 1 комментарий

Ну, наверное, последний – на полгода работы одного человека. Не очень большой, а что?

  Развернуть 1 комментарий

@caffeinum, ну вот по этому такая идея и пришла в голову. Как только проект разрастается и становится сильно больше, распиливание его на части и раскладывание кусочков становится благом. И никакая машина тут не поможет.

  Развернуть 1 комментарий

@norguhtar, ну я подумал об этом – моя идея в основном в визуальной части, а не в том, как автоматически разрезать. Распиливание на части – благо, согласен. А в чем благо каждый раз спрашивать разработчика, какое расширение должно быть у файла?

  Развернуть 1 комментарий

@caffeinum, в IDE от Jetbrains и не спрашивает, спрашивает тип файла, а дальше расширение само ставит. Так лучше?

  Развернуть 1 комментарий

@norguhtar, нет, особо разницы нет – то, что я выбираю между .js и .jsx, или между JS File и JSX File. Я хочу писать код, а не файлы

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

Но это все ненастоящие решения, а какое-то запихивание под ковер.

  Развернуть 1 комментарий

@caffeinum, вполне нормальное решение. Компьютер не настолько умен, чтобы угадать какой файл надо. В рамках фреймворка он может уметь раскладывать файлы по шаблону и не более. В случае языка там уже выбор структуры зависит от проекта.

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

  Развернуть 1 комментарий
Vlad Zaitsev, Architect & Product Owner 29 июня 2020

Вот есть у меня проект, в котором штук пять смысловых частей — работа с бд, с сетью, парсер протокола, еще что-нибудь. Если я работаю над одной частью, мне не надо видеть остальные — я хочу перемещаться в пределах одной части, и знать, что если промотаю наверх, или поищу "create", то увижу первую функцию модуля работы с бд, и функцию "create_tuple", а не "сreate_file".
А что мне делать в описанном подходе? Держать все в одном "файле"? Так неудобно. Разбивать на разные части? А чем это отличается от того, что у меня сейчас?

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

  Развернуть 1 комментарий

Наверное, я тут предложу вариант с двумерным полотном – если сделать скролл вправо, то окажешься на уровне "смысловой части", например, в разделе про сеть. Если влево – то видно пять больших "директорий". Если до конца вправо, то там только один файл или даже метод.

То есть, дерево можно оставить, но дать возможность легко перемещаться по нему

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

  Развернуть 1 комментарий
shvembldr, Frontend Developer 29 июня 2020

Странно видеть, что кто-то пишет комментарии здесь...

  Развернуть 1 комментарий
Mikhail Aksenov, Винстон Вульф в команде разработки, решаю все проблемы 29 июня 2020

Несколько проблем:

Непонятно, что это реально приносит в воркфлоу.

Отнимает свободу выбора инструмента, если это в одном файле.

Не проще ли тогда сделать наоборот и -склеивать- в один файл для презентации тогда?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

Хорошо.

Теперь главный вопрос: что с мультиязыковыми проектами делать? Ведь sql, js, go, py в одном файле и смотреть неудобно и language server поддерживать будет со скрипом.

  Развернуть 1 комментарий

@thecoldwine, неплохой вопрос, но я с такими мало работал, поэтому задам встречный: а какие у вас есть идеи? :)

  Развернуть 1 комментарий

@caffeinum, честно?

Я бы не изобретал велосипед, потому что именно файлы во всем флоу разработки меня напрягают меньше всего.

Самый яркий представитель переопределения структуры проекта поверх существующей файловой - Visual Studio с их .+proj проектами и это кошмар. Во-первых, это требует инструментов, которые под это заточены, во-вторых хуже автоматизируется, в-третьих кто в лес кто по дрова всегда.

Если бы я делал перегрузку, то я бы наверное начал с интерпретации файлов по ролям в проекте и представлении их как объектов. Ну то есть скорее радикально менял воркфлоу в духе смоллтока.

  Развернуть 1 комментарий
Сева Родионов, джаваскрипт-шалун, техлид 29 июня 2020

Я все думал в сторону и бд по типу neo4j или couchDB, и какой-то плоской структуры с тэгами в своё время. Увы, это почти никуда не интегрируется, и в этом главная проблема

  Развернуть 1 комментарий
Gleb Kudriavtcev, Руководитель продуктов 29 июня 2020

В ряде ЯП файлы - это first type object и эрзац неймспейсов. Это тупо, но это факт и под это заточен даже не визуал, а сами технологии. Сука, оно реально собирается файликами. Так что такая история там просто не получится или будет вызывать кучу трудноуловимых ошибок.

Ну и про удобство уже выше все сказали, в реальности это неудобно.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб