Про кубики и монолиты

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

Сегодня наши читатели из Сиэттла интересуются, что можно сказать о маленьких и больших тулзах.

Большие мега-тулзы, которые делают всё, с детства вызывают двойственные чувства. Одно из ярких малолетних впечатлений – это характерный швейцарский нож. В нем было вообще всё, что я мог себе представить; и это вызывало чувство глубокого эстетического восхищения. Однако даже в дошкольном возрасте работать отверткой или, упаси высшие силы, подстригать когти на руках ножничками из того ножа – никакого удовольствия не доставляло. Очевидно неудобно пользоваться, зато очевидно удобно носить “на всякий случай”, занимает сравнительно мало места.

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

Место в современных системах экономить довольно глупо. UNIX подход, придуманный десятки лет назад, живет и процветает – набор мелких утилит, каждая из которых хорошо решает одну (!) тривиальную задачу, нехитрыми завязываниями входов и выходов решает кучу существенно менее тривиальных повседневных небольших задач. Можно проверять корректность имен текстур (регистр, спецсимволы итп) специально написанной батч-загрузкой всех моделей в мега-редактор. А можно отделаться одной командой, содержащей заклинания grep и perl -e.

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

Я не строю типовые монолитные дома без возможности перепланировки, я только делаю кубики Лего. Строят всякое уже пользователи моих кубиков. И поскольку две и две трети пользовательские головы – это сильно больше, чем моя личная половинка, получается чудесное. У некоторых Эйфелева башня, а у некоторых даже и Голден-Гейт.

И выглядит он сильно приятнее, чем монолит с плохой строительной отделкой.

  • CEMEH

    Так как Шодан обещался отвечать на вопросы обстоятельно и подробно…

    Какие задачи жизненные удобнее решаются сцепливанием маленьких тулов (хочу примеров)? Какого уровня задачи решаются каждой тулой? Писать большую плохо только по соображениям стоимости разработки? Не может быть так, что это компенсируется затратой денег на арт и левел-дезайн?
    Почему у UE3 и CryEngine монолитный тул?

  • coolace

    Мой опыт на 100% подтверждает то, что Шодан говорит. Видел кучу плохих больших тулзов и много хороших маленьких и на то причин просто дофигища, это примерно как то до чего недавно совсем дошли наши программисты, типа собирать игровые объекты из кубиков-функциональностей лучше чем делать один мега-геймобжект и потом наследованием получать “паровой поезд с тремя вагонами”.

  • http://aruslan.livejournal.com/ aruslan

    При низком старте – набор вменяемых ясных и простых инструментов безусловно зарулит мегатулзу.
    Хотя бы потому, что мегатулза в низком старте всегда происходит не от большого ума, а от как обычно.

    В низком старте любая сложность – всегда accidental, от неумения, нежели чем от задачи.

    Очевидно и другое.
    Говорить “простая и ясная тулза” в отрыве от “и скрипты и makefiles вот этими самыми руками” нечестно.
    То есть /bin/sh в каком-то смысле тулза простая (была во всяком случае в девичестве), но вот что творится при старте Linux – это видимо уже не к тулзе.
    А к процессу конфигурирования оной.
    И через это – надо честно признавать, что клей системы просто выносится за пределы тулзы.
    Чем и достигается превосходный complexity management в данном конкретном месте.
    Ценой peopleware сразу за его пределами.

    Проблема framework vs library и мегатулза vs меганабор простых тулзов – она в орг процессах и тех интерфейсах.
    Когда vec4 входит в базовую библиотеку, а потом она начинает работать с Perforce, и десятки-сотни людей работают с этим одновременно, и версионированно – то граница между мегатулзой и меганабором быстро размывается.

    Что собственно ясно выражается в случае мегатулзов на .NET-фреймворке, который часто получается вполне себе UNIХ-подобным решением.

    Потому что даже fetch_from_p4 | process | inject_to_running_game_at_console потребует более чем определенного интерфейса и канонических форматов/структур.
    А когда тот самый “process” выкидывает ошибку, то вот здесь начинается вовсе не accidental сложность, а вполне себе фича.

    Одно несомненно – простые и ясные (пусть и резко ограниченные) тулзы – они вирусны по природе и легко встраиваются.
    Всегда есть люфт между заменой монструозного гэ изящным набором простых тулзов
    и осознанием почему то гэ было таким монструозным.

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

  • http://aruslan.livejournal.com/ aruslan

    А теперь – собственно про кубики и монолиты.
    Монолиты (если их просветить рентгеном) – вполне себе комплекты кубиков с заранее зафиксированными связями.

    И когда дядя Дима говорил про кубики, я говорил про пинауты – про контекст и структуру связей между кубиками.
    Которые фиксируются и обработкой ошибок, и порядком вызовов / зависимостями по данным, и она еще параллелизуется и умеет не вычислять по сто раз одно и то же.

    Совместное использование контекста и управление структурой связей – и есть реальная complexity.
    И именно её пытается скрыть фреймворк.
    А в системе кубиков автоматизацией её сокрытия занимается тот самый build/tools engineer.
    Весь вопрос – у кого лучше получается.

    Иными словами – слишком многие тулзы выиграют если они будут совместно использовать (share) контекст.
    Любые IDE в общем-то, включая DCC типа 3DS/Maya/XSI.
    Редактирование и компиляция и отладка и контроль версий – классический пример когда контекст есть и его разделение приятно.

    “Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
    Это такое приятное дополнение к десятому закону Гринспуна.

  • IronPeter

    Everything that can be a source- and destination-independent filter should be one.

    Data streams should if at all possible be textual (so they can be viewed and filtered with standard tools).

    Database layouts and application protocols should if at all possible be textual (human-readable and human-editable).

    Complex front ends (user interfaces) should be cleanly separated from complex back ends.

    Whenever possible, prototype in an interpreted language before coding C.

    Mixing languages is better than writing everything in one, if and only if using only that one is likely to overcomplicate the program.

    Be generous in what you accept, rigorous in what you emit.

    When filtering, never throw away information you don’t need to.

    Small is beautiful. Write programs that do as little as is consistent with getting the job done.

  • http://aruslan.livejournal.com/ aruslan

    Да-да, из Майки – в колладу, потом обработка, потом сборка, и, не торопясь, копируем на консольку. А там глядишь уже и игру запускать можно.
    А если где-то обломилось – так и скажем (пользуясь той инфой что оказалась под руками).

    There are two ways Unix programmers can address this problem.
    One is to deny that large is actually large.

  • IronPeter

    А почему бы и нет собственно? Несколько рабочих станций, выстроенных в пайп. На первой крутится Майка, на второй билдер и оптимизатор, на третьей сборщик. И все это по Fibre Channel с перфорс-сервером соединено.

    Нажатие на цапку “интегрируй мне модельку”, 100ms – и моделька на консольке.

  • http://aruslan.livejournal.com/ aruslan

    Вот и я говорю. Дело – не в кубиках ;)

  • http://aruslan.livejournal.com/ aruslan

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

  • Balmer

    Да, тоже нравятся кубики. Особенно весело/грустно, когда начинают строить монолит на недоделанных кубиках.