나중에 작성한 코드를 보면 헷갈리시겠죠?

많은 프로그래머들은 코드를 어떻게 구성하는지, 어떻게 효율성을 높이는지, 어떻게 코드 유지 관리성, 재사용성, 확장성, 유연성을 향상하는지 모릅니다. 자신이 작성한 코드는 엉망이지만, 이렇게 엉망인 코드는 실제로는 정상적으로 실행될 수 있습니다.

이런 코딩 경험이 낯설지 않나요?

주변에 이런 경험을 하는 프로그래머들이 많을 겁니다. 1년 반만에 작성한 코드를 보면 정말 안타깝다는 생각이 듭니다. .. 정말 제가 예전에 썼던 코드인가요? 이렇게 나쁜 코드를 작성할 수 있을까요?

아직 유지되고 있는 코드는 이때 리팩토링할 아이디어가 떠오르거나, 더 좋은 방법이 나올 겁니다! 그것을 달성하기 위해. 이 시점에서 당신과 코드의 애증 관계는 이미 시작되었습니다...

이 영화는 주로 6가지 기본 원칙에서 시작하여 디자인 패턴에 대한 소개로서 6가지 기본 원칙과 디자인의 관계를 설명합니다. 패턴 후속편에서는 디자인 패턴을 하나씩, 디자인 패턴과 일상적인 개발에 대해 자세히 소개합니다.

기본 사양 및 제약 조건

자격을 갖춘 모든 팀은 한편으로는 표준을 통합하고 가독성과 유지 관리 가능성을 높이는 데 도움이 된다고 생각합니다. 나중에 버그가 발생하면 후발주자가 문제를 더 빨리 찾아 해결할 수 있습니다.

이 지저분한 코드는 큰 기능을 구현합니다. 후발주자들이 그것을 유지하기 위해 틀림없이 모든 조상들에게 따뜻한 인사를 전할 것입니다. 좋은 코딩 습관은 자격을 갖춘 프로그래머의 자기 수양에 속하며, 자신에게도 남에게도 해가 되지 않습니다.

개발 시 사양 및 제약 조건에 대해 가장 먼저 언급해야 할 것은 명명입니다.

지난 5년 동안 다양한 사람들과 협력해 왔고, 가장 기억에 남는 것은 여가 시간에 5개의 프로젝트를 동시에 개발하고 유지했다는 것입니다. 서로 배우고 함께 발전하는 삶, 이 과정에서 제가 가장 고민하는 것은 명명법의 불규칙성입니다.

모든 종류의 이상한 이름을 가진 비표준 스타일이 많이 있습니다. 이러한 이름 목록을 본 적이 있습니다. 하나는 열 세부 정보라고 하고 다른 하나는 열 메시지라고 합니다. 이름은 "ZhuanLaiLiuYanActivity"이므로 혼란스럽습니다.

그런 이름이 두렵다면 정말 세상을 본 적이 없는 것입니다. 이것은 적어도 중국어 병음 약어를 본 적이 있습니다. 동물검사 증명서의 이름이 djz로 되어 있어 더욱 혼란스럽습니다.

병음 명명에 관해 여기서 말하면 비난을 받을지 모르겠습니다. 한어 병음은 중국 문화를 홍보하기 위한 중국 국가의 훌륭한 계획이지만 항상 병음 명명을 좋아하는 친구들을 만났습니다. 프로그래밍할 때 병음은 정말 기분이 너무 나빠요.

가장 강력한 기술의 지원에도 불구하고 작성된 코드는 초등학생의 작업처럼 보입니다. 여기서 중국어 병음을 무시하려는 것이 아니라 단지 내 생각을 일부 표현한 것뿐입니다.

권장 사항: 큰 혹, 작은 혹 또는 밑줄 이름 지정은 허용됩니다. 통일된 표준이 없는 경우 "알리바바 Java 개발 매뉴얼"을 참조하여 업계에 막 입문하는 친구들은 명명부터 시작해야 합니다. 앞으로 성장하는데 큰 도움이 될 것입니다.

개발 매뉴얼 다운로드 주소: https://pan.baidu.com/s/1mjZxvSW.

다음으로 강조할 점은 댓글입니다. 많은 사람들은 댓글이 많을수록 좋다고 생각할 수도 있지만, 댓글이 우리에게 많은 부담과 오해를 가할 때도 있습니다.

