По словам Гарри Робертса, старшего разработчика пользовательского интерфейса в BSkyB, разработчикам следует использовать концепцию под названием shame.css, чтобы изолировать любые быстрые исправления и взломы CSS в проектах.
Робертс объяснил в своем блоге, что это может помешать разработчикам увидеть взломы, пронизывающие CSS, и, таким образом, подумать, что такие вещи приемлемы по умолчанию.
Кроме того, в статье отмечалось, что такой подход, если он должным образом задокументирован и сопровождается средствами для итерации, может обеспечить более быстрый переход к более чистому CSS в проектах, где использовались хаки (по любой причине).
.net поговорил с Робертсом (HB) о взломе CSS и потенциальных преимуществах, которые shame.css может принести при правильном использовании.
.net: Как вы думаете, есть ли у некоторых людей в отрасли тенденция нереалистично относиться к необходимости (надеюсь) краткосрочных взломов, чтобы заставить сайт работать?
HR: Долгое время. Если вы работаете над сайтом или продуктом, который приносит миллионы фунтов стерлингов в год, любые ошибки, поломки или причуды необходимо исправлять как можно скорее. Владельца продукта не волнует, совершенен ли ваш CSS - он заботится о том, чтобы сайт был в рабочем состоянии и функционировал, а также за счет этого дохода. Хороший код является важно, и хаки далеки от идеала, но думать, что вы всегда можете предотвратить взломы и краткосрочные / быстрые исправления, - это неважно.
.net: Значит, вы бы сказали, что они просто необходимое зло в бизнесе?
HR: Когда клиент дышит вам в шею или какая-то функция на действующем сайте не работает, вам нужно убедиться, что вы довольны правильными заинтересованными сторонами. Если вы потратите час на написание идеального исправления для чего-то, что вы могли бы поверхностно исправить за две минуты, я бы сказал, что вы делаете счастливым не того человека, то есть себя!
В своей собственной работе я обнаружил, что «потребность» во взломах возрастает довольно пропорционально размеру проекта, но хорошо в том, что у вас также, вероятно, позже будет больше проектного времени, посвященного исправлению этих взломов.
.net: Здесь на помощь приходит shame.css. Что конкретно вы считаете взломом CSS с этой концепцией?
HR: Что-то, что можно было бы сделать лучше, если бы было больше времени. Трудно думать о примерах вне контекста, но я думаю, что вы часто узнаете, когда что-то взломано. Написали то, что вам было бы стыдно объяснять коллеге? Наверное, это взлом!
Следовательно, shame.css предназначен для создания файла того, что вы могли бы сделать лучше, и что вы можете сделать лучше, когда у вас будет время вернуться к ним. На самом деле это самописный список дел - набор хаков, которые вы откладываете в сторону, чтобы подумать, когда у вас будет больше времени.
.net: В своей статье вы упоминаете о документировании взломов, но разве нет аргументов, что разработчикам в любом случае следует больше документировать CSS, а не только для взломов?
HR: Да! Если есть одна вещь, которую все разработчики должны делать больше, так это писать комментарии. Вы должны комментировать все, что не сразу очевидно из кода. Задокументируйте свой код, чтобы, если вас сбит автобус по дороге домой, ваш коллега смог бы взять его на себя на следующий день.
.net: Что вы предлагаете с точки зрения интеграции shame.css?
HR: Если используется препроцессор, @Импортировать в позор. [scss | less | etc] файл в самом конце, в идеале. (Это всегда может привести к проблемам со специфичностью и порядком источников, поэтому ваш пробег может отличаться.)
Если вы не используете препроцессор, но у вас есть приличный процесс сборки, весь ваш CSS должен быть объединен и минимизирован перед развертыванием, так что, опять же, shame.css можно закрепить до конца.
Если вы не используете препроцессор а также у вас нет процесса сборки, то, во-первых, вы, вероятно, должны это исправить, и, во-вторых, раздел хаков в конце вашей таблицы стилей, вероятно, будет вашим лучшим выбором. Shame.css не предназначен для публичного просмотра, поэтому никогда не создавайте отдельной таблицы стилей, вызываемой элементом ссылки в вашей разметке. Вы должны обслуживать только одну объединенную и уменьшенную таблицу стилей.
.net: Если концепция shame.css действительно популярна, как, по вашему мнению, он может изменить процесс дизайна и веб-сайты в целом?
HR: Shame.css настолько же полезен, насколько и разработчики, которые его реализуют. Это все хорошо, и хорошо изолировать и документировать хаки, но если вы никогда не исправляете и не пересматриваете их, вы просто находитесь в той же лодке, что и раньше.
Для меня shame.css означает более широкий сдвиг в развитии; его не нужно ограничивать CSS. Концепция просто «осознание, документирование и анализ ваших хаков». Вы можете применить это мышление ко всему.
Настоящая работа, связанная с shame.css, заключается в том, чтобы привлечь к работе вашу непосредственную команду (разработчиков), а затем информировать бизнес / менеджеров по менеджменту / мастеров схватки / бизнес-менеджеров / владельцев продуктов (и т. Д.) О том, что продукт иногда будет включать меньше -чем идеальный код, но этот код существует для удовлетворения бизнес-требований.
Скажите им, что вы изолируете и документируете хаки и выделяете время на разработку, чтобы привести в порядок вещи. Легче создать экономическое обоснование для наведения порядка в кодовой базе, если вы можете дать количественную оценку. Если просто сказать своему менеджеру проекта: «Мне нужно кое-что привести в порядок, прежде чем я смогу перейти к Feature X», это не всегда означает! Составьте список дел и постарайтесь выделить полдня спринта на уборку.
Идея shame.css состоит в том, чтобы сделать ваши хаки более прозрачными, поддающимися количественной оценке и изолированными. Что делать с этой информацией - решать вам!
