CSS의 품질과 복잡성을 모니터링하는 스택을 찾아

많은 개발자들은 CSS 코드 기반을 유지하는 방법에 대해 글을 쓰지만 코드 기반의 품질을 측정하는 방법에 대해 글을 쓰는 사람은 거의 없습니다. 물론 Stylelint 및 CSSLINT와 같은 우수한 코드 점검 도구가 있지만 마이크로 레벨에서만 오류를 방지 할 수 있습니다. 잘못된 색상 표기법을 사용하고, autopRefixer가 이미 사용될 때 공급 업체 접두사를 추가하고, 선택기를 일관되지 않은 방식으로 쓰십시오 ... 등.

우리는 항상 OOCSS, BEM, SMACSS, ITCSS, 실용적인 우선 등 CSS가 작성되는 방식을 개선 할 수있는 방법을 찾고 있습니다. 그러나 다른 개발 커뮤니티는 간단한 코드 점검 도구에서 Sonarqube 및 PHP Mess Detector와 같은 도구로 진화 한 것으로 보이지만 CSS 커뮤니티는 여전히 얕은 보풀 규칙보다 심층적 인 점검 도구가 부족합니다. 이를 위해 CSS 품질을 확인하고 시행하기위한 일련의 도구 인 Project Wallace를 만들었습니다.

Project Wallace 란 무엇입니까?

Project Wallace의 핵심에는 명령 줄 인터페이스, 코드 검사관, 분석기 및 리포터를 포함한 일련의 도구가 있습니다.

다음은 이러한 도구에 대한 간단한 개요입니다.

명령 줄 인터페이스

이를 통해 명령 줄에서 CSS 분석을 실행하고 제공하는 CSS에 대한 통계를 얻을 수 있습니다.

Constyble Code Checker

이것은 CSS를 위해 특별히 설계된 코드 검사기입니다. Wallace에서 생성 된 분석 결과를 기반으로, 초과하지 말아야 할 임계 값을 설정할 수 있습니다. 예를 들어, 단일 CSS 규칙에는 10 개 이상의 선택기가 포함되어 있지 않거나 평균 선택기 복잡성이 3보다 높지 않아야합니다.

분석기

이름이 제안한대로 Extract-CSS 웹 페이지에서 모든 CSS를 추출하여 분석을 위해 ProjectWallace.com으로 보낼 수 있습니다.

보고자

추출 CSS의 모든 분석 결과는 ProjectWallace.com으로 전송되며 대시 보드에는 모든 데이터에 대한 보고서가 포함되어 있습니다. CSS 통계와 비슷하지만 더 많은 메트릭을 추적하고 시간이 지남에 따라 결과를 저장하고 대시 보드에 표시합니다. 또한 두 시점과 다른 많은 기능의 차이를 보여줍니다.

CSS 복잡성을 분석하십시오

CSS 복잡성에 관한 기사는 많지 않지만 Harry Roberts (CSSwizardry)는 저에게 감동을주었습니다. 요점은 각 CSS 선택기가 기본적으로 IF 문의 무리이며 컴퓨터 과학 과정을 수강 할 때 수동으로 계산 해야하는 방법의 루프 복잡성을 상기시킵니다. Harry의 기사는 CSS 선택기의 복잡성을 계산하기 위해 모듈을 작성할 수 있기 때문에 나에게 큰 의미가 있습니다. 물론 복잡성 측면에서 완전히 다른 질문이기 때문에 특이성과 혼동되지 않아야합니다.

기본적으로 CSS의 복잡성은 여러 형태로 올 수 있지만 코드베이스를 검토 할 때 가장주의를 기울이는 몇 가지 사항이 있습니다.

CSS 선택기 루프 복잡성

선택기의 각 부분은 브라우저가 다른 IF 문을 실행해야 함을 의미합니다. 더 긴 선택기는 짧은 선택기보다 더 복잡합니다. 디버그하기가 더 어렵고 브라우저 구문 분석은 느리고 덮기가 어렵습니다.

 <code>.my-selector {} /* 1 个标识符*/ .my #super [complex^="selector"] > with ~ many :identifiers {} /* 6 个标识符*/</code>

규칙 세트 당 선언 수 (응집력)

