프로그래머 공동 개발 네트워크 프로그래머 프로그래밍의 10계명

1.- DRY: 같은 말을 반복하지 마세요.
DRY는 가장 간단한 규칙이자 이해하기 가장 쉽습니다. 그러나 적용하기가 가장 어려울 수도 있습니다(이를 위해서는 일반 디자인에 상당한 노력이 필요하며 이는 쉬운 작업이 아닙니다). 이는 두 개 이상의 위치에서 유사한 코드를 발견하면 공통성을 추상화하여 고유한 새 메서드를 형성하고 기존 위치의 코드를 변경하여 일부를 사용하도록 해야 함을 의미합니다. 적절한 매개변수와 함께 이 새 메서드를 호출합니다.
DRY 이 규칙은 프로그래밍에서 가장 일반적인 규칙일 수 있습니다. 지금까지 어떤 프로그래머도 이 규칙에 이의를 제기해서는 안 됩니다. 그러나 일부 프로그램에서는 단위 테스트를 작성할 때 이 규칙을 잊어버리는 것을 볼 수 있습니다. 클래스의 여러 인터페이스를 변경할 때 DRY를 사용하지 않으면 호출을 통과한 사람들이 인터페이스의 단위 테스트 절차를 수행한다고 가정해 보겠습니다. 시스템 클래스를 수동으로 변경해야 합니다. 예를 들어, 단위 테스트의 많은 테스트 사례가 클래스를 구성하는 표준 공통 방법을 사용하지 않지만 각 테스트 사례가 자체적으로 클래스의 인스턴스를 구성하는 경우 클래스 생성자가 변경되면 다음을 수행해야 합니다. 수정하세요. 테스트 케이스가 몇 개 있나요? 이는 DRY 규칙을 사용하지 않은 결과입니다.
2.- 짧은 메소드
적어도 프로그래머가 짧은 메소드를 작성해야 하는 세 가지 이유가 있습니다.
코드를 읽기가 더 쉬워졌습니다.
코드를 재사용하기가 더 쉬워집니다. (짧은 방법으로 코드 간의 결합 정도를 줄일 수 있습니다.)
코드를 테스트하기가 더 쉬워집니다.
3.-좋은 명명 규칙
클래스, 함수 또는 변수의 이름이 " 영역에서" 수준에 도달하면 훌륭하고 통일된 명명 규칙을 사용하면 프로그램을 더 쉽게 읽고 유지 관리할 수 있습니다. "문자 그대로의 의미"를 사용하면 문서 수가 줄어들고 의사소통도 줄어들 수 있습니다. "프로그래밍에서 디자인 이름 지정에 대한 몇 가지 사항" 기사에서 몇 가지 팁을 얻을 수 있습니다.
4.- 각 수업에 올바른 책임을 부여하세요
하나의 수업, 하나의 책임 이러한 규칙은 수업의 SOLID 규칙을 참조할 수 있습니다. 그러나 여기서 우리가 강조하는 것은 단일한 책임이 아니라 올바른 책임입니다. Customer라는 클래스가 있는 경우 이 클래스에 판매 메서드를 두어서는 안 됩니다. 이 클래스에는 Customer와 가장 직접적으로 관련된 메서드만 두도록 할 수 있습니다.
5.- 코드 정리
코드 정리에는 두 가지 수준이 있습니다.
물리적 계층 구성: 사용하는 디렉터리, 패키지 또는 네임스페이스 구조에 관계없이 클래스를 쉽게 찾을 수 있도록 표준 방식으로 구성해야 합니다. 이것은 물리적 코드 조직입니다.
논리 계층 구성: 소위 논리 계층이란 주로 서로 다른 기능을 가진 두 개의 클래스나 메소드를 특정 사양을 통해 연결하고 구성하는 것을 의미합니다. 여기서 주요 관심사는 프로그램 모듈 간의 인터페이스입니다. 이것이 우리가 흔히 볼 수 있는 프로그램 모듈의 아키텍처입니다.
6.- 다수의 단위 테스트를 생성하라
단위 테스트는 BUG에 가장 가까운 곳이자, BUG를 수정하는데 드는 비용이 가장 저렴한 곳이기도 하며, 성공 여부를 결정짓는 곳이기도 하다. 또는 전체 소프트웨어의 품질이 저하되었습니다. 따라서 가능하면 더 나은 단위 테스트 사례를 더 많이 작성하여 나중에 해당 코드를 변경할 때 코드 변경이 다른 단위에 영향을 미치는지 쉽게 알 수 있도록 해야 합니다.
7.- 코드를 자주 리팩터링하세요.
소프트웨어 개발은 ​​코드가 실제 요구 사항의 최신 변경 사항을 따라갈 수 있도록 하는 지속적인 검색 프로세스입니다. 따라서 이러한 변경 사항을 따라잡기 위해서는 코드를 자주 리팩터링해야 합니다. 물론 리팩토링은 위험합니다. 모든 리팩토링이 성공적인 것은 아니며 언제든지 코드를 리팩터링할 수 있는 것도 아닙니다. 다음은 더 많은 버그가 발생하거나 이미 잘못된 코드가 악화되는 것을 방지하기 위해 코드를 리팩터링하기 위한 두 가지 전제 조건입니다.
테스트할 단위 테스트가 엄청나게 많습니다. 앞서 언급했듯이 리팩토링에는 보증 및 테스트를 위해 많은 수의 단위 테스트가 필요합니다.
모든 리팩토링을 크게 만들지 마세요. 큰 리팩토링 대신 작은 리팩토링을 조금씩 사용하세요. 처음에는 2000줄의 코드를 리팩터링하려고 계획했는데 3시간이 지나면 계획을 포기하고 코드를 원래 버전으로 되돌리는 경우가 너무 많습니다. 따라서 우리가 권장하는 것은 리팩토링은 조금씩 축적하는 것이 가장 좋다는 것입니다.
8.- 프로그램 댓글은 사악하다
이게 논란이 많겠군요. 대부분의 프로그래머들은 프로그램 댓글이 아주 좋다고 생각합니다. 그렇습니다. 이론상으로는 프로그램 댓글이 아주 좋습니다. 그러나 실제 프로그래밍에서는 프로그래머가 작성한 코멘트가 매우 열악하여(프로그래머의 표현력이 매우 문제가 됨) 프로그램 코멘트가 모든 악의 화신이 되고 우리가 프로그램을 읽을 수 없게 되는 경우가 대부분입니다. 이때 우리는 주석을 읽지 않고 코드를 직접 읽습니다. 따라서 여기에서 주석을 작성하지 말라고 권장하는 것은 아니지만, 주석이 충분하지 않은 경우 코드를 주석보다 더 읽기 쉽고 명확하며 더 좋게 만들기 위해 코드를 리팩터링하는 데 더 중요한 시간을 할애하는 것이 좋습니다.
9.- 구현이 아닌 인터페이스에 집중하세요
이것은 가장 고전적인 규칙입니다.인터페이스는 추상화인 "무엇"에 초점을 맞추고 구현은 세부 사항인 "어떻게"에 중점을 둡니다. 인터페이스는 계약과 동일하며, 실제 세부 사항은 본 계약의 운영 및 구현과 동일합니다. 운영은 매우 유연할 수 있지만 계약은 상대적으로 안정적이고 변경되지 않아야 합니다. 인터페이스가 잘 설계되지 않았고 빈번한 변경이 필요하다면 이번 세대에서는 확실히 비용이 많이 드는 일이 될 것입니다. 따라서 소프트웨어 개발 및 디버깅에서는 구현이 아닌 인터페이스가 최우선입니다. 그러나 우리 프로그래머들은 항상 구현 세부 사항에 중점을 두기 때문에 부분적인 코드는 매우 훌륭하지만 전체적인 소프트웨어 설계는 상대적으로 열악합니다. 이를 위해서는 우리의 더 많은 관심이 필요합니다.
10.- 코드 검토 메커니즘
한 사람이 실수할 확률은 매우 높습니다. 사람이 많을수록 실수할 확률은 줄어듭니다. 실수할 확률. 사람이 많아지면 사물을 다른 관점에서 볼 수 있기 때문에 비효율적인 논쟁으로 이어질 수 있지만, 소프트웨어 제품이 출시된 후 발생하는 문제의 유지 비용에 비하면 이 비용은 상당히 가치가 있습니다. 그러므로 우리는 다양한 사람들이 코드를 검토할 수 있도록 해야 합니다. 코드 검토 메커니즘은 문제를 발견하는 가장 효과적인 메커니즘일 뿐만 아니라 지식 공유를 위한 메커니즘이기도 합니다. 물론, 코드 리뷰에는 아래와 같은 몇 가지 기본 원칙이 있습니다.
리뷰어의 능력은 코드 작성자의 능력보다 크거나 같아야 합니다. 그렇지 않으면 코드 리뷰는 일종의 초보자 교육이 됩니다.
또한 리뷰어가 형식적인 리뷰를 하는 것이 아니라 진정한 책임을 지기 위해서는 코드 작성자가 아닌 자신이 리뷰한 코드에 대해 리뷰어가 일차적인 책임을 갖도록 해야 합니다.
또한 좋은 코드 리뷰는 코드가 완성되었을 때 하는 것이 아니라, 코드 작성 과정에서 반복적인 코드 리뷰를 하는 것입니다. 코드 검토는 코드 완료 여부에 관계없이 며칠에 한 번씩 지속적으로 수행하는 것이 좋습니다.

이상은 프로그래머를 위한 공동 개발 네트워크의 내용을 포함하여 프로그래머를 위한 공동 개발 네트워크와 프로그래머 프로그래밍의 10계명을 소개한 내용입니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되길 바랍니다.