跳到主要内容

开发人员说,使用shame.css来容纳CSS黑客攻击

开发人员应该使用一个名为shame.css的概念来模拟项目中任何快速修复的“hack”CSS,根据BSkyB高级UI开发人员Harry Roberts的说法

罗伯茨在博客文章中解释说,这可能会阻止开发人员看到整个CSS中出现的黑客攻击,从而认为这些东西在默认情况下是可以接受的。

此外,文章指出,如果适当记录并伴随迭代方法,这种方法可以在使用黑客的项目中(无论出于何种原因)更快地向更清洁的CSS发展。

.net与Roberts(HB)谈到了黑客攻击CSS以及shame.css在正确使用时可能带来的潜在优势。

.net:你认为这个行业的某些人有一种倾向,认为需要(希望)短期黑客来使网站运作是不现实的吗?
HR:重要时刻。如果您在每年赚取数百万英镑的网站或产品上工作,任何错误,破损或怪癖都需要尽快修复。您的产品所有者并不关心您的CSS是否完美 - 他们关心网站是否正常运行,并且关注该收入。好的代码重要的是,黑客远非理想,但认为你可以随时防止黑客攻击和短期/快速修复。

.net:所以你说他们只是生意中的必然恶魔?
HR:当一个客户在你的脖子上呼吸 - 或者一个功能在现场被打破 - 你需要确保你保持正确的利益相关者的快乐。如果你花一个小时写一个完美的修复程序,你可以在两分钟内表面修复,我会说你保持错误的人快乐 - 即你自己!

在我自己的工作中,我发现黑客的“需求”与项目的规模相当成比例地增加,但是好的方面是你以后可能会有更多的项目时间来修复这些黑客。

.net:shame.css的用武之地。有了这个概念,你认为什么是CSS hack?
HR:如果有更多时间,可以做得更好的事情。很难想出脱离背景的例子,但我想你会经常知道什么时候是黑客。写一些你会羞于向同事解释的东西?这可能是一个黑客!

因此,shame.css是关于制作一个你可以做得更好的事情的文件,并且当你有时间重新访问它们时你可以做得更好。这是一个自写的待办事项列表,实际上是一个黑客文件,当你有更多时间时,你会把它放在一边思考。

.net:在你的文章中,你提到记录黑客攻击,但是开发人员通常不应该更多地记录CSS,而不仅仅是针对黑客攻击?
HR:是!如果所有开发人员都应该做更多的事情,那就是写评论。你应该只从代码中评论任何不明显的东西。记录您的代码,这样,如果您在回家途中遇到公共汽车,您的同事可以在第二天接管。

.net:在整合shame.css方面,你有什么建议?
HR:如果使用预处理器,@进口。耻[SCSS |更少|等]最后归档,理想情况下。 (这可能总是导致特异性和源序问题,因此您的里程可能会有所不同。)

如果你没有使用预处理器,但是有一个不错的构建过程,所有的CSS应该在部署之前连接和缩小,所以,再次,shame.css可以坚持到最后。

如果您没有使用预处理器你没有构建过程,那么你可能应该修复它,而两个,样式表末尾的黑客部分可能是你最好的选择。 Shame.css不适合公众查看,因此永远不要在标记中使用链接元素调用单独的样式表。您应该只提供一个连接和缩小的样式表。

.net:如果shame.css作为一个概念真的起飞了,你认为它如何改变设计过程和网站?
HR:Shame.css仅与实现它的开发人员一样有用。这一切都很好,隔离和记录黑客,但如果你从来没有修复或重新访问它们,你就像以前一样在同一条船上。

对我来说,shame.css标志着更广泛的发展转变;它不需要限于CSS。这个概念仅仅是“实现,记录并指出你的黑客行为”。你可以将这种想法应用于一切。

与shame.css相关的真正工作是让你的直接团队(开发人员)加入,然后让业务/ PM / scrum主人/ BA /产品所有者(等等)意识到产品有时会包含更少的事实 - 理想的代码,但该代码的存在是为了满足业务需求。

告诉他们你正在分离和记录黑客并获得一些开发时间来分配整理。如果可以量化代码库,那么为整理代码库制作业务案例会更容易。简单地告诉你的项目经理,“在我进入功能X之前,我有一些东西需要整理”并不总是会削减它!把一些东西列到你的PM,并尝试用半天的冲刺时间来清理。

Shame.css背后的想法只是让你的黑客更透明,可量化和孤立。这取决于你对这些信息的处理方式!



翻译字数超限