많은 선언을 포함하는 규칙 세트는 소수의 선언을 포함하는 규칙 세트보다 더 복잡합니다. 테일 윈드 및 타키 온과 같은 기능적 CSS 프레임 워크의 인기는 CSS 자체의 상대적 "단순성"에 기인 할 수 있습니다.

 <code>/* 1 条规则，1 个声明=> 内聚性= 1 */ .text-center { text-align: center; } /* 1 条规则，8 个声明=> 内聚性= (1 / 8) = 0.125 */ .button { background-color: blue; color: white; padding: 1em; border: 1px solid; display: inline-block; font-size: normal; font-weight: bold; text-decoration: none; }</code>

소스 코드 라인 수

코드가 많을수록 더 복잡합니다. 각 코드 줄은 유지되므로 보고서에 포함됩니다.

규칙 당 평균 선택기 수

규칙에는 일반적으로 1 개의 선택기가 포함되지만 때로는 더 많은 것입니다. 이로 인해 CSS의 일부를 삭제하기가 어렵 기 때문에 더 복잡합니다.

이러한 모든 메트릭은 Project Wallace가 도구 세트에서 사용하는 CSS 복잡성 코드 검사기 인 Constyble을 사용하여 코드 확인할 수 있습니다. 메트릭의 기준선을 정의한 후 Constyble을 설치하고 구성 파일을 설정하십시오. 다음은 Constyble ReadMe에서 직접 추출한 구성 파일의 예입니다.

 <code>{ // 不要超过4095 个选择器，否则IE9 将删除任何后续规则"selectors.total": 4095, // 我们不需要ID 选择器"selectors.id.total": 0, // 如果出现除这些颜色之外的任何其他颜色，则报告错误！ "values.colors.unique": ["#fff", "#000"] }</code>

가장 중요한 부분은 Constyble이 최종 CSS에서 실행되므로 SASS, Less, PostCSS 또는 다른 전처리 업체에서 보유한 모든 전처리 작업 후에 만 ​​작업을 수행한다는 것입니다. 이러한 방식으로 우리는 총 선택기 수 또는 평균 선택기 복잡성을 현명하게 점검 할 수 있습니다. 코드 검사관과 마찬가지로 빌드 단계의 일부로 사용할 수 있으며 문제가 발생하면 빌드가 실패합니다.

프로젝트 월리스 사용의 수확

Project Wallace를 잠시 동안 사용한 후 복잡성을 추적하는 데 좋습니다. 이 목적으로 주로 사용되지만 CSS의 코드 검사관이 사전 처리 된 코드를 확인하기 때문에 찾을 수없는 미묘한 오류를 찾는 좋은 방법이기도합니다. 여기에 내가 찾은 몇 가지 흥미로운 것들이 있습니다.

• 스프린트 중에 사이트에서 일관되지 않은 색상을 수정 해야하는 사용자 스토리 수를 계산하지 않았습니다. 몇 년 동안 프로젝트가 있었고 사람들은 회사에 들어오고 나갔습니다. 이것은 웹 사이트의 모든 브랜드 색상을 잘못 만드는 비밀입니다. 다행히도, 우리는 고객의 브랜드가 새로운 프로젝트에서 매우 정확하다는 것을 증명할 수 있었기 때문에 Constyble 및 Project Wallace를 구현했습니다. Constyble은 스타일 가이드에없는 색상을 추가하지 못하게합니다.
• 전 고용주가 일하는 프로젝트에 Project Wallace Webhooks를 설치했습니다. 프로젝트에 새 CSS를 추가 할 때마다 CSS를 ProjectWallace.com으로 보내며 프로젝트 대시 보드에 즉시 표시됩니다. 따라서 특정 선택기 또는 미디어 쿼리가 CSS에 추가 될 때 쉽게 찾을 수 있습니다.
• 올해 초 CSS- 트릭 재 설계는 복잡성과 파일 크기가 크게 떨어졌다. 재 설계는 훌륭하고 분석 할 수 있습니다. 그것은 당신에게 무대 뒤에서 상황을 면밀히 살펴보고 저자들이 어떻게 CS를 바꾸 었는지 알아낼 수있는 기회를 제공합니다. 사이트에서 작동하지 않는 섹션과 새로운 섹션이 적용되는 섹션을 알면 CSS가 얼마나 빨리 증가하고 있는지에 대한 아이디어가 제공 될 수 있습니다.
• 네덜란드에 본사를 둔 대규모 국제 회사는 한 번 CSS 파일에 4095 명 이상의 셀렉터를 보유하고 있습니다. 나는 그들이 신흥 시장을 적극적으로 개발하고 있으며 인터넷 익스플로러 8을 지원해야한다는 것을 알고 있습니다. IE9는 4095 명의 셀렉터 후 모든 CSS를 읽지 않으므로 대부분의 CSS는 구형 IE 브라우저에 적용되지 않습니다. 나는 그들에게 이메일을 보냈고 그들은 문제를 확인하고 즉시 CSS를 두 파일로 나누어 즉시 수정했습니다.
• Gitlab은 현재 70 개가 넘는 고유 한 글꼴 크기를 사용합니다. 나는 그들의 타이포그래피가 복잡하다고 확신하지만, 이것은 너무 야심 찬 것 같습니다. 어쩌면 그것은 타사 CSS 때문일 수도 있지만 판단하기는 어렵습니다.
• 다른 개발자의 프로젝트를 상속 할 때 CSS 분석 결과를 검토하여 프로젝트의 어려움을 이해합니다. 그들은 대량으로 그것을 사용하고 있습니까! 중요합니까? 평균 규칙 세트 크기를 이해하기 쉽습니까, 아니면 규칙 세트 당 20 개 이상의 선언을 추가합니까? 평균 선택기 길이는 얼마이며 다루기가 어렵습니까? .complex-selector-Override \ [class \] [class] ... [class]에 의지하지 않는 것이 좋을 것입니다.
• 확대 / 축소가 효과적인지 확인하는 영리한 트릭은 코드의 줄 번호 표시기가 1보다 크지 않은지 확인하는 것입니다. CSS 수축은 모든 CSS가 한 줄에 배치되므로 코드 줄 수가 1과 같아야합니다!
• 다른 프로젝트에서 항상 일어난 일은 축소 실패였습니다. 프로젝트 월리스의 차이가 #AAAA 대신 #AAAAA처럼 갑자기 많은 색상이 표시 될 때까지 모르겠습니다. 이것은 그 자체로 나쁘지는 않지만, 동시에 많은 색상으로 발생하여 무언가 잘못되었을 것입니다. 빠른 설문 조사에 따르면 수축에 실수를했습니다.
• StackoverFlow에는 흰색 색상을 작성하는 4 가지 독특한 방법이 있습니다. 이것은 반드시 나쁜 것은 아니지만 CSS 미니 화 프로그램이 설계 시스템에서 손상되거나 일치하지 않는다는 신호일 수 있습니다.
• Facebook.com은 CSS에 650 개가 넘는 고유 한 색상을 보유하고 있습니다. 깨진 설계 시스템도 가능성처럼 들리기 시작했습니다.
• 이전 고용주의 프로젝트는 입력 [type = checkbox] : checked .label input [type = radio] 레이블 : 초점 : After는 가장 복잡한 선택기입니다. 면밀한 검사 후,이 선택기는 다른 입력에 중첩 된 입력을 찾는 것으로 나타났습니다. 이것은 HTML에서 불가능하며, 우리는 CSS의 쉼표를 잊어 버렸을 것이라고 생각합니다. 코드 검사기는 이에 대해 경고하지 않습니다.
• CSS 전 처리기에 둥지를 짓는 것은 시원하지만 syntax.fm에서 찾은 것처럼 @Media (Max-Width : 670px) 및 (Max-Width : 670px)와 같은 잘못된 것들을 일으킬 수 있습니다 .

프로젝트 월리스의 경우 이것은 빙산의 일각 일뿐입니다. CSS 분석을 시작하면 배우고 발견해야 할 것이 더 많습니다. 자신의 통계를 보지 말고 다른 통계를 보지 마십시오.

나는 덜 숙련 된 개발자와 대화 주제로 내 Constyble 구성을 사용하여 복잡한 CSS 블록을 구축하지 못하는 이유를 설명했습니다. 특정 CSS 작성 방법을 피하거나 홍보 해야하는 이유를 다른 개발자와 논의하면 지식을 전달하는 데 도움이 될 수 있습니다. 또한 발을 땅에 두는 데 도움이됩니다. 단지 도움을 원하는 PHP 개발자에게 설명해야한다는 사실, 몇 년 동안 한 일은 내가하는 일을하는 이유를 다시 생각하게 만들었습니다.

저의 목표는 CSS에서 옳고 그른 것을 다른 사람에게 말하는 것이 아니라 도구를 만들어 귀하와 동료에게 적합한 기능을 확인할 수있는 것입니다. Project Wallace는 우리가 쓰는 CSS를 이해하는 데 도움이됩니다.

위 내용은 CSS의 품질과 복잡성을 모니터링하는 스택을 찾아의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!