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

Я одержим порядком.

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

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

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



Документируйте все!

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

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

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

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



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

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

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

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

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

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



План B

У каждой методологии должна быть своя «Модель строгости», нужно выделять самые основные правила и не забывать описывать исключения.

Все принципы методологии необходимо разделить на уровни строгости: от фундаментальных правил до тривиальных.

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

Система должна работать, даже если ее основные принципы вышли из-под контроля.

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

Помните главное Важно всегда помнить фундаментальные понятия.

Наличие плана выхода не означает, что его необходимо использовать.

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

Не должно быть никакого «запасного-запасного» плана; все сценарии следует рассматривать с учетом основных принципов.

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



МКСС

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

Существуют фундаментальные основы и рекомендуемые правила.

Методологию не следует воспринимать как панацею; невозможно продумать все и охватить все возможные сценарии.

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

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

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

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

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

Теги: #MCSS #CSS #методология #презентация #разработка сайтов #CSS #HTML

Вместе с данным постом часто просматривают: