BSkyB的高级UI开发人员Harry Roberts表示，开发人员应使用shame.css概念在项目中隔离任何快速修复的“ hack” CSS。
罗伯茨（Roberts）在博客文章中解释说，这可能会阻止开发人员看到遍及CSS的骇客，因此默认情况下认为这样的事情是可以接受的。
此外，该文章还指出，如果正确记录了这种方法，并附带了迭代方法，则可以在使用黑客（无论出于何种原因）的项目中更快地向更清洁的CSS过渡。
.net向Roberts（HB）讲述了如何入侵CSS以及shame.css如果正确使用将带来的潜在优势。
.net：您是否认为行业中的某些人倾向于（希望）短期黑客才能使网站正常运行，这是不现实的？
人力资源： 重要时刻。如果您在每年赚取数百万英镑的网站或产品上工作，则任何bug，破损或怪癖都需要尽快修复。您的产品负责人不在乎您的CSS是否完美-他们关心网站是否正常运行以及是否可以赚取收益。好的代码 是 重要的是，黑客远非理想之选，但认为您始终可以防止黑客入侵，并且短期/快速修复都是天真的。
.net：所以您会说它们只是企业中必不可少的邪恶？
人力资源： 当客户喘不过气来–或实时站点上的某个功能损坏–您需要确保让合适的涉众满意。如果您花一个小时写出可以在两分钟之内表面修复的完美解决方案，那么我想说的是让错误的人感到高兴-即您自己！
在我自己的工作中，我发现对hack的“需求”与项目规模成正比地增加，但是这样做的好处是，您以后可能还会有更多的项目时间专门用于解决这些hack。
.net：shame.css出现在哪儿。有了这个概念，您特别认为CSS hack是什么？
人力资源： 如果有更多的时间，本可以做得更好的事情。很难脱离上下文考虑示例，但是我认为您通常会知道什么时候会被黑客入侵。写了一些令您感到羞愧的解释给同事？那可能是黑客！
因此，shame.css是关于制作一些本可以做得更好的事情的文件，并且在有时间重新访问它们时可以做得更好。确实，这是一个自我编写的待办事项清单，您可以一边思考，一边有更多的时间来整理文件。
.net：在您的文章中，您提到了记录黑客问题，但是是否存在争论，开发人员通常应该更多地记录CSS，而不仅仅是针对黑客问题？
人力资源： 是的！如果所有开发人员都需要做一件事，那就是写评论。您应该注释仅从代码中无法立即看出的所有内容。将您的代码记录下来，这样，如果您在回家的路上遇到公交车撞到的情况，您的同事可以在第二天接班。
.net：关于整合shame.css，您有何建议？
人力资源： 如果使用预处理器， @进口 这 丢人的。[scss | less | etc] 最好在文件末尾进行归档。 （这总是会导致特定性和源顺序问题，因此您的里程可能会有所不同。）
如果您没有使用预处理程序，但是构建过程不错，那么在部署之前，应将所有CSS串联并缩小，因此，再次，shame.css可以在此结束。
如果您不使用预处理器 和 您没有构建过程，那么一个，您可能应该修复该问题，第二，在样式表末尾的“ hacks”部分可能是您最好的选择。 Shame.css并非供公众查看，因此切勿在标记中使用链接元素调用单独的样式表。您只应提供一个串联并缩小的样式表。
.net：如果shame.css作为一个概念真正兴起，您如何看待它会总体上改变设计流程和网站？
人力资源： Shame.css仅与实现它的开发人员一样有用。很好地隔离和记录黑客，但如果您从未修复或重新访问它们，则与以前一样。
对我而言，shame.css表示发展方向发生了更广泛的变化。它不必局限于CSS。这个概念仅仅是“实现，记录并指出您的骇客”。您可以将这种思想应用于所有事物。
shame.css涉及的真正工作是让您的直属团队（开发人员）加入其中，然后使业务/ PM / scrum master / BA /产品所有者（等等）意识到产品有时包含的内容较少的事实。 -理想代码，但该代码存在以满足业务需求。
告诉他们您正在隔离和记录黑客，并分配了一些开发时间来整理工作。如果可以量化代码库，则整理其业务案例会更容易。只是告诉您的项目经理，“在继续使用Feature X之前，我需要整理一些东西”，这并不总是可以解决的！列出您的PM清单，并尝试获得半天的冲刺时间来清理。
shame.css背后的想法仅仅是使您的黑客更加透明，可量化和隔离。由您决定如何处理这些信息！
