CSS 디자인 패턴에 대해 이야기하기

디자인 패턴이란 무엇인가요?

엔지니어가 다른 사람에게 자랑하고 우수해 보이려고 디자인 패턴을 사용한다고 조롱하는 사람들도 있었습니다. 언제 사용할 수 있나요?

먼저 좀 더 공식적인 설명을 살펴보겠습니다. “디자인 패턴은 반복적으로 사용되며 대부분의 사람들에게 알려져 있으며, 디자인 패턴을 사용하는 목적을 요약한 분류된 코드 디자인 경험의 집합입니다. 코드를 재사용하고, 다른 사람이 더 쉽게 이해할 수 있도록 하며, 코드 신뢰성을 보장합니다. 디자인 패턴이 우리 자신과 다른 사람 모두에게 이익이 되며, 시스템 디자인 패턴이 코드 준비를 진정한 엔지니어링으로 만든다는 것은 의심의 여지가 없습니다. 소프트웨어 공학의 초석은 건물의 구조와 같습니다. "

오늘은 CSS 디자인 패턴에 대해 이야기하겠습니다.

디자인 패턴, 이 용어는 우리에게 공통적으로 사용되는 용어입니다. 거의 모든 프로그래밍 언어에는 여러 세트가 있지만 깊이 있게 연구하는 사람은 많지 않습니다.

1. 거기에 강조할 필요는 없을 것 같습니다. 문제가 있으면 변경하거나 팀 규범을 따르세요.

2. 일부 기존 모델을 사용하지 않아도 됩니다. 3. 많은 분들이 접하고 있는 사업의 규모는 아직 기획과 정리가 필요한 수준은 아닙니다. 레이아웃 작성과 특수효과 작성, 호환성만 챙기면 한 잔 할 정도입니다. 일부 방법론적 문제에 대해 생각할 의식이 없습니다.

물론 저는 세 가지를 모두 경험했고 여러분도 경험했을 거라 믿습니다~

우리는 모두 성장해서 천천히 더 크고, 더 복잡한 프로젝트를 해나갈 것입니다. 이번에는 전체 프로세스에 걸쳐 위에서 아래로 몇 가지 문제에 대해 생각해야 합니다. 백엔드에 대해서는 이야기하지 않고 스타일 공식, 톤, 모듈, 레이아웃 방법, 상호 작용 방법, 로직 등과 같은 프런트 엔드에 대해서만 이야기하겠습니다. 팀워크를 추가하고 계획이 없으면 그렇지 않습니다. 문제가 있는 코드는 모듈 이름 지정, 클래스 이름 지정, 파일 구성, 공유 모듈 추출, 코드 재사용, 가독성, 확장성 및 유지 관리 가능성과 같은 다양한 문제를 노출시킵니다. 단순한 작은 조치처럼 보일 수도 있지만, 앞으로 더 많은 비용을 지불해야 하거나 전체 프로젝트를 재구성해야 하는 문제를 피하기 위해 더 많은 것을 살펴보아야 한다는 장점이 있다고 말할 수 있습니다. 현재와 ​​혜택은 미래에 있을 것입니다~

CSS는 설계되기 때문에 몇 가지 문제나 결함이 있을 것입니다. 그중 가장 분명한 것 중 하나는 CSS의 모든 규칙이 전역 선언이라는 것입니다. 이는 당신이 원하는지 여부에 관계없이 그것이 소개된 모든 관련 페이지에 영향을 미칩니다. 독립적이고 구성 가능한 모듈은 유지 관리 가능한 시스템의 핵심입니다. 다음으로 CSS를 보다 과학적인 방식으로 작성하는 방법을 여러 수준에서 논의하겠습니다.

필요에서 시작하기

포인트

처음 글쓰기를 배울 때 우리는 어떤 문장이 좋은지, 나쁜지, 문장의 구조가 좋은지 등을 생각하지 않습니다. 기사는 적절합니다. 왜냐하면 우리는 그것을 인식하지 못하기 때문입니다. 코드를 작성할 때도 마찬가지입니다. 처음에는 규칙만 정의하면 됩니다. 올바른 속성과 올바른 구문을 사용할 수 있으면 페이지를 구현할 수 있습니다. 천천히, 페이지에도 구조가 있다는 것을 알게 될 것입니다. 페이지 구조에 따라 코드를 구성하면 더 좋을까요? 예를 들어 헤더, 내비게이션, 사이드바, 배너 영역, 메인 콘텐츠 영역, 하단 등으로 구분됩니다.