지난 리뷰에서 일부 동료가 내 코드 일부를 복사했을 때 실제로는 다른 기능을 만들고 싶어했다는 사실을 발견했습니다. 그들은 단지 일부 코드를 복사하고 대대적인 수정을 가하고 싶었을 뿐입니다. 유사한 기능) 더 유연하고 코드의 재사용성과 유연성을 향상시키는 것이 가장 좋습니다.

사실 재사용할 수 있는 곳이 거의 없습니다. 왜 제가 직접 코드 몇 줄도 작성하지 않았는지 이해가 안 가는데, 제 노트도 복사해 두었다는 게 헷갈리네요. 제가 그 수업을 진행하고 있을 때, 그 저자가 바로 저라는 것을 알게 되었습니다. 나는 역사적인 제출물을 확인하기 위해 git에 갔습니다. 그것은 나와 관련이 없으며, 기능 설명은 이 수업과 전혀 관련이 없습니다. ...

댓글과 관련하여 한 가지 더 말씀드릴 점은 중복된 댓글입니다. 이것을 필요와 명명의 조합이라고 합니다. 좋은 명명 기준은 로그인 및 등록 댓글과 같은 불필요한 댓글을 많이 생략할 수 있으며, 완전히 불필요한 것입니다.

좋은 습관은 개발에 많은 편리함을 가져다 줄 수 있지만 어떤 사람들은 이름을 textview1 및 textview2로 지정하고 싶어합니다. 댓글을 달더라도 아래에서 사용하면 여전히 위아래로 뛰는 알파카 그룹이 될 것입니다. 친절한.

1.for (int i = 0; i

2. // TODO

3. }

이러한 코드의 경우 많은 사람들이 정상이라고 생각할 수도 있습니다. Tan Haoqiang 선생님을 비난하십시오. 그렇습니다. Tan Haoqiang의 책에는 실제로 많은 문제가 있지만 이것이 이런 종류의 코드를 작성하는 이유는 아닙니다.

일상적인 개발에서는 다른 사람의 코드를 유지하면서 항상 for 문을 디버깅합니다. 이런 코드는 주석을 추가해도 여전히 엉망이라는 생각이 들지 않나요?

팀마다 고유한 규범과 제약 사항이 있기 때문입니다. 대기업에는 각 팀마다 통일된 자체 규범 세트가 있기 때문입니다. 언어마다 제약 사항도 다릅니다. 나중에 시간이 나면 자세히 작성해 보겠습니다. 제약 조건에 대한 기사. 사양이 포함된 무료 블로그입니다.

이 분야에 대해 쓰고 싶은 내용이 정말 많습니다. 케이스 이후의 무분별한 사용, 1, 2, 3은 항상 혼란스럽습니다. 필요한 상수 대체 변수, 스레드를 대체하는 스레드 풀 등 싱글톤에 대해서는 정말 많은 것들이 있기 때문에 오늘은 네이밍(naming)과 주석(Annotation)이라는 두 가지 핵심 사항에 대해 설명하겠습니다.

권장 사항: 주석을 합리적으로 사용하십시오. 초보자의 경우 익숙하지 않은 코드와 불명확한 논리를 배울 때 이해를 돕기 위해 가능한 한 많은 주석을 사용하십시오.

댓글의 효과는 네이밍을 통해 얻을 수 있지만, 로직이 복잡하거나 동작 상태가 너무 많은 경우에는 유지관리 비용을 줄이기 위해 꼭 필요한 코멘트가 여전히 매우 중요합니다.

익숙해야 할 몇 가지 프로그래밍 아이디어

프로그래머가 프로그램을 작성하는 데 소요되는 시간은 작업 시간의 약 10-20%를 차지합니다. 대부분의 프로그래머는 최종 프로그램에 들어가기 위해 매일 약 10-12줄의 코드를 작성할 수 있습니다. 제품의 코드 - 기술 수준이 아무리 높더라도 마찬가지입니다.

훌륭한 프로그래머는 최적의 솔루션을 찾기 위해 생각하고 연구하고 실험하는 데 시간의 90%를 보냅니다. 나쁜 프로그래머는 문제가 있는 프로그램을 디버깅하고 특정 작성 방식이 작동할 것이라는 희망으로 맹목적으로 프로그램을 수정하는 데 시간의 90%를 소비합니다.

훌륭한 프로그래머에게는 논리가 가장 중요합니다. 그렇게 하면 버그가 더 적게 나타나고 버그율도 매우 낮은 수준으로 줄어들 수 있습니다.

나는 아주 좋은 개발자는 아니지만 수년 동안 이러한 습관을 유지하고 있습니다. 복잡하거나 다양한 기능에 대해서는 항상 내 아이디어를 먼저 명확하게 하고 어떤 작업이 있을 것인지, 버그가 발생할 수 있는 곳은 어디인지 나열합니다. 저는 팀원들에게 천 마디 말보다 한 장의 그림이 낫다고 자주 언급합니다. 시작하기 전에 생각을 명확하게 하면 절반의 노력으로 두 배의 결과를 얻을 수 있습니다.

비즈니스 로직이 복잡하든 아니든 그냥 작업을 시작하세요. 잘못된 부분을 발견하면 수정하게 됩니다. 이로 인해 항상 코드가 쌓이게 됩니다. 많은 수정 끝에 그것은 인식할 수 없을 정도로 되었고, 그것을 유지하는 사람들에게는 더욱 비참합니다.

여기서 저자는 독자들이 먼저 그림을 그려보고, 계속해서 모듈을 인터페이스로 분해하고, 인터페이스를 구현하여 모듈을 구현하고, 인터페이스 지향 프로그래밍을 달성하면 유지 관리성이 많이 향상될 것이라고 제안합니다. ...

모듈 간의 통신은 클래스 간의 연관이 아니라 추상화를 통한 상호 작용을 달성해야 합니다. 추상화는 세부 사항에 의존해서는 안 되고, 세부 사항은 추상화에 의존해야 합니다. 구현 지향 프로그래밍이 아닌 인터페이스 지향 프로그래밍입니다.

이것의 장점은 나중에 호출된 클래스를 다른 구현 클래스로 교체하려는 경우 인터페이스를 조정하기 때문에 호출한 클래스를 하나씩 변경할 필요가 없다는 것입니다. 인터페이스의 구현 클래스를 구성에서 새 클래스로 바꾸면 모든 것이 대체됩니다.

클래스 간 결합이 약할수록 재사용에 유리합니다. 약 결합 클래스를 수정해도 관련 클래스에는 영향을 미치지 않습니다.

제안: 시작하기 전에 생각을 명확하게 하면 절반의 노력으로 두 배의 결과를 얻을 수 있습니다. 개발 과정에서 인터페이스를 먼저 정의하고 인터페이스를 구현하여 모듈 개발을 완료하면 버그율을 최대한 줄이고 더 나은 코드를 작성할 수 있습니다.

기술적 역량의 향상은 주로 "높은 응집력과 낮은 결합력"의 코드에 반영됩니다. 왜냐하면 이러한 아이디어가 현재 인기 있는 MVC, MVP, MVVM 등과 같은 많은 개발 모델을 파생시켰기 때문입니다.

버전 반복 및 재구성

시스템을 구축할 때 시스템의 요구 사항이 처음에 결정되고 다시는 변경되지 않을 것이라고 기대해서는 안 됩니다. 이는 비현실적이고 비과학적인 아이디어이며 요구 사항은 반드시 변경, 그러면 요구사항 변경에 직면했을 때 설계 소프트웨어를 어떻게 상대적으로 쉽게 수정할 수 있습니까? 그래서 새로운 요구사항이 발생하면 전체 프로그램을 폐기하고 다시 시작해야 합니다.

많은 친구들이 이 문제에 직면했다고 생각합니다. 원래는 매우 일반적인 요구 사항이 N번의 반복과 수정을 거쳐 거대한 기능을 형성했습니다. 버전이 계속해서 반복되면서 유지 관리 비용도 커집니다. 악순환이 반복되고 리팩토링 코드가 역사의 단계로 진입하게 됩니다.

유지관리 비용의 관점에서 보면 재건축이 원래의 기본 유지관리 비용보다 훨씬 저렴하고 향후 유지관리에도 더 편리하다는 점은 부인할 수 없습니다. 일부 회사에서는 여러 버전을 반복한 후 전체 프로젝트를 직접 재구성하도록 추진하기도 합니다. 이런 일은 소규모 회사에서만 발생하는 것이 아니라 일부 대기업에서도 자주 발생합니다.

기술적으로 복잡한 코드를 리팩토링할 때 해야 할 일은 세 가지입니다. 기존 코드를 이해하고, 기존 코드를 분해하고, 새 코드를 빌드하는 것입니다.

리팩토링해야 할 이전 코드는 이해하기 어려운 경우가 많습니다. 특히 여러 번 반복되고 많은 사람이 처리하는 모듈에서는 모듈 간의 과도한 결합으로 인해 단일 동작이 전체 본문에 영향을 미치므로 범위를 제어하기가 어렵습니다. 영향; 오래된 코드는 테스트하기 어렵기 때문에 특히 제품 문서가 불완전한 경우 새 코드의 정확성이 보장되지 않습니다.

이것은 지난 리뷰에서 발견한 코드입니다. 상수의 불규칙한 사용에 대해서는 이야기하지 않겠습니다. 이것은 제품 반복의 결과이지만 제가 너무 많은 바퀴를 만들었다는 것은 아닙니다. 해야 한다. 코드 재사용에 대한 부정적인 교재로 여기에 생생하게 반영되어 있습니다. 상태가 더 많으면 여러 번 반복될 수밖에 없습니다...

추천: 리팩토링은 만병통치약이 아니며, 후속 작업을 거친 후입니다. 여러 버전이 개정되면서 코드는 난잡해지고 체계적이지 않게 되었으며, 코드의 난잡함은 늘 반복되었습니다.

향후 요구사항이 수정될지 여부를 판단하는 것은 불가능하므로 코드 품질을 개선하고, 변경 사항에 대처하기 위해 동일하게 유지하고, 인터페이스를 합리적으로 설계하고, 요구사항이 바뀔 때마다 더 많이 생각함으로써 대처할 수 있습니다. 변경되고, 여러 번 사용되는 코드를 캡슐화하고 추출하여 기존 로직을 최소한으로 변경합니다.

디자인 패턴의 중요성

디자인할 줄 아는 사람은 건설기술자이고, 디자인할 줄 모르는 사람은 벽돌을 옮기는 사람이다.

앞서 많이 말했지만 이제 디자인 패턴의 중요성에 대해 직접 이야기해 보겠습니다. 건축 디자인에 있어서는 디자인 패턴의 중요성에 대해 6가지 기본 원칙을 언급해야 합니다. 상상할 수 있습니다.

먼저, 제가 이전에 읽은 책들에서는 일반적으로 단일 책임 원칙, 데메테르의 법칙, 리히터 대체 원칙, 열기 및 닫기 원칙, 종속성 반전 원칙 및 인터페이스 격리의 6가지 기본 원칙이 여전히 약간 논란의 여지가 있습니다. 원칙.

그런데 최근 몇몇 게시물에서 인터페이스 격리 원칙은 없지만 합성/집합 재사용 원칙이 있다는 내용을 본 적이 있는데, 이전 준비에 영향을 주지 않기 위해 합성/집합 재사용 원칙에 대해서는 별도로 논의하겠습니다.

6가지 기본 원칙은 건축 디자인 전체의 영혼이자 건축 디자인의 지도 이념입니다. 디자인 패턴은 건축 디자인의 구체적인 디자인 기법이자 건축 디자인의 구체적인 실천입니다.

건축 디자인부터 시작해 보겠습니다. 아키텍처 디자인은 주로 추상화 기능에 반영됩니다. 추상화 기능은 건축가의 코딩 경험, 기능적 분해 및 이해, 논리적 엄격함에 따라 달라집니다.

건축 설계를 할 때는 문제를 최대한 포괄적으로 고려해야 하며, 바다는 모든 강에 열려 있고, 이는 건축 디자이너의 기본 조건입니다. 있어야합니다.

고려된 문제가 더 포괄적이고 포괄적일수록 작업은 더 어려워지고 자신에게 더 많은 장애물이 생길 것입니다. 이러한 세부적인 문제를 합리적으로 추상화하고 솔루션을 제안하는 것이 추상화 수준이 높을수록 솔루션이 더 합리적이라는 것이 건축가의 가치입니다.

