BSkyB의 수석 UI 개발자 인 Harry Roberts에 따르면 개발자는 shame.css라는 개념을 사용하여 프로젝트에서 빠른 수정 '해킹'CSS를 격리해야합니다.
Roberts는 블로그 게시물에서 이것이 잠재적으로 개발자가 CSS 전체에 걸쳐 해킹을 보는 것을 막을 수 있으며 따라서 이러한 것들이 기본적으로 수용 가능하다고 생각한다고 설명했습니다.
또한이 기사는 이러한 접근 방식이 적절하게 문서화되고 반복 수단을 동반한다면 해킹이 사용 된 프로젝트에서 더 빠른 CSS로 진행할 수 있다고 언급했습니다.
.net은 Roberts (HB)에게 CSS 해킹과 shame.css가 올바르게 사용되면 가져올 수있는 잠재적 인 이점에 대해 이야기했습니다.
.net : 업계의 일부 사람들이 사이트를 작동시키기 위해 (희망적으로) 단기 해킹의 필요성에 대해 비현실적인 경향이 있다고 생각하십니까?
HR : 큰 시간. 연간 수백만 파운드를 벌어들이는 사이트 또는 제품에서 작업하는 경우 버그, 파손 또는 단점은 가능한 한 빨리 수정해야합니다. 귀하의 제품 소유자는 귀하의 CSS가 완벽한 지 신경 쓰지 않습니다. 그들은 사이트가 작동하고 그 수익을 올리는 데 관심이 있습니다. 좋은 코드 이다 중요하고 해킹은 이상적인 것과는 거리가 멀지 만, 항상 해킹과 단기 / 빠른 수정을 방지 할 수 있다고 생각하는 것은 순진한 일입니다.
.net : 그렇다면 그들이 사업에 필요한 악이라고 말씀 하셨나요?
HR : 클라이언트가 숨을 쉬고 있거나 라이브 사이트에서 기능이 손상 될 때 올바른 이해 관계자를 행복하게 유지해야합니다. 2 분 만에 피상적으로 고칠 수있는 문제에 대한 완벽한 수정을 작성하는 데 1 시간을 소비한다면 잘못된 사람, 즉 자신을 행복하게 유지하고 있다고 말할 수 있습니다!
내 자신의 작업에서 해킹에 대한 '필요'가 프로젝트 규모에 비례하여 상당히 증가한다는 것을 발견했지만 그에 대한 좋은 점은 나중에 이러한 해킹을 수정하는 데 더 많은 프로젝트 시간을 할애 할 가능성이 높다는 것입니다.
.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와 관련된 실제 작업은 직계 팀 (개발자)을 참여시킨 다음 비즈니스 / PM / 스크럼 마스터 / BA / 제품 소유자 (등)에게 제품에 때때로 적은 양이 포함된다는 사실을 알리는 것입니다. -이상적인 코드이지만이 코드는 비즈니스 요구 사항을 충족하기 위해 존재합니다.
해킹을 격리하고 문서화하고 있다고 말하고 정리 작업에 개발 시간을 할당하십시오. 수량화 할 수 있다면 코드 기반을 정리하기위한 비즈니스 사례를 만드는 것이 더 쉽습니다. 단순히 프로젝트 관리자에게 "기능 X로 이동하기 전에 정리해야 할 사항이 몇 가지 있습니다"라고 말하는 것만으로도 문제가 해결되지는 않습니다! PM에게 항목 목록을 가져 와서 청소하는 데 반나절의 스프린트 시간을 확보하십시오.
shame.css의이면에있는 아이디어는 단순히 해킹을 더 투명하고 정량화 가능하며 격리되게 만드는 것입니다. 그 정보로 무엇을하는지는 당신에게 달려 있습니다!
