Модель строгости

    Я помешан на порядке.

    Вся информация должна быть разложена по полочкам — идеи, планы, подходы, методологии.

    Меня пугают мысли о беспорядке — я стараюсь всё систематизировать и изложить в личные заметки, статьи или документации.

    Но что делать, когда система не работает, ресурсы ограничены и специфика задачи не соответствуем идеальным понятиям? Под катом, я поделюсь своими мыслями о “Модели строгости”, касательно методологий разработки и многослойной системы организации CSS.

    Документировать всё!


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

    Система поможет вам держать всё под контролём, и быть готовым к любым трудностям.

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

    Мир не идеален


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

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

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

    План Б


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

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

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

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

    Не должно быть “запасного-запасного” плана, все сценарии должны рассмытриваться от корневых принципов. Система должна оставаться целостной, стройте крепость, готовую к любым осадам, а не стоянку с велосипедами.

    MCSS


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

    Методология не должна восприниматься как панацея, не возможно продумать всё и покрыть все возможные сценарии. MCSS нужно закладывать в ядро собственных документаций и выпиливать под нужды собственного продукта.

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

    Документация открыта для ваших советов и предложений! В ближайшее время будет выложено видео презентации MCSS c Web Standards Days и сопроводительная статья.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 7

    • UFO just landed and posted this here
        0
        Немного оффтопиковый вопрос — в чём сделана презентация? Классно выглядит.
          +1
          Я делал на deck.js, больше интерисовали не эффекты, а функционал перехода по слайдам, и навигация. Из интересных движков есть еше impress.js и Shower от Макеева.
          0
          Завидую я вам. А я постоянно учу себя порядку, но энтропия берет надо мной верх
            0
            Как бы не было лень писать документации, в команде без этого никак, особенно на крупных проектах.
            0
            >Документировать всё!
            Подскажите удобный документ, где можно документировать все?
            WiKi — не очень для этого подходит.

            Был проект ru.wikipedia.org/wiki/NPJ
            Идея хорошая, но вот развитие дальше не пошло, а жаль.
              0
              Нам пока достаточно вики, для текстовых документаций + собственная среда прототипов и документаций по вёрстке, которую в ближайшее время думаем выпустить в опен сорс.

            Only users with full accounts can post comments. Log in, please.