그러고보니 우리 코드가 많이 보이더군요. 이전보다 더 좋아졌고, 정리가 명확해지고 유지 관리성이 크게 향상되었습니다. 그러나 아직은 충분하지 않은 것 같습니다. 매우 작지만 재사용성이 높은 항목도 모듈에 배치하기에는 적합하지 않습니다. 테두리, 배경, 아이콘, 글꼴, 여백, 레이아웃 방법 등과 같은 필요한 모든 위치에서 한 번 정의하면 여러 번 반복될 것입니다. 이는 분명히 모범 사례에서 벗어나 코드 중복 및 유지 관리 문제를 야기합니다. 그러므로 우리는 그것을 "해체"해야 합니다. 해체된 후에는 어떻게 되나요? 사용하고 싶은 곳에 직접 추가할 수 있고, 변경이 필요할 때 균일하게 변경할 수 있습니다.

배열

"분할"과 "분할" 후에 우리의 코드 구조는 매우 명확해졌습니다. 각 콘텐츠 모듈, 기능 모듈, UI 모듈은 모두 호출을 기다리고 있습니다. 왼쪽? ? 예, 질서 있는 조직은 여전히 ​​필요합니다. 분류가 명확한 후에도 여전히 질서 있는 방식으로 배열되어야 합니다. 우리가 그것을 다른 차원에서 고려한다면, 우리는 항상 우수성을 위해 노력할 수 있습니다. 예를 들어, 다음과 같은 것을 볼 수 있습니다:

@import "mod_reset.css";
@import "ico_sprite.css";
@import "mod_btns.css";
@import "header.css";
@import "mod_tab.css";
@import "footer.css";

우리는 코드를 볼 수 있도록 다양한 부분을 특정 순서로 배치합니다. 더 체계적이고 쉬워 보입니다. 동시에 상속이나 계단식 적용 범위에 도움이 됩니다. 이 단계가 불필요한 것처럼 보일 수도 있지만 실제로는 중복 코드를 줄이고 문제 위치를 빠르게 찾을 수 있는 상대적으로 높은 전체 계획 기능이 필요합니다.

또한 코드 범위를 구별하는 데 도움이 되는 다음과 같은 다른 방법도 사용할 수 있습니다.

　1. 파일 앞부분에 간략한 디렉터리를 생성하세요

　2. 블록 댓글을 사용하세요

주석에는 코드의 목적, 상태 전환, 조정 이유, 상호 작용 논리 등을 최대한 자세히 작성해야 합니다. 이렇게 하면 자신의 유지 관리가 용이할 뿐만 아니라 다른 사람이 인계하고 유지 관리하는 데도 도움이 됩니다. 당신의 코드.

결론부터 시작

요구 사항의 일부 공통된 부분 외에도 주의가 필요하지만 공식적으로 정의되지 않은 다른 사항이 있습니다. 예를 들면 다음과 같습니다.

레벨을 너무 깊게 중첩하지 마세요

브라우저 렌더링 원리에 대해 조금 아는 사람이라면 CSS 규칙을 파싱할 때 레이어별로 오른쪽에서 왼쪽으로 순회한다는 것을 알고 있습니다. 너무 많으면 필연적으로 렌더링 시간이 늘어나고 렌더링 속도에 영향을 미칩니다. 또한 선택기 수준이 너무 많으면 HTML 구조가 충분히 간결하지 않다는 것을 간접적으로 반영합니다.

그럼 몇 겹이 적당할까요? 일반적인 권장 사항은 4층을 초과하지 않는 것인데, 다시 4층을 초과하면 어떻게 될까요? 엄청난 양을 쓰거나 프로젝트가 극도로 복잡하지 않는 한 눈에 띄는 영향은 없을 것입니다. 실제로 우리의 일상적인 요구 사항을 보면 4개 레이어만으로도 대부분의 문제를 해결할 수 있습니다. 그래서 그것은 합리적입니다.

요소 선택기 사용을 피하세요

두 가지 이유:

이전 단락에서 언급한 내용과 관련된 첫 번째 요점은 HTML에서 일반적으로 사용되는 요소가 많다는 것입니다. p, p, 스팬, a, ul 등과 같은 고화질 요소. 다중 레벨 선택기의 가장 안쪽 레이어에 있는 요소 선택기를 사용하는 경우 검색을 시작할 때 브라우저는 HTML의 모든 요소를 ​​순회합니다. 물론 이는 필요하지 않습니다.

두 번째 요점은 우리의 요구 사항과 코드 구조에 잠재적인 변화가 있다는 것입니다. 오늘 페이지를 작성하면 내일은 버튼, 문장 등을 추가해야 할 수도 있습니다. 우리가 작성한 구조는 언제든지 다른 구조에서 재사용될 수 있습니다. 따라서 새로 추가된 것인지, 다른 구조에 추가된 재사용된 것인지를 결정하기 위해 요소 선택기를 사용하는 경우 스타일 충돌이 발생할 가능성이 매우 높습니다. 클래스를 수정하거나 재정의하세요.

그러므로 위의 사항을 고려하여 특정 코드 모듈에서는 요소 선택기를 사용하지 않는 것이 좋습니다. 요소 선택기를 사용하는 전제는 문제가 발생하지 않는다는 것입니다. 내가 사용한 범위는 "특정 코드 모듈"이므로 재설정과 같은 일반적인 규칙을 정의하는 데 사용되는 스타일이 허용되고 권장됩니다. 다른 곳에 있을 수도 있으며, 이를 위해서는 우리 자신의 고려가 필요합니다.

그룹 선택기 사용을 피하세요

그룹 선택기의 문제점은 무엇인가요? 그냥 사진으로 가세요.

다음은 예시일 뿐입니다. 다음은 서로 다른 위치에서 동일한 스타일을 정의하는 데 사용되는 세 가지 세트입니다. 사용해야 하는 네 번째 장소가 있으면 다른 선택기 세트를 추가해야 합니다. 10개의 다른 장소가 있으면 10을 쓰나요? 이는 유지관리에 있어서 매우 고통스러운 일입니다. 어떻게 이렇게 복잡하고 불필요한 노동이 필요합니까? 따라서 Wall Crack에서는 이러한 접근 방식을 권장하지 않습니다. 그러면 필요할 때마다 통일된 스타일을 정의할 수 있습니다. 배치하면 재사용 및 유지 관리가 더 편리해집니다.

물론 처음 썼을 때는 이렇게나 더 많을지 몰랐고, 굳이 추출할 필요가 있을지도 모르겠다고 말씀하실 수도 있겠네요. 경험을 바탕으로 판단해야 하며, 프로젝트 발전 과정에서 적시에 코드를 구성하고 재구성해야 합니다.

파일 소개 개수와 순서

웹 페이지를 처음 접하는 친구들에게는 이 두 가지 사항도 별로 영향을 미치지 않는 것 같아서 간과하기 쉽습니다. 요청이 이미 로드되어 있으므로 사람들을 미치게 만드는 것이 쉽지 않습니다. 그러나 궁극적인 사용자 경험 추구로 인해 파일 요청 수가 가능한 한 적고, 콘텐츠가 우선 순위에 따라 표시되고, 파일이 순서대로 로드되기를 바랍니다. 이렇게 하면 파일 크기를 줄이는 것이 정말 어려울 때 사용자는 더 중요하고 일반적으로 표시되는 콘텐츠를 먼저 볼 수 있습니다.

위의 내용은 몇 가지 예에 불과합니다. 보다 실질적인 결론을 내리려면 관련 블로그 게시물이나 책을 더 읽어보고 선배들의 경험을 찾아보세요.

모순에서 시작

보편성과 의미

명명 규칙은 특정 스타일이 속한 카테고리와 페이지 전체 범위 내에서의 역할을 즉시 이해하는 데 도움이 됩니다. 경우에 따라 명명 규칙을 사용하면 스타일이 속한 파일을 더 쉽게 찾을 수 있습니다.

. 대규모 프로젝트에서는 여러 파일에 걸쳐 분리된 스타일이 있을 가능성이 더 높습니다. 이 경우 명명 규칙을 사용하면 스타일이 속한 파일을 더 쉽게 찾을 수 있습니다.