특정 요구사항부터 코드 구현, 특정 제품까지. 아키텍처 디자인의 목적은 시스템의 재사용성, 확장성, 안정성에 지나지 않습니다. 구체적인 것들은 이러한 특성을 잘 반영할 수 없습니다.

아키텍처 설계 과정에서 단일 책임 원칙은 높은 응집력과 낮은 결합도를 더 잘 반영해야 함을 알려줍니다. 이 클래스는 데이터 요청에 사용됩니다. 이미지를 로드할 때 하나의 클래스가 하나의 책임만 담당하고 변경 이유는 하나만 있도록 뷰의 주석을 분리하세요.

학급이 더 많은 책임을 맡게 되면 이러한 책임을 함께 결합하게 되어 불필요한 유지 관리 비용이 발생하게 됩니다. 큰 관점에서 볼 때 MVP와 MVC 패턴은 모두 단일 책임 원칙의 구현입니다. 모델, 뷰 및 제어는 격리되어 있으며 각각 자체 임무를 수행합니다.

Demeter의 법칙은 두 클래스가 서로 직접 통신할 필요가 없다면 두 클래스도 직접 상호 작용해서는 안 된다고 안내합니다. 한 클래스가 다른 클래스의 메서드를 호출해야 하는 경우 해당 호출을 제3자를 통해 전달할 수 있습니다.

클래스 간 결합이 약할수록 재사용에 유리합니다. 약 결합 클래스를 수정해도 관련 클래스에는 영향을 미치지 않습니다. 주요 강조점은 클래스 간의 느슨한 결합입니다.

Liskov 대체 원칙에 관해서는 많은 사람들이 이 용어를 들어보지 못했을 수도 있지만 실제 개발 과정에서 항상 사용됩니다. 실제로 하위 유형은 상위 유형을 대체할 수 있어야 합니다.

간단한 예를 들어 보겠습니다. "List list = new ArrayList();" 이렇게 하면 실제로는 매우 간단합니다. 예를 들어 어느 날 ArrayList가 수요를 충족할 수 없어 LinkedList를 사용해야 합니다. . ArrayList만 변경하면 됩니다. 전역 목록 개체를 변경하는 대신 LinkedList로 바꾸면 유지 관리가 향상됩니다.

열림 및 닫힘 원리는 객체지향 원리의 핵심으로 확장 가능 부분과 수정 불가능 부분으로 구성됩니다. 소프트웨어 요구사항은 항상 변경됩니다. 소프트웨어 설계자의 경우 원래 시스템을 수정하지 않고 유연한 시스템 확장을 달성하는 것이 필요합니다.

확장에 개방적이라는 것은 추상화가 상대적으로 안정적이기 때문에 추상 프로그래밍을 의미합니다. 확장은 인터페이스나 추상 클래스를 통해 제한되며 인터페이스나 추상 클래스에 존재하지 않는 공용 메서드는 확장에 대해 정의됩니다. 나타나다.

클래스가 고정된 추상화에 의존하도록 하여 수정이 불가능하도록 합니다. 이는 추상 클래스의 상속을 구현하고 해당 메서드를 재정의하여 메서드를 확장할 수 있는 상속 및 다형성을 기반으로 합니다.

종속성 역전의 원리는 특정 구현에 의존하기보다는 추상화에 의존하는 것을 의미합니다. 실제로 이는 구현 지향 프로그래밍이 아닌 인터페이스 지향 프로그래밍입니다.

일반적으로 추상화 변경 확률은 매우 작기 때문에 사용자 프로그램이 추상화에 종속되고 구현 세부 사항도 추상화에 종속됩니다. 구현 세부 사항이 계속 변경되더라도 추상화가 변경되지 않는 한 클라이언트 프로그램은 변경할 필요가 없습니다. 이는 클라이언트 프로그램과 구현 세부 사항의 결합을 크게 줄입니다.

인터페이스 격리의 원칙은 "단일 인터페이스를 사용하는 것보다 여러 개의 특화된 인터페이스를 사용하는 것이 더 낫다"는 것입니다.

