내가 깨끗한 코드 시리즈를 작성하기 시작했을 때, 목적은 내가 이 주제에 관한 지식을 고정시키는 것일 뿐만 아니라, 내가 얻은 지식을 전달하는 것이다.
이 시리즈는 이 책의 빠른 안내서도 될 수 있다.내가 몇 가지 주제를 기억해야 할 때, 나는 내가 원하는 것을 더 빨리 찾을 수 있다.
, 나는 명칭, 함수, 주석에 대해 이야기했다.
나는 형식, 대상, 데이터 구조, 그리고 오류를 어떻게 처리하는지 이야기했다.
마지막 문장에서 나는 제3자 코드를 어떻게 처리하고 테스트와 클래스를 어떻게 조직하는지 토론했다.
이 9개의 주제 외에 이 깨끗한 코드북은 처리 시스템의 문제를 토론했고 자바에 관한 주제도 있었다. 코드의 냄새를 어떻게 식별하는지도 포함했다.
나는 이 시리즈가 모든 언어에 더욱 통용되고 우호적일 수 있도록 하기 위해서 이 주제들을 토론하지 않기로 결정했다.또한 저는 처음부터 시스템을 구축하는 실용적인 지식이 많지 않기 때문에 재구성에 관한 독점 시리즈가 코드 냄새 문제를 더욱 잘 해결할 수 있다고 믿습니다. 왜냐하면 이라는 책에서 이 주제는 좀 천박하기 때문입니다.
즉, 우리는 오늘 게시물의 주제부터 시작할 수 있다.

타사 코드 처리

우리는 혼자서 백 퍼센트 코드를 작성하기가 매우 어렵다.우리는 통상적으로lib를 사용하여 우리를 돕는다. 대부분의 경우, 일부 동료들은 코드를 공헌한다
중요한 것은 코드 경계를 어떻게 처리하고 우리의 코드가 어디에서 끝나는지, 다른 코드가 어디에서 시작되는지 식별하는 것이다. 이렇게 하면 우리는 시스템을 더욱 쉽게 유지할 수 있다.
제3자 코드를 사용하는 문제는 그들이 통상적으로 우리가 필요로 하는 것보다 더 많은 기능을 가지고 있기 때문에 우리의 코드를 이상하게 나타낼 수 있다는 것이다.

당신의 창고를 봉인하세요!

이 문제를 해결하는 가장 좋은 방법은 우리가 클래스에서 사용할 라이브러리를 봉인하고 우리가 필요로 하는 방법만 추출하는 것이다.
제3자 라이브러리를 자신의 클래스에 봉인하는 또 다른 장점은 이렇게 하면 우리는 라이브러리 버전을 더욱 쉽게 변경할 수 있고 심지어는 라이브러리 자체를 교환할 수 있다는 것이다.
우리의 코드에 결제 서비스에 연결된 라이브러리가 있다고 가정해 보세요.우리가 서비스를 변경하려고 할 때, 우리가 만든 클래스에서만 변경할 수 있습니다.우리는 낡은 라이브러리의 모든 인용을 새 라이브러리로 바꾸기 위해 전체 코드를 볼 필요가 없이 우리의 방법을 조정할 수 있다.

타사 코드 탐색

코드에 새 라이브러리를 추가하려면 그 기능과 작업 방식을 알아야 합니다.생산 과정에서 우리가 이해하지 못하는 코드를 사용하면 약간의 문제를 초래할 수 있다.
우리가 추가하고자 하는 라이브러리의 행동을 찾아내는 가장 좋은 방법은 라이브러리가 해결하고자 하는 상황을 위해 테스트를 작성하여 통과시키는 것이다.이렇게 하면 우리는 코드가 어떻게 작동하는지 이해할 수 있을 뿐만 아니라, 이러한 테스트는 어떤 버전이나 라이브러리 변경에도 매우 유용하다.
버전을 변경하고 테스트를 실행하면 더 이상 유효하지 않은 행동을 발견하고 수정할 수 있습니다.
만약 내가 몇 가지 주제에서 제3자 라이브러리가 코드에서 사용하는 것을 정리할 수 있다면, 그것들은 다음과 같다.

제3자 코드와 당신의 코드 사이의 명확한 분리를 유지합니다.

제3자lib의 행위 방식이 당신의 코드에 적합한지 확인하기 위해 좋은 테스트를 작성합니다.주의해야 할 것은 라이브러리가 아니라 코드를 테스트하고 있다는 것입니다.

우리의 코드가 제3자 코드와 연결되지 않도록 확보한다.네가 통제할 수 있는 것에 의존하는 것이 네가 통제할 수 없는 것에 의존하는 것보다 낫다.

코드가 가능한 한 적게 인용되고 문제가 발생할 때 라이브러리를 교환할 수 있도록 어댑터를 봉인하고 만듭니다.

조직 테스트

테스트를 작성할 때, 우리의 가장 큰 걱정은 그것의 가독성이어야 한다.
테스트 코드에서 생산 코드보다 가독성이 더 중요할 수 있다.
테스트를 작성할 때, 우리는 테스트에 속하지 않는 세부 사항을 작성하는 것을 피해야 한다. 앞으로 이 테스트를 복구해야 하는 사람들이 무슨 일이 일어나고 있는지 알고 불필요한 코드를 이해할 필요가 없도록 해야 한다.

테스트마다 하나의 단언을 사용합니다

이상적인 상황에서 모든 테스트는 단언만 있기 때문에 이런 상황이 발생할 때 테스트의 어느 부분이 중단되었는지 의심할 여지가 없다.
이 규칙은 여러 차례의 반복 테스트를 초래할 수 있다.이 문제를 해결하기 위해 before 과 중복된 코드 블록을 사용할 수 있습니다.
만약 중복이 너무 많다면, 우리는 심지어 모든 테스트에서 여러 개의 단언을 사용할 수 있지만, 매우 조심스럽게 단언의 수량을 유지해야 한다.
아니면, 내 생각에 의하면, 밥 아저씨가 아니라면, 당신은 이 문제를 해결할 수 없을 것이다. 왜냐하면 너무 많은 DRY 코드의 가독성을 손상시킬 수 있기 때문이다. 테스트를 할 때, 가독성은 항상 당신의 최우선 임무가 되어야 한다.
아마도 더 좋은 규칙은 모든 테스트가 하나의 개념만 테스트하는 것이다.
간결함을 유지하기 위해서는 한 번에 한 테스트를 넘지 않는 것이 매우 중요하다. 당신은 현재 발생하고 있는 일을 추적할 수 있다.
밥 아저씨는 알파벳 줄임말로 깨끗한 테스트의 규칙을 기억하는 데 도움을 준다.

F、 I.R.S.T

신속: 테스트는 신속해야 한다.만약 테스트 시간이 너무 길다면 우리는 테스트를 실행하고 싶지 않다.

독립: 한 테스트는 영원히 다른 테스트에 의존해서는 안 된다.모든 테스트를 중단 없이 무작위로 실행할 수 있을 것이다.

반복성: 테스트는 QA, 프로덕션 환경 또는 사용자 컴퓨터의 모든 환경에서 실행되어야 합니다.

인증: 테스트 결과는 항상 부울 값이어야 하며 통과 여부를 알려야 합니다.

제때: 그들은 코드를 생산하기 전에 정확한 시간을 가지고 쓴다.나중에 남겨두면 TDD가 아닌 테스트를 작성하기 어려울 수 있습니다.

교과 과정을 조직하다.

java에서 클래스의 조직 순서는 다음과 같습니다.

변수 목록입니다.

공공 정태 상수.

사유 정적 변수.

실례 사유 변수.

공공 기능.

공공 함수에서 호출되는 개인 함수는 공공 함수의 바로 아래에 있어야 한다.

그러나 루비와 다른 언어에서는 모든 개인 방법은 모든 공공 코드 다음에 그룹을 나누고 작성해야 한다.이상적인 상황에서 그들은 공공 방법에 따라 그들의 순서를 호출한다.

반은 작아야 한다.

우리가 함수를 말하려면 반드시 시간이 걸린다고 말하면, 우리는 그것이 반드시 몇 줄이 있어야 한다고 말한다.
우리가 한 반이 반드시 어려야 한다고 말했을 때, 우리의 뜻은 그것이 반드시 단일 책임의 원칙을 따라야 한다는 것이다.

그러나 우리는 한 종류가 너무 많은 책임이 있는지 어떻게 알 수 있습니까?

너무 많은 책임이 있는 첫 번째 표지는 그 이름이다.
클래스는 우리가 그것들의 작용을 이해할 수 있도록 해석적인 방식으로 명명해야 한다.만약 당신이'and','or','If','but'가 필요하다면, 그들은 이미 한 가지 일만 하고 있는 것이 아니다.
다음 예시에서 우리는 SuperDashboard류가 마지막으로 주목하는 구성 요소를 찾고 구축 버전을 변경하는 것을 볼 수 있기 때문에 두 가지 직책이 있다.

public class SuperDashboard {
  public Component getLastFocusedComponent();
  public int getMajorVersionNumber();
  public int getMinorVersionNumber();
  public int getBuildNumber();
}

이 문제를 해결하는 방법의 하나는 모든 직책을 위해 하나의 종류를 만드는 것이다.
어떤 사람들은 우리가 많은 수업을 할 때 우리가 원하는 것을 찾기 어렵다고 불평한다.
그러나 우리가 멈추고 생각할 때, 만약 우리가 많은 것을 가지고 있는 교실이 있다면, 우리는 우리가 원하는 것을 찾기 어려울 것이다.우리가 여러 종류가 있을 때, 마치 서랍 몇 개가 그것들의 내용을 표시하고 있는 것 같다.그러나 우리가 몇 시간밖에 수업을 하지 않았을 때, 우리는 서랍을 채우는 일이 매우 드물었다.

내중력 정보

이상적인 상황에서 클래스 내의 함수는 이 클래스에서 만든 변수와만 대화해야 하지만, 이것은 불가능하기 때문에, 우리는 클래스가 내중성을 갖추어야 한다.

재구성 후의 새로운 유형.

코드를 재구성할 때 흐름의 존재를 관찰할 수 있습니다. 이로 인해 더 많은 클래스가 생성될 수 있습니다.

우리가 하나의 큰 함수를 몇 개의 작은 함수로 분해할 때 우리는 변수를 공유해야 한다고 생각한다.

우리는 함수에 파라미터가 필요하지 않도록 클래스 실례 변수를 만들고 싶지만, 왜 우리는 소수의 함수가 사용할 실례 변수를 만들어야 합니까?이것은 보기에 그다지 재미있지 않다.

새 클래스를 만들 수 있다는 뜻이 아닙니까?D

코스를 구성하여 변경합니다.

우리는 하나의 종류는 반드시'개-닫기'원칙에 따라 확장에 대해 개방하고 변경에 대해 닫아야 한다는 것을 기억해야 한다.
때때로 우리의 클래스는 끊임없이 변화하는 제3자 라이브러리를 봉인한다.이런 상황이 발생할 때, 우리는 하나의 부류로 라이브러리에 연결하여 이 문제를 해결하고, 새로운 라이브러리로 여러 개의 하위 클래스를 만들 수 있다.
Sarah Dorweiler 이미지 게시