모듈 제목, 버튼, 프롬프트 텍스트, 아이콘 등과 같이 재사용을 위해 보편적으로 정의해야 하는 경우가 많습니다. 처음에는 시각적 초안의 내용을 보는 데 익숙합니다. "news"이면 "news"를 정의하고, "about"이면 "about"을 정의하고, 빨간색 버튼이면 "red-btn"을 정의합니다. 문제 다음과 같은 뉴스 목록이 비슷한 스타일과 구조로 되어 있지만 뉴스가 아닌 경우 어떻게 해야 합니까? "뉴스"를 계속 사용하는 것은 명백히 부적절합니다. 이는 우리의 관심을 내용으로 제한할 수 없으며 내용과 구조를 분리해야 함을 알려줍니다.

더 이상 '뉴스'를 사용할 수 없는데 무엇을 사용해야 할까요? 알파벳? 123? 이렇게 하면 충돌도 없고 모든 것이 잘 될 것입니다~ 사실 이것은 다른 모듈과의 충돌을 상당 부분 방지하지만 자체 가독성이 크게 떨어지며, 다른 모듈이 무엇인지 잊어버릴 수도 있습니다. 시간이 좀 지나면 팀워크에 매우 해롭습니다. 어떤 네이밍 방법을 사용해야 하는지는 전체 프로젝트에 맞춰 계획해야 합니다. 어떤 특성이 서로 다른 구조를 구별하는 데 적합하며, 이름과 이름 사이의 연결을 더 쉽게 만들 수도 있습니다. 카테고리, 기능, 페이지 등과 같은 구조입니다.

팀과 개인

팀에서는 모두가 서로 다른 경험, 코딩 수준 및 습관을 가지고 있으므로 각 사람은 밑줄을 사용하고 나는 밑줄을 사용합니다. 나는 영어로 전체 철자를 사용하고, 당신은 약어 등을 사용합니다. 옳고 그름은 없지만 팀 구성원 간의 협업에 상당한 장애물을 초래합니다. 다른 사람들은 구성 및 정의 방법에 적응하고 이해하는 데 시간을 소비해야 하며 이로 인해 비용이 눈에 띄게 증가합니다.

따라서 일부 작성 규정 외에도 "팀 사양"이 존재해야 합니다. 사양은 우리의 코드를 더욱 통일되고 명확하며 읽기 쉽고 인식하기 쉽게 만듭니다. 또한 팀의 모든 사람에게 도움이 되는 몇 가지 모범 사례와 재사용된 모듈을 추출할 수도 있습니다.

물론, 사람에게 가장 어려운 일은 기존의 습관을 고치는 일입니다. 이는 팀에 입사한 후의 '변신'의 고통이기도 합니다. 더 나은 코딩 방법과 더 나은 실천 방법을 배우고, 프로젝트나 팀 전체의 관점에서 무언가의 가치와 중요성을 고려할 것입니다.

CSS와 전처리기

이전에 CSS 전처리기에 대해 기사에서 자세히 설명한 적이 있는데, 학습 비용이 들고 적용할 필요가 없다고 느껴서 거부하곤 했습니다. 그러나 일단 사용 방법을 배우기로 결정하면 전처리기가 자신을 소개할 때 구문이 CSS와 완벽하게 호환된다는 점을 구체적으로 강조합니다. SASS 파일이라면 CSS 코드를 직접 작성하는데 문제가 없습니다. 또한, 반복적으로 선택기를 작성하는 대신 중첩을 사용하여 통합 변수를 정의하고, 공통 코드 블록을 쉽게 추출하여 재사용할 수 있는 등 많은 편의를 제공할 수 있습니다.

따라서 CSS를 잘 정리하고 작성하면 전처리기가 다시 날개를 달아 우리가 더욱 유연하고 효율적으로 코딩할 수 있게 해줄 것입니다.

기존 모델을 시작으로

널리 보급된 모델을 간단히 살펴보겠습니다. (ps: 순서는 순위, 품질과는 관계가 없습니다)

1. OOCSS - Object Oriented CSS

컴퓨터를 접해본 사람이라면 다 아실, OOP - Object Oriented 프로그래밍 , 당신이 OOCSS를 처음 접하면 "객체지향 CSS"인가? 실제 프로그래밍 언어가 아닙니다. 어떻게 객체 지향적입니까?

OOCSS는 2009년에 처음 언급되었습니다. 두 가지 주요 원칙은 다음과 같습니다.

스킨에서 구조를 분리하고 콘텐츠에서 컨테이너를 분리합니다.