모듈은 필요한 인터페이스에 의존해야 하며, 필요한 모든 인터페이스를 제공하고, 불필요한 인터페이스를 제거하는 동시에 단일 책임 원칙을 따라야 합니다. 그래야 비대해진 인터페이스로 인한 오염을 방지하고 관련 없는 인터페이스를 제거할 수 있습니다. 부풀어 오른 대형 인터페이스를 형성하기 위해 이들을 병합하는 것은 인터페이스에 대한 일종의 오염입니다.

인터페이스의 세분성은 너무 작아서는 안 됩니다. 너무 작으면 인터페이스 수가 급격히 늘어나 개발자에게 불리합니다. 인터페이스의 세분성이 너무 크면 유연성이 줄어들고 맞춤화됩니다. 서비스를 제공할 수 없으며 이는 전체 프로젝트에 예측할 수 없는 결과를 가져올 수 있습니다. 위험, 합리적인 인터페이스 디자인도 예술입니다.

많은 디자인 패턴이 여러 가지 기본 원리를 사용하기 때문에 이 그림에 대해서는 논란이 많을 것입니다. 위 그림은 단지 디자인 패턴을 대략적으로 요약한 것일 뿐입니다.

6가지 기본 원칙(합성/집합 및 재사용 원칙 포함)을 디자인 패턴에 구체적으로 구현한다는 점을 강조하며, 6가지 기본 원칙과 23가지 디자인 패턴이 서로 상호보완적임을 설명합니다. 디자인 패턴의 초석이 되는 디자인 패턴은 6가지 기본 원칙을 적용한 유연한 구현입니다.

합성/집계 및 재사용 원칙은 다소 논란의 여지가 있습니다. 현재 일부 책에서는 여전히 구성/집계 재사용 원칙을 유지하고 인터페이스 격리 원칙을 제거합니다. 구성/집계 재사용 원칙은 상속을 덜 사용하고 구성 관계를 더 많이 사용하는 것을 의미합니다.

구성과 집합은 모두 객체 모델링 관계의 유형입니다. 집합은 전체가 부분으로 구성되어 있고, 부분이 전체와 분리되지 않고 독립적인 개체로 존재할 수 있다는 것을 의미합니다. , 부분과 전체의 엄격한 관계를 구현합니다. 부분과 전체의 수명주기는 일관되며 부분은 전체와 분리될 수 없습니다.

요약: 6가지 기본 원칙은 객체 지향 사고의 구현이고, 단일 책임 원칙과 인터페이스 격리 원칙은 캡슐화 개념을 구현하고, 열기 및 닫기 원칙은 객체의 캡슐화와 다형성을 구현합니다. Liskov 대체 원칙은 객체 상속에 대한 사양입니다.

의존성 역전 원리는 다형성과 추상적 사고를 구현한 것입니다. 객체지향에 대한 완전한 이해와 기본 설계 원리를 숙지하고 프로젝트 설계에 유연하게 활용할 수 있는 능력을 바탕으로 코드 품질과 구조 설계를 향상시킬 수 있습니다.

특히 디자인 패턴을 이해하고 마스터하는 데 필요한 지식인 재사용성, 유지 관리성, 확장성 및 유연성을 보장합니다.

Supplement

우리 모두는 6가지 기본 원칙을 염두에 두고 개발에 유연하게 활용해야 합니다. 일상적인 개발에서 디자인 패턴을 적용하는 데 있어 한 가지 강조해야 할 점은 자신에게 가장 적합한 것입니다. 의.

이때 모듈이 매우 가볍고 단지 디자인 패턴을 사용하기 위해 디자인 패턴을 사용한다면 이는 의심할 여지없이 설명 없이 나타나 프로젝트를 부풀리게 만들고 불필요한 유지 관리 비용도 발생합니다(유지 관리 비용은 매우 낮지만). .

저는 최근 정보를 정리하고 디자인 패턴에 대한 특별한 주제를 작성할 준비를 시작했습니다. 주로 MVP 함정과 데메테르의 법칙, 프레임워크와 열기 및 닫기 원칙, 싱글톤과 함정, 스키닝 및 관찰자 패턴, 로딩 목록 및 템플릿 방법에 중점을 둡니다. 패턴, 생성자와 빌더 간의 비교, 여러 타사 로그인 및 명령 모드는 앞으로도 계속 개선될 예정이므로 계속 지켜봐 주시기 바랍니다.