중재자 메모이
질문에는 이미 17 개의 답변이 게시되었습니다. 새로운 답변을 게시하기 전에 기존 답변을 읽고 귀하의 견해가 이미 적절하게 다루어지지 않았는지 확인하십시오.

Robert Martin의 "Clean Code"책에서 권장하는 몇 가지 관행, 특히 내가 사용하는 소프트웨어 유형에 적용되는 관행과 나에게 의미가있는 관행을 따랐습니다 (도그마로 따르지 않음). .

그러나 내가 알아 차린 부작용 중 하나는 내가 작성하는 "깨끗한"코드가 일부 관행을 따르지 않는 것보다 더 많은 코드라는 것입니다. 이를 이끌어내는 구체적인 관행은 다음과 같습니다.

• 캡슐화 조건

그래서 대신

if(contact.email != null && contact.emails.contains('@')

이런 작은 방법을 쓸 수 있습니다

private Boolean isEmailValid(String email){...}

• 인라인 주석을 다른 개인용 메소드로 대체하여 메소드 이름에 인라인 주석이 아닌 자체적으로 설명합니다.
• 수업은 한 가지 이유 만 변경해야합니다

그리고 다른 사람들도 있습니다. 요점은 30 줄의 방법 일 수있는 것은 주석으로 대체하고 조건을 캡슐화하는 작은 방법으로 인해 클래스가된다는 것입니다. 당신이 너무 많은 방법을 가지고 있다는 것을 깨닫게되면, 그것은 의미가 있습니다. 실제로는 메서드 였어야 할 때 모든 기능을 하나의 클래스에 넣습니다.

나는 극단으로 행한 행동은 해로울 수 있음을 알고 있습니다.

내가 찾고있는 구체적인 질문은 다음과 같습니다.

이것은 깨끗한 코드를 작성했을 때 허용되는 부산물입니까? 그렇다면 더 많은 LOC가 작성되었다는 사실을 정당화하기 위해 사용할 수있는 몇 가지 주장은 무엇입니까?

조직은 더 많은 LOC에 대해 특별히 염려하지 않지만, 더 많은 LOC는 매우 큰 클래스를 초래할 수 있습니다 (다시, 가독성을 위해 한 번만 사용하는 도우미 기능없이 긴 메소드로 대체 될 수 있음).

당신이 충분히 큰 수업을 볼 때, 그것은 수업이 충분히 바쁘고 책임이 끝났다는 인상을줍니다. 따라서 다른 기능을 수행하기 위해 더 많은 클래스를 작성할 수 있습니다. 결과는 많은 작은 도우미 메소드를 사용하여 "한 가지"를 수행하는 많은 클래스입니다.

이것은 특별한 관심사입니다 ...이 클래스는 많은 작은 방법의 도움 없이도 여전히 "한 가지"를 달성하는 단일 클래스 일 수 있습니다. 아마도 3 개 또는 4 개의 메서드와 주석이있는 단일 클래스 일 수 있습니다.

... 우리는 비교적 크고 문서화되지 않은 코드 기반 (우리가 상속 한)을 지원하는 매우 작은 팀이므로 일부 개발자 / 관리자는 작업을 수행하기 위해 더 적은 코드를 작성하여 가치를 유지하여 유지 보수 할 코드가 줄어 듭니다.

이 사람들은 무언가를 올바르게 식별했습니다. 코드를 더 쉽게 관리하기를 원합니다. 코드가 적을수록 유지 관리가 더 쉽다고 가정하지만 잘못되었습니다.

코드를 쉽게 유지 관리하려면 변경하기 쉬워야합니다. 변경하기 쉬운 코드를 얻는 가장 쉬운 방법은 변경 사항이 주요 변경 사항 인 경우 실패 할 수있는 전체 자동화 된 테스트 세트를 얻는 것입니다. 테스트는 코드이므로 해당 테스트를 작성하면 코드 기반이 팽창합니다. 그리고 그것은 좋은 것입니다.

둘째, 변경이 필요한 사항을 해결하려면 코드를 쉽게 읽고 추론 할 수 있어야합니다. 매우 간결한 코드, 줄 수를 줄이기 위해 크기가 줄어드는 것은 읽기 쉽지 않을 것입니다. 코드가 길수록 읽는 데 시간이 오래 걸리기 때문에 분명히 절충안이 있습니다. 그러나 이해하기가 더 빠르면 그만한 가치가 있습니다. 그것이 그 혜택을 제공하지 않는다면, 그 자세한 정보는 혜택이되는 것을 멈 춥니 다. 그러나 코드가 길수록 가독성이 향상되면 다시 한 번 좋습니다.

그렇습니다. 그것은 허용 가능한 부산물이며, 대부분의 코드를 대부분 읽을 필요가 없도록 구성되어 있습니다. 변경을 할 때마다 30 줄 기능을 읽는 대신 전체 흐름을 얻기 위해 5 줄 기능을 읽고 변경 사항이 해당 영역에 닿으면 몇 가지 도우미 기능을 사용할 수 있습니다. 새로운 "추가"클래스가 호출 EmailValidator되고 문제가 전자 메일 유효성 검사와 관련이 없다는 것을 알고 있으면 전체를 읽지 않아도됩니다.

더 작은 조각을 재사용하는 것이 더 쉬우므로 전체 프로그램의 줄 수를 줄이는 경향이 있습니다. 는 EmailValidator사방에 사용할 수 있습니다. 이메일 유효성 검사를 수행하지만 데이터베이스 액세스 코드와 함께 축소되는 일부 코드 줄은 재사용 할 수 없습니다.

그런 다음 전자 메일 유효성 검사 규칙을 변경해야 할 경우 수행해야 할 작업을 고려하십시오. 또는 몇 곳이 없을 수도 있습니다.

Bill Gates는 "코드 라인으로 프로그래밍 진행을 측정하는 것은 항공기 건물의 진행률을 무게로 측정하는 것과 같습니다"라고 말한 것으로 유명합니다.

나는이 감정에 겸손히 동의합니다. 이것은 프로그램이 더 많거나 적은 코드 라인을 위해 노력해야한다는 것이 아니라 궁극적으로 기능적이고 작동하는 프로그램을 만드는 데 중요한 것은 아닙니다. 궁극적으로 여분의 코드 줄을 추가 한 이유는 이론적으로 더 읽기 쉽다는 것을 기억하는 데 도움이됩니다.

특정 변경 내용을 읽을 수 있는지 여부에 대한 의견 불일치가있을 수 있지만 그렇게하면 프로그램 을 더 읽기 쉽게 만든다고 생각 하기 때문에 프로그램을 변경하는 것이 잘못되었다고 생각하지 않습니다 . 예를 들어를 만드는 isEmailValid것은 불필요하고 불필요하다고 생각할 수 있습니다. 특히 그것을 정의하는 클래스에 의해 정확히 한 번 호출되는 경우. 그러나 isEmailValid각 개별 조건이 무엇을 확인하고 왜 점검해야하는지 결정해야하는 일련의 AND 조건보다 조건을 더 많이보고 싶습니다.

문제가 발생 isEmailValid하는 곳은 부작용이 있거나 전자 메일 이외의 것을 확인 하는 방법을 만들 때 입니다. 단순히 모든 것을 작성하는 것보다 나쁩니다 . 오해의 소지가 있기 때문에 더 나쁘고 버그 때문에 놓칠 수 있습니다.

이 경우 분명히 그렇게하지는 않지만 계속하고 싶을 것입니다. 변경을 통해 읽기가 더 쉬운 지 항상 확인해야하며, 귀하의 경우에는 변경하십시오!

따라서 일부 개발자 / 관리자는 작업을 수행하기 위해 코드를 적게 작성하여 가치를보고 유지 관리 할 코드가 줄어 듭니다.

이것은 실제 목표에 대한 시야를 잃어 버리는 문제입니다.

중요한 것은 개발에 소요되는 시간을 줄이는 것 입니다. 그것은 코드 라인이 아닌 시간 (또는 동등한 노력)으로 측정됩니다.
이는 자동차 제조업체가 각 나사를 넣는 데 0이 아닌 시간이 걸리기 때문에 나사를 적게 사용하여 자동차를 만들어야한다는 말과 같습니다. 이는 정확하지만 자동차의 시장 가치는 나사 수에 따라 정의되지 않습니다 또는 없습니다. 무엇보다도 자동차는 성능이 뛰어나고 안전하며 유지 관리가 용이해야합니다.

나머지 답변은 깨끗한 코드가 어떻게 시간을 늘릴 수 있는지에 대한 예입니다.

벌채 반출

로깅이없는 애플리케이션 (A)을 가져옵니다. 이제 동일한 애플리케이션 A이지만 로깅이있는 애플리케이션 B를 작성하십시오. B에는 항상 더 많은 코드 줄이 있으므로 더 많은 코드를 작성해야합니다.

그러나 많은 시간이 문제와 버그를 조사하고 무엇이 잘못되었는지 알아내는 데 시간이 걸립니다.

응용 프로그램 A의 경우 개발자는 코드를 읽고 계속해서 문제를 재현하고 문제의 원인을 찾기 위해 코드를 단계별로 실행해야합니다. 즉, 개발자는 사용 된 모든 계층에서 실행 시작부터 끝까지 테스트해야하며 사용 된 모든 논리를 관찰해야합니다.
어쩌면 그는 그것을 즉시 찾아내는 것이 운이 좋을지 모르지만 아마도 대답은 그가 생각하는 마지막 장소에있을 것입니다.

응용 프로그램 B의 경우 완벽한 로깅을 가정하면 개발자는 로그를 관찰하고 결함이있는 구성 요소를 즉시 식별 할 수 있으며 이제 어디를 볼지 알 수 있습니다.

이것은 분, 시간 또는 일 절약의 문제 일 수 있습니다. 코드베이스의 크기와 복잡성에 따라

회귀

전혀 건조하지 않은 응용 프로그램 A를 가져 가십시오.
DRY 인 애플리케이션 B를 가져 오지만 추가 추상화로 인해 더 많은 행이 필요했습니다.

변경 요청이 제출되며 로직을 변경해야합니다.

응용 프로그램 B의 경우 개발자는 변경 요청에 따라 (고유, 공유) 논리를 변경합니다.

응용 프로그램 A의 경우 개발자는이 논리의 모든 인스턴스를 사용중인 것을 기억해야합니다.

• 모든 인스턴스를 기억하는 경우에도 동일한 변경 사항을 여러 번 구현해야합니다.
• 그가 모든 인스턴스를 기억하지 못한다면, 이제 모순되는 일관성이없는 코드베이스를 다루고있는 것입니다. 개발자가 거의 사용하지 않는 코드를 잊어 버린 경우이 버그는 최종 사용자에게 분명하지 않을 수 있습니다. 그 당시 최종 사용자가 문제의 원인을 파악하려고합니까? 그럼에도 불구하고 개발자는 변경에 따른 결과를 기억하지 못할 수 있으며 잊혀진이 논리를 변경하는 방법을 찾아야합니다. 어쩌면 개발자는 그때까지 회사에서 일하지 않을 수도 있으며, 이제 다른 사람이 처음부터 모두 알아 내야합니다.

이것은 엄청난 시간 낭비로 이어질 수 있습니다. 개발뿐만 아니라 버그를 찾아서 찾는 것입니다. 개발자가 쉽게 이해할 수없는 방식으로 응용 프로그램이 잘못 작동 할 수 있습니다. 그리고 그것은 긴 디버깅 세션으로 이어질 것입니다.

개발자 호환성

개발자 A가 만든 응용 프로그램 A. 코드는 깨끗하거나 읽을 수 없지만 매력처럼 작동하며 프로덕션 환경에서 실행되고 있습니다. 당연히 문서도 없습니다.

휴일로 인해 개발자 A는 한 달 동안 결석합니다. 긴급 변경 요청이 접수되었습니다. 개발자 A가 돌아올 때까지 3 주를 더 기다릴 수 없습니다.

개발자 B는이 변경을 실행해야합니다. 그는 이제 전체 코드베이스를 읽고 모든 것이 작동하는 방식, 작동하는 이유 및 달성하려는 목표를 이해해야합니다 . 나이가 들지만 3 주 후에 할 수 있다고 가정 해 봅시다.

동시에 응용 프로그램 B (개발자 B가 만든 응용 프로그램 B)에 응급 상황이 발생했습니다. 개발자 B는 사용 중이지만 코드베이스를 모르는 경우에도 개발자 C를 사용할 수 있습니다. 우리는 무엇을해야합니까?

• B가 A 작업을 계속하고 C가 B 작업을하게한다면, 자신이하는 일을 모르는 두 명의 개발자가 있고 그 작업은 차선책으로 수행됩니다.
• B를 A에서 빼내고 B에게 맡기고 C를 A에 놓으면 개발자 B의 모든 작업 (또는 상당 부분)이 폐기 될 수 있습니다. 이 작업은 잠재적으로 며칠 / 주간의 노력이 낭비됩니다.

개발자 A는 휴가를 마치고 돌아와서 B가 코드를 이해하지 못하여 코드를 잘못 구현했음을 알았습니다. 그가 사용할 수있는 모든 리소스를 사용했기 때문에 B의 잘못이 아닙니다. 소스 코드는 읽기 쉽지 않았습니다. A는 이제 코드의 가독성을 수정하는 데 시간을 소비해야합니까?

이러한 모든 문제와 더 많은 문제는 시간 을 낭비하게됩니다 . 예, 단기적으로 깨끗한 코드는 지금 더 많은 노력이 필요 하지만, 불가피한 버그 / 변경 사항을 해결해야 할 경우 배당금 을 지불 하게됩니다.

경영진은 이제 짧은 작업이 앞으로 몇 개의 긴 작업을 절약 할 수 있음을 이해해야합니다. 계획 실패는 실패 할 계획입니다.

그렇다면 더 많은 LOC가 작성되었다는 사실을 정당화하기 위해 사용할 수있는 몇 가지 주장은 무엇입니까?

저의 설명은 경영진에게 3 개월 동안 개발할 수있는 100KLOC 코드베이스 또는 6 개월 동안 개발할 수있는 50KLOC 코드베이스가있는 응용 프로그램을 선호하는 것입니다.

경영진은 KLOC에 신경 쓰지 않기 때문에 개발 시간을 단축 할 것 입니다. KLOC에 중점을 둔 관리자는 관리하려는 대상에 대한 정보를 얻지 못한 채 미세 관리하고 있습니다.

난 당신이해야한다고 생각 매우 그들은 더 많은 전체의 복잡성으로 이어질 경우 "클린 코드"관행을 적용하는 방법에 대한주의. 조기 리팩토링은 많은 나쁜 것들의 뿌리입니다.

함수에서 조건부를 추출하면에서 조건부를 추출한 지점에서 코드가 단순 해지지 만 이제 프로그램의 더 많은 점에서 볼 수있는 함수가 있으므로 전체적으로 더 복잡해 집니다 . 이 새 기능이 표시되는 다른 모든 기능에 약간의 복잡성 부담이 가중됩니다.

나는 당신 이 조건부를 추출 해서는 안된다고 말하는 것이 아니라 단지 필요한 경우 신중하게 고려해야한다는 것입니다.

• 전자 메일 유효성 검사 논리를 구체적으로 테스트하려는 경우 그런 다음 해당 논리를 별도의 함수-아마도 클래스로 추출해야합니다.
• 코드의 여러 위치에서 동일한 논리를 사용하는 경우 분명히 단일 함수로 추출해야합니다. 자신을 반복하지 마십시오!
• 논리가 분명히 별도의 책임 인 경우, 예를 들어 이메일 유효성 검사는 정렬 알고리즘 중간에 발생합니다. 이메일 유효성 검사는 정렬 알고리즘과 독립적으로 변경되므로 별도의 클래스에 있어야합니다.

위의 모든 것에서 "깨끗한 코드"가 아닌 추출의 이유가 있습니다. 또한, 그것이 옳은 일이라면 의심의 여지가 없을 것입니다.

의심 스러우면 항상 가장 단순하고 가장 간단한 코드를 선택하십시오.

나는 이것에 본질적으로 아무런 문제가 없다고 지적했다.

if(contact.email != null && contact.email.contains('@')

적어도 한 번만 사용한다고 가정합니다.

나는 이것에 매우 쉽게 문제가있을 수 있습니다 :

private Boolean isEmailValid(String email){
   return email != null && email.contains('@');
}

내가 볼 몇 가지 :

1. 왜 사적인가요? 잠재적으로 유용한 스텁처럼 보입니다. 사적인 방법이 될만큼 유용하고 더 널리 사용될 가능성은 없습니까?
2. 메서드의 이름을 개인적으로 지정하지 않을 것입니다. 실제 유효성 검사가 거의 없기 때문에 아마도 ContainsAtSign 또는 LooksVaguelyLikeEmailAddress 일 것입니다.
3. 두 번 이상 사용됩니까?

한 번 사용되면 구문 분석이 간단하고 한 줄 미만이 걸리므로 결정을 두 번째로 추측합니다. 팀의 특별한 문제가 아니라면 내가 부르는 것이 아닐 것입니다.

반면에 나는 방법이 다음과 같은 것을하는 것을 보았습니다.

if (contact.email != null && contact.email.contains('@')) { ... }
else if (contact.email != null && contact.email.contains('@') && contact.email.contains("@mydomain.com")) { //headquarters email }
else if (contact.email != null && contact.email.contains('@') && (contact.email.contains("@news.mydomain.com") || contact.email.contains("@design.mydomain.com") ) { //internal contract teams }

이 예는 분명히 건조하지 않습니다.

또는 그 마지막 진술조차도 다른 예를 제시 할 수 있습니다.

if (contact.email != null && contact.email.contains('@') && (contact.email.contains("@news.mydomain.com") || contact.email.contains("@design.mydomain.com") )

목표는 코드를 더 읽기 쉽게 만드는 것입니다.

if (LooksSortaLikeAnEmail(contact.Email)) { ... }
else if (LooksLikeFromHeadquarters(contact.Email)) { ... }
else if (LooksLikeInternalEmail(contact.Email)) { ... }

다른 시나리오 :

다음과 같은 방법이있을 수 있습니다.

public void SaveContact(Contact contact){
   if (contact.email != null && contact.email.contains('@'))
   {
       contacts.Add(contact);
       contacts.Save();
   }
}

이것이 비즈니스 로직에 적합하고 재사용되지 않는 경우 여기에는 문제가 없습니다.

그러나 누군가 " '@'이 저장되는 이유는 무엇입니까?" 그리고 당신은 어떤 종류의 실제 유효성 검사를 추가하기로 결정한 다음 추출하십시오!

Presidents의 두 번째 이메일 계정 Pr3 $ sid3nt @ h0m3! @ mydomain.com을 설명 하고 RFC 2822를 지원하고 지원하기로 결정 했을 때 기뻤습니다 .

가독성 :

// If there is an email property and it contains an @ sign then process
if (contact.email != null && contact.email.contains('@'))

코드가 명확하면 여기에 의견이 필요하지 않습니다. 실제로, 코드가 가장 많은 시간을 하고있는 이유를 설명하기 위해 주석이 필요하지는 않지만, 왜 그렇게하는지에 대한 설명이 필요 합니다.

// The UI passes '@' by default, the DBA's made this column non-nullable but 
// marketing is currently more concerned with other fields and '@' default is OK
if (contact.email != null && contact.email.contains('@'))

if 문 위의 의견이나 작은 방법 내부의 의견이 나에게인지, pedantic. 다른 방법으로 유용한 주석과 유용한 반대의 반대 의견을 주장 할 수도 있습니다. 이제 다른 방법으로 이동하여 방법과 이유 를 확인 해야하기 때문입니다.

요약하면 :이 것들을 측정하지 마십시오. 텍스트가 작성된 원칙 (DRY, SOLID, KISS)에 중점을 둡니다.

// A valid class that does nothing
public class Nothing 
{

}

Clean Code 는 훌륭한 책이자 읽을 가치가 있지만 그러한 문제에 대한 최종 권한은 아닙니다.

코드를 논리적 함수로 나누는 것이 일반적으로 좋은 생각이지만 Martin이하는 정도까지는 프로그래머가 거의 없습니다. 어느 시점에서 모든 것을 함수로 바꾸는 것에서 수익을 감소시키고 모든 코드가 작을 때 따르기가 어려울 수 있습니다 조각.

완전히 새로운 기능을 만들 가치가 없을 때 한 가지 옵션은 중간 변수를 사용하는 것입니다.

boolean isEmailValid = (contact.email != null && contact.emails.contains('@');

if (isEmailValid) {
...

이를 통해 파일을 많이 탐색하지 않고도 코드를 쉽게 따라갈 수 있습니다.

또 다른 문제는 현재 Clean Code 가 책으로 오래 되었다는 것 입니다. 많은 소프트웨어 엔지니어링이 기능적 프로그래밍 방향으로 이동 한 반면, Martin은 사물에 상태를 추가하고 객체를 생성하는 방식을 벗어났습니다. 그가 오늘 저술을 썼다면 다른 책을 썼을 것 같습니다.

"이메일이 유효합니다"라는 조건이 현재 유효하지 않은 이메일 주소 " @"를 수락한다는 사실을 고려하면 EmailValidator 클래스를 추상화해야 할 모든 이유가 있다고 생각합니다. 더 좋은 방법은 잘 테스트 된 라이브러리를 사용하여 이메일 주소를 확인하는 것입니다.

메트릭으로 작성된 코드 줄은 의미가 없습니다. 소프트웨어 엔지니어링에서 중요한 질문은 다음과 같습니다.

• 코드가 너무 많습니까?
• 코드가 너무 적습니까?

중요한 질문은 다음과 같습니다.

• 응용 프로그램 전체가 올바르게 설계 되었습니까?
• 코드가 올바르게 구현 되었습니까?
• 코드를 유지 관리 할 수 ​​있습니까?
• 코드를 테스트 할 수 있습니까?
• 코드가 적절하게 테스트 되었습니까?

Code Golf 이외의 목적으로 코드를 작성할 때 LoC에 대한 생각을 한 적이 없습니다. 나는 "이 글을 더 간결하게 작성할 수 있을까?"라고 스스로에게 물었지만, 단순히 길이가 아니라 가독성, 유지 보수성 및 효율성을 목적으로합니다.

물론, 유틸리티 메소드 대신 긴 부울 연산 체인을 사용할 수는 있지만 그래야합니까?

귀하의 질문은 실제로 필자가 작성한 일부 부울 체인에 대해 다시 생각하게하고 아마도 하나 이상의 유틸리티 메소드를 작성해야했을 것입니다.

한 수준에서, 그들은 맞습니다-적은 코드가 좋습니다. 또 다른 대답은 Gate를 인용 한 것입니다.

"디버깅이 소프트웨어 버그를 제거하는 프로세스 인 경우 프로그래밍은 버그를 처리하는 프로세스 여야합니다."– Edsger Dijkstra

디버깅 할 때 초보자는 올바른 코드를 삽입합니다. 전문가들은 결함이있는 코드를 제거합니다.”– Richard Pattis

가장 저렴하고 빠르며 안정적인 구성 요소는없는 구성 요소입니다. -고든 벨

요컨대, 코드가 적을수록 오류가 줄어 듭니다. 필요하지 않은 경우 잘라내십시오.
지나치게 복잡한 코드가 있으면 실제 기능 요소가 모두 남을 때까지 단순화하십시오.

여기서 중요한 것은 이것들은 모두 기능을 나타내며 최소한의 기능 만 필요하다는 것입니다. 그것이 어떻게 표현 되는지 에 대해서는 아무 것도 말하지 않습니다 .

깨끗한 코드를 사용하여 수행하는 작업은 위와 반대되지 않습니다. LOC에 추가하고 있지만 사용하지 않는 기능은 추가하지 않았습니다.

최종 목표는 읽을 수있는 코드는 있지만 불필요한 추가 요소는없는 것입니다. 두 원칙은 서로 상충되지 않아야합니다.

은유는 자동차를 만드는 것일 것입니다. 코드의 기능적인 부분은 섀시, 엔진, 바퀴입니다. 이를 분해하는 방법은 서스펜션, 파워 스티어링 등과 비슷하므로 다루기가 더 쉽습니다. 작업을 수행하는 동안 문제가 발생할 가능성을 최소화하기 위해 가능한 한 간단하게 정비공을 원하지만 좌석이 좋지 않은 것은 아닙니다.

기존 답변에는 많은 지혜가 있지만 언어라는 한 가지 요소를 더 추가하고 싶습니다 .

일부 언어는 다른 언어보다 더 많은 코드를 사용하여 동일한 효과를 얻습니다. 특히, Java (문제의 언어라고 생각되는)는 매우 잘 알려져 있고 일반적으로 매우 견고하고 명확하고 간단하지만 일부 최신 언어는 훨씬 간결하고 표현력이 있습니다.

예를 들어, Java에서는 각각 게터와 세터 및 하나 이상의 생성자를 가진 세 가지 속성을 가진 새 클래스를 작성하는 데 50 줄을 쉽게 취할 수 있지만 Kotlin * 또는 Scala의 한 줄에서 정확히 같은 것을 달성 할 수 있습니다. (심지어 더 큰 절약 당신은 또한 적절한 원한다면 equals(), hashCode()및 toString()방법을.)

결과적으로 Java에서 추가 작업을 수행하면 실제로 맞지 않는 일반 객체를 재사용하거나 기존 객체에 속성을 압착하거나 여러 가지 '베어'속성을 개별적으로 전달할 가능성이 높아집니다. 간결하고 표현적인 언어로 더 나은 코드를 작성할 가능성이 높습니다.

(이것은 코드의 '표면적'복잡성과 코드가 구현하는 아이디어 / 모델 / 프로세스의 복잡성 간의 차이점을 강조합니다. .)

따라서 올바른 일을하는 '비용'은 언어에 달려 있습니다. 아마도 좋은 언어의 표시는 당신이 일을 잘하는 것과 간단하게하는 것 중에서 선택 하지 못하게 하는 것일 수 있습니다!

(* 이것은 실제로 플러그의 장소는 아니지만 Kotlin은 IMHO의 가치가 있습니다.)

Contact현재 수업을 진행 하고 있다고 가정 해 봅시다 . 이메일 주소 확인을 위해 다른 방법을 작성하고 있다는 사실은 수업 Contact에서 단일 책임을 처리하지 않는다는 증거입니다 .

또한 전자 메일 책임을 처리하는 것이 이상적이며 자체 클래스이어야합니다.

코드가 융합되어 Contact있고 Email클래스 라는 전자 증거는 이메일 유효성 검사 코드를 쉽게 테스트 할 수 없다는 것입니다. 올바른 값을 가진 큰 방법으로 이메일 유효성 검사 코드에 도달하려면 많은 조작이 필요합니다. 아래의 방법을 참조하십시오.

private void LargeMethod() {
    //A lot of code which modifies a lot of values. You do all sorts of tricks here.
    //Code.
    //Code..
    //Code...

    //Email validation code becoming very difficult to test as it will be difficult to ensure 
    //that you have the right data till you reach here in the method
    ValidateEmail();

    //Another whole lot of code that modifies all sorts of values.
    //Extra work to preserve the result of ValidateEmail() for your asserts later.
}

반면, 이메일 유효성 검사를위한 메소드가있는 별도의 Email 클래스가있는 경우 유효성 검사 코드를 단위로 테스트하려면 Email.Validation()테스트 데이터 를 한 번만 호출하면 됩니다.

_{보너스 내용 : MFeather 는 테스트 가능성과 우수한 디자인의 깊은 시너지에 대해 이야기 합니다.}

LOC 감소는 결함 감소와 상관 관계 가있는 것으로 밝혀졌습니다 . LOC를 줄일 때마다 결함의 가능성이 줄어든다고 가정하면 상관 관계가 원인과 같다고 믿는 함정에 빠지게됩니다. 감소 된 LOC는 좋은 개발 관행 의 결과 이며 코드를 좋게 만드는 것이 아닙니다.

내 경험상, 코드가 적 으면서 (매크로 레벨에서) 문제를 해결할 수있는 사람들은 같은 일을하기 위해 더 많은 코드를 쓰는 사람들보다 숙련 된 경향이 있습니다. 이러한 숙련 된 개발자가 코드 라인을 줄이기 위해하는 일은 일반적인 문제를 해결하기 위해 추상화 및 재사용 가능한 솔루션을 사용 / 만드는 것입니다. 그들은 코드 줄을 세고 여기 또는 줄을 줄 수 있는지 고민하는 데 시간을 소비하지 않습니다. 종종 그들이 작성하는 코드가 필요한 것보다 더 장황한 경우가 많습니다.

예를 들어 보겠습니다. 나는 시대에 관한 논리와 그것들이 어떻게 겹쳐 지는지, 그것들이 인접하는지, 그리고 그들 사이에 어떤 간격이 있는지를 다루어야했습니다. 이 문제에 대해 처음 작업을 시작했을 때 모든 곳에서 계산을 수행하는 코드 블록이 생겼습니다. 결국 겹침, 보완 등을 계산하는 기간과 작업을 나타내는 클래스를 만들었습니다. 이렇게하면 큰 코드가 즉시 제거되어 몇 가지 메서드 호출로 바뀌 었습니다. 그러나 그 수업 자체는 전혀 쓰이지 않았습니다.

분명히 말하면 : 여기 또는 더 간결하게 코드 줄을 잘라서 LOC를 줄이려고하면 잘못하고 있습니다. 먹는 야채의 양을 줄여 체중을 줄이려고하는 것과 같습니다. 재사용 및 추상화를 통해 LOC를 이해하고 유지 보수하며 디버그 및 축소하기 쉬운 코드를 작성하십시오.

유효한 트레이드 오프를 식별했습니다

실제로 여기에는 절충점이 있으며 전체적으로 추상화에 내재되어 있습니다. 누구나 이름을 지정하고 분리하기 위해 N 줄의 코드를 자체 함수로 가져 오려고 할 때마다 호출 사이트를 쉽게 읽을 수 있습니다 (해당 이름의 모든 세부 사항이 아닌 이름을 참조하여). 더 복잡합니다 (이제 코드베이스의 서로 다른 두 부분에 얽혀 있음을 의미합니다). "Easy"는 "hard"의 반대이지만 "complex"의 반대 인 "simple"과 동의어가 아닙니다. 이 둘은 반대가 아니며 추상화는 항상 어떤 형태 또는 다른 형태를 쉽게 삽입하기 위해 복잡성을 증가시킵니다.

비즈니스 요구 사항의 일부 변경으로 인해 추상화가 누출되기 시작하면 복잡성이 추가 된 것을 직접 확인할 수 있습니다. 예를 들어 추상 코드가 일부 트리를 통과하고 실제로 정보를 수집하고 실행하려는 경우와 같이 사전 추출 된 코드 중간에 새로운 논리가 가장 자연스럽게 나타날 수 있습니다. 나무를 횡단. 한편이 코드를 추상화하면 다른 호출 사이트가있을 수 있으며 메소드 중간에 필요한 논리를 추가하면 다른 호출 사이트가 중단 될 수 있습니다. 코드 줄을 바꿀 때마다 해당 코드 줄의 즉각적인 맥락 만 살펴 봐야합니다. 메소드를 변경할 때 전체 소스 코드를 Cmd-F로 작성하여 해당 메소드의 계약 변경으로 인해 깨질 수있는 것을 찾아야합니다.

이 경우 탐욕 알고리즘이 실패 할 수 있습니다.

복잡성은 어떤 의미에서 코드를 만든 적은 보다는 읽기를 더. 이전 작업에서는 여러 계층으로 매우 신중하고 정확하게 구조화 된 HTTP API를 다루었습니다. 모든 엔드 포인트는 수신 메시지의 형태를 확인한 다음이를 "business-logic-layer"관리자에게 전달하는 컨트롤러에 의해 지정됩니다. 그런 다음 일부 "데이터 계층"을 요청하여 일부 "데이터 액세스 개체"계층에 대한 여러 쿼리를 담당했으며 실제로는 귀하의 질문에 응답하는 여러 SQL 대리인을 생성했습니다. 내가 말할 수있는 첫 번째 것은 코드의 90 %가 복사 및 붙여 넣기 상용구입니다. 따라서 많은 경우에있어서, "이 관리자는 요청을 해당 데이터 액세스 객체로 전달하기 때문에"주어진 코드의 통과를 매우 "쉽게"읽을 수있었습니다.많은 컨텍스트 스위칭의 파일을 발견하고이 기타에 ''이 다른 계층에서 다음이라고합니다 X를 '당신이 결코이가 X라고된다,이 계층에서 X라고 ", 추적되어 있지 않은 것을 정보를 추적하려고 다른 층. "

중단했을 때이 간단한 CRUD API는 페이지 당 30 줄로 인쇄하면 선반에 10 ~ 5 백 페이지의 교과서가 필요합니다. 반복적 인 백과 사전이었습니다. 암호. 본질적인 복잡성 측면에서, 나는 본질적인 복잡성에 대한 교과서의 절반이 거기에 있다고 확신하지 못한다. 이를 처리 할 데이터베이스 다이어그램은 5-6 개에 불과했습니다. 그것에 약간의 변경을하는 것은 거대한 사업이었다, 그것은 거대한 사업 이었다는 것을 배우고, 새로운 기능을 추가하는 것은 우리가 실제로 새로운 기능을 추가하는 데 사용할 상용구 템플릿 파일을 가지고있을 정도로 고통스러워졌다.

그래서 나는 각 부분을 읽기 쉽고 명확하게 만드는 것이 어떻게 전체를 읽을 수없고 명백하지 않게 만들 수 있는지 직접 보았습니다. 이는 욕심 많은 알고리즘이 실패 할 수 있음을 의미합니다 . 욕심 많은 알고리즘을 알고 있습니까? "국지적으로 상황을 개선하기 위해 어떤 조치를 취하 든, 전 세계적으로 개선 된 상황에서 자신을 발견 할 것입니다." 종종 아름다운 첫 시도이지만 복잡한 상황에서는 놓칠 수도 있습니다. 예를 들어 제조 과정에서 복잡한 제조 공정의 모든 특정 단계의 효율성을 높이려고 시도 할 수 있습니다. 이것은 종종 시스템의 글로벌 효율성을 파괴 할 수 있습니다.

모범 사례 : DRY 및 길이를 사용하여 전화 걸기

(참고 :이 섹션 제목은 다소 농담입니다. 나는 종종 누군가에게 "우리는 X가 최선의 방법으로 말해야 하기 때문에 X를해야 한다고 말합니다 " 라고 말하면 SQL 주입이나 암호 해싱과 같은 것에 대해 이야기하지 않는 시간의 90 %입니다 또는 무엇 이건 - 일방적 모범 사례 - 그리고 "때문에 우리가 X를해야하므로 문이 시간의 90 %에 번역 될 수 내가 그렇게 말 ."그들은 더 나은 일을 한 일부 사업에서 일부 블로그 기사가있을 수 있습니다처럼 X '가 아닌 X'로 표시되지만 일반적으로 귀하의 비즈니스가 해당 비즈니스와 유사하다는 보장은 없으며 일반적으로 X가 아닌 X '로 더 나은 작업을 수행 한 다른 비즈니스의 다른 기사도 있습니다. 따라서 제목도 가져 가지 마십시오. 진지하게.)

내가 추천하는 것은 Jack Diederich의 Stop Writing Classes (youtube.com) 라는 대화를 기반으로합니다 . 그는 그 대화에서 몇 가지 중요한 점을 지적합니다. 예를 들어, 클래스에 두 개의 공용 메소드가있을 때 클래스가 실제로 함수라는 것을 알 수 있습니다. 그중 하나는 생성자 / 초기화 기입니다. 그러나 어떤 경우에 그는 "Muffin" dict이 파이썬이 가지고 있는 내장 유형 의 서브 클래스 인 자체 클래스 "MuffinHash"를 선언함에 따라 대화를 위해 문자열 대체 된 가상의 라이브러리에 대해 이야기하고 있습니다. 구현은 완전히 비어있었습니다. 누군가는 "나중에 파이썬 사전에 커스텀 기능을 추가해야 할 수도 있습니다. 지금 바로 추상화를 소개하겠습니다."

그의 반항적 인 대답은 간단하게 "필요하다면 나중에 언제든지 할 수있다"는 것이었다.

우리는 때때로 우리가 지금보다 더 나쁜 프로그래머가되는 것처럼 가장하기도하므로 미래에 우리를 행복하게 해줄 작은 것을 삽입하고 싶을 수도 있습니다. 우리는 미래의 요구를 기대합니다. "트래픽이 생각보다 100 배 더 크다면, 그 접근 방식은 확장되지 않을 것이므로,이 더 어려운 접근 방식에 사전 투자를해야합니다." 매우 의심 스럽다.

우리가 그 조언을 진지하게 받아들이면“나중에”언제 왔는지 식별해야합니다. 아마도 가장 분명한 것은 스타일상의 이유로 물건의 길이에 대한 상한을 설정하는 것입니다. 그리고 남은 최선의 조언은 SOLID 원리에 구멍을 뚫기 위해 선 길이에 대한 이러한 휴리스틱을 사용하여 DRY를 사용하는 것입니다 (반복하지 마십시오). 텍스트의 "페이지"인 30 줄의 휴리스틱과 산문의 유추를 바탕으로,

1. 복사 / 붙여 넣기를 원할 때 체크를 함수 / 방법으로 리 팩터하십시오. 복사하여 붙여 넣어야 할 유효한 이유가 있지만 항상 더러워 야합니다. 실제 저자는 주제를 강조하려고하지 않는 한, 내러티브 전체에서 큰 문장을 50 번 다시 읽도록 만들지 않습니다.
2. 함수 / 메소드는 이상적으로 "단락"이어야합니다. 대부분의 함수는 페이지 길이의 절반 또는 1-15 줄의 코드 여야하며, 함수의 10 % 만 페이지와 1/2, 45 줄 이상의 범위에 있어야합니다. 120 줄 이상의 코드를 만들고 나면 그 부분을 여러 부분으로 나눌 필요가 있습니다.
3. 파일은 이상적으로 "챕터"여야합니다. 대부분의 파일은 12 페이지 이하이어야하므로 360 줄의 코드와 주석입니다. 파일의 10 %만이 길이가 50 페이지 또는 1500 줄의 코드와 주석 범위에 있어야합니다.
4. 이상적으로는 대부분의 코드가 함수의 기준선 또는 한 수준 깊이로 들여 쓰기되어야합니다. Linux 소스 트리에 대한 일부 휴리스틱을 기반으로 종교적 인 경우 기준선 내에서 코드의 10 % 만 2 레벨 이상 들여 쓰기해야하며 3 레벨 이상 들여 쓰기는 5 % 미만이어야합니다. 이것은 특히 큰 시도 / 캐치에서의 오류 처리와 같은 다른 문제를 "포장"해야하는 것은 실제 논리에서 벗어나야한다는 것을 의미합니다.

앞에서 언급했듯이 현재 Linux 소스 트리에 대해 이러한 통계를 테스트하여 대략적인 백분율을 찾았지만 문학적 유추에서 근거가 있습니다.