직역하면 구조와 스킨은 다음과 같습니다. 분리되어 용기와 내용물이 분리됩니다.

즉, 구조와 스킨, 콘텐츠가 강하게 결합되어서는 안되고, 서로 독립적이어야 하며, 재사용과 결합이 더 용이하도록 하는 것이 목표이며, 선택하여 사용할 수 있습니다. , 인용 등을 선택합니다.

2. SMACSS - Scalable and Modular Architecture for CSS

실제로 OOCSS는 배울 만한 아이디어를 제공하지만, 코드 구성 측면에서 구체적인 구현 방법을 제공하지 않습니다. 이러한 관점에서 SMACSS는 한 단계 더 나아갑니다.

핵심은

1. 베이스(Basic)

기본 스타일은 먼저 정의해야 하며 특정 유형의 요소에만 적용되는 일반적인 고정 스타일입니다.

2. 레이아웃

레이아웃 스타일은 목록, 메인 콘텐츠, 사이드바 위치, 너비와 높이, 레이아웃 방법 등 페이지의 전반적인 구조와 관련이 있습니다.

3. 모듈

모듈 스타일은 페이지를 해체하는 과정에서 추출하고 분류한 모듈입니다. 이러한 스타일은 별도로 작성됩니다.

4. 상태

페이지의 일부 요소는 사용 가능, 사용할 수 없음, 사용됨, 만료, 경고 등과 같은 다양한 상태에 응답해야 합니다. 이러한 스타일은 함께 구성할 수 있습니다.

5. 테마(theme)

테마는 전체 레이아웃의 색상과 스타일을 의미합니다. 일반적으로 웹사이트에서 가장 인상 깊었던 것은 바로 QQ입니다. 다른 공간 활용이 많지 않아 일반적으로 사용하지 않지만, 필요할 때 활용 방법을 알아두는 것이 좋습니다.

위의 5가지 분류 전략을 사용하면 코드를 구성할 때 아이디어가 매우 명확해지고 배열이 매우 질서정연해집니다. 이름 지정의 어려움과 혼란을 해결할 수 있다는 것입니다. 이 문제의 주된 이유는 요소의 소속과 특성을 정의하는 데 어떤 표준을 사용해야 할지 모르기 때문입니다. 그리고 충돌할 가능성도 적습니다.

3. 메타 CSS

원자 클래스는 다음과 같이 "의미론적" 클래스라고도 부를 수 있습니다.

특징은 무엇입니까? ? 스타일은 구조나 내용과는 아무런 관련이 없습니다. 이러한 규칙 세트를 미리 정의하여 필요한 곳에 추가할 수 있습니다. 모든 사람이 이 작성 방법을 처음 보면 다음과 같이 생각할 것입니다. 이것? ! 네, 항상 어떤 사람들이 있고, 어떤 새로운 아이디어와 방법이 나올 것입니다. 물론 이것은 그것이 얼마나 좋다고 칭찬하는 것이 아니라, 이 현상과 과정 자체가 좋다고 말하는 것입니다. "이렇게 쓰는 것과 직접 인라인하는 것 사이에 차이가 있나요?", "스타일을 조정하려면 HTML을 변경해야 하는데, 그러면 유지 관리가 더 번거롭고 원본에 어긋납니다." 등의 불만을 자주 제기합니다. 스타일과 구조를 분리하려는 의도" 등이 있습니다. 사실 저는 개인적으로 위의 작성 방법에 동의하지 않습니다. 이것을 추출하고 싶다면 또 추출할 수 없는 것은 무엇입니까? 또한 이러한 속성은 프로젝트, 페이지 및 모듈 간에 흔하지 않습니다. 이를 추출하는 것은 약간 게으르고 노력을 절약하지만 더 많은 상황을 처리하려면 중복 코드를 작성하는 것이 이득이 아닙니다.

비록 단점이 있지만 저는 개인적으로 float(float), 텍스트 레이아웃(text-align), Flexbox 레이아웃 등 다른 것들의 분리를 지지합니다. 또한 자주 사용되며 재사용이 쉽고 변경 사항이 거의 없습니다. 또한 버튼 유형, 텍스트 색상 유형 등과 같은 다른 공개 세부 카테고리도 추출할 수 있습니다. CSS 자체와는 관련이 없지만 프로젝트와 관련이 있습니다. 이는 아이디어를 직접 사용하기보다는 차용하는 것입니다.

