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

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

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

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

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

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

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

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

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

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

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

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

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

План Б

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

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

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

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

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

MCSS

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

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

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

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