4. BEM

엄밀히 말하면 BEM은 살과 피의 집합이 아니며 CSS 수준의 계획에만 국한되지도 않습니다. 코드 작성에 대한 아이디어는 간단해 보이지만 프런트엔드 세계에 큰 영향을 미칩니다.

핵심은 다음과 같습니다.

Block, Element, Modifier

페이지 각 부분의 레벨 속성을 정의하는 데 도움이 되며, 어떤 의미에서는 또한 일종의 "철거". 명명 규칙은 다음과 같습니다.

그 외모는 많은 사람들에게 영감을 주었지만 여전히 일부 사람들은 까다로운 태도를 가지고 있습니다. 예를 들면 다음과 같습니다.

1. The 스타일이 획일적이지 않고, 코드가 깔끔하고 아름답지 않은 것 같습니다

2. 클래스 이름이 너무 길어질 수 있습니다

앞서 말씀드린 대로 직접 사용하지 않으셔도 됩니다. , 그러나 이점을 분명히 해야 합니다. 클래스 이름을 통해 모듈에 속한 코드와 모듈에서의 역할을 알 수 있다는 것입니다. 그런 다음 그것으로부터 배우십시오.

물론 BEM은 OOCSS 작성자를 비롯해 많은 분들의 노력이 모여 많은 칭찬을 받아왔습니다. 따라서 그렇게 간단하지는 않습니다. 또한 js로 작성하는 방법, 파일을 더 잘 구성하는 방법, 프로젝트를 빌드하는 방법 등을 알려줍니다. 자세한 내용은 공식 홈페이지에서 확인할 수 있다.

현실을 바탕으로 결과를 결정하는 사람은 바로 당신입니다

디자인 패턴은 어떻게 활용하나요?

이미 성숙한 디자인 패턴이 있더라도 실제로는 그 중 어느 것도 프로젝트와 완전히 일치하지 않는다고 느끼거나 이를 사용하기 위해 조정해야 하므로 비용이 매우 많이 듭니다. 실제로 패턴을 적용할 필요는 없습니다. 패턴을 적용하려면 패턴 뒤에 있는 원리를 이해하고 패턴이 어떤 문제를 어떻게 해결하는지 파악한 다음 패턴에서 배우고 패턴의 방법을 사용하여 문제를 해결해야 합니다. 좋아요, 그러니까 쓸까 말까 고민할 필요도 없고, 어느 것을 골라야 할지 고민할 필요도 없습니다. 단지 어느 것이 좋고 어느 것이 나쁘다고 말하는 것이 아닙니다. 우리가 그것을 사용할 수 있는 곳. 바다는 모든 강을 품고 수백 가지 학파의 힘을 모아준다.

제가 개인적으로 항상 주장해 온 또 다른 관점은 프런트 엔드 개발의 3대 요소인 html, css, js가 단독으로 얼마나 좋은지, 얼마나 좋은지에 대해 말할 수 없고 말할 수도 없다는 것입니다. 한 번만 사용되는 코드나 모듈이 있고, 하나의 언어만 있는 것이 아닙니다. 트로이카는 모두 함께 협력하며, 그 안에는 재사용, 확장, 팀워크 등 여러 가지 요소가 있습니다. 그러므로 우리는 '내가 지금 이 일을 하고 있는데, 이것이 유일한 일이고, 고쳐졌고, 문제가 없다'는 생각을 가질 수 없습니다. 실제로 많은 문제가 잠재적으로 존재하므로 개발 관점에서 보아야 합니다. 프로젝트 파일 간, 프로젝트 간, 팀 구성원 간, 업무 분담 위치에 관계없이 협력 전후의 영향과 불편함을 고려해야 합니다.

모범 사례는 무엇인가요? '연습'이 있어야만 '최고'가 있을 수 있다. 실제 상황과 동떨어지지 않고 최고를 말하는 것은 허공의 성일 뿐이다. 따라서 최고의 모델은 고전적인 모델이 아니라 프로젝트 중에 지속적으로 조정되는 모델입니다. 그러므로 더 이상 불분명해 보이는 디자인 패턴을 두려워할 필요도 없고, 디자인 패턴을 이해하지 못한다고 우울해할 필요도 없습니다. 패턴~

CSS 디자인 패턴에 대한 자세한 내용은 PHP 중국어 홈페이지 관련 글을 주목해주세요!