계산을 나타내는 긴 코드를 더 쉽게 읽을 수 있습니까?

긴 메소드는 일반적으로 나쁜 것으로 간주되지만 내 코드에는 이해하기 어려운 긴 메소드 (50 줄 이상)가 있습니다. 내부의 단일 문 길이가 이미 50 줄 이상이고 읽기 어려운 단일 문은 ORM을 사용하여 데이터베이스 쿼리를 작성하여 작업이 수행되는 특정 작업을 수행하기 때문에 이러한 메서드를 읽기가 쉽지 않습니다. 메소드 이름에 명확하게 표시됩니다. 명령문이 여러 열을 결합하고 여러 위치를 적용하고 여러 개의 고유 한 열을 선택하여 필요한 문서화 된 출력 형식을 작성하기 때문에 명령문이 너무 긴 이유.

읽기 어려운 코드는 잘못된 코드로 간주됩니까? 마찬가지로, 복잡한 알고리즘에 대한 코드를 작성하여 읽기 어려운 코드로 명확하게 명명 된 메서드로 래핑하면 해당 코드가 잘못된 코드입니까?

당신은 썼다

읽기 어려운 코드는 잘못된 코드로 간주됩니까

따라서 읽기 어려운 코드이고, 읽기 어려운 경우 유지 관리 및 진화 가 어렵다는 점에 동의합니다. 따라서 코드를 사용자가 직접 측정 한 "나쁜"것으로 생각합니다. 그러나 때로는 50 행 SQL 문과 같은 것을 개선하는 방법이 명확하지 않은 경우가 있습니다. 쉬운 "추출 방법"리팩토링이 작동하지 않으며 코드를 더 읽기 쉽게 시작할 수있는 힌트가 없을 것입니다. 이러한 경우에도 다음 중 하나 또는 모두를 시도 할 수 있습니다

• 코드를 정리할 때 자신보다 경험이 많은 사람에게 코드를 보여주십시오. 조직에 누군가가 없으면 요청할 수 있습니다. codereview.stackexchange

• 특정 문제에 대해 Google에 시도하십시오. 예를 들어 "clean up long sql statement"와 같은 것이 좋은 시작일 수 있습니다. 당신은 그 주제에 관해 얼마나 많은 기사를 찾게되는지 놀라게 될 것입니다. 당신의 경우에 대한 뇌파의 레시피를 찾을 수 없더라도, 새로운 아이디어를 얻을 수있을 것입니다

• 할 수없는 일에 대한 정당성을 요구하는 대신 적절한 줄 바꿈 추가, 들여 쓰기, 설명 주석 추가, 일부 변수 개선과 같이 코드를 약간 정리하기 위해 할 수 있는 일에 집중하십시오. 이름. 이 과정에서 코드의 세부 사항을 다시 읽도록 강요하지는 않지만 코드를 더 작은 단위로 리팩터링하는 방법을 찾습니다.

• 연습, 연습, 연습. "청결한 코딩"은 하루에 배우는 것이 아니라 더 많은 경험으로 쉽게 얻을 수 있습니다. 오늘 문제에 대한 해결책을 찾지 못할 수도 있지만 몇 개월 후에 코드로 돌아 오면 다르게 보일 것입니다.

읽기 어려운 것은 나쁘지 않습니다-불필요하게 읽기 어려운 것은 나쁩니다.

어려운 일이 있습니다 . 이 경우 문제를 완전히 이해하고 코드를 작성하고 다음 개발자가 할 수 있도록 최대한 주석을 달아야합니다.

그러나 어떤 것은 당신이 그들을 어렵게 만들었 기 때문에 어려울뿐입니다. 문제를 단순화하고 쉽게 만들 수 있으면 단순화하십시오. 이해하기 어렵지만 하위 문제로 합리적으로 분할 할 수있는 경우 하위 문제로 분할하여 단순화합니다.

ORM에서 보고서를 작성 하시겠습니까? 진심이야? SQL을 배우십시오. 절차 적 언어는 이런 종류의 일에 끔찍합니다.

SQL은 복잡한 조인 및 선택을 처리하도록 훨씬 더 나은 언어입니다. 그리고 SQL을 아름답게 보이게 할 수 없더라도 다이어그램에서 데이터베이스 개체를 끌어다 놓을 수있는 모든 종류의 시각화 도구가 있으며 SQL이 자동으로 생성됩니다. 말할 것도없이 쿼리를 조정 및 최적화하고, 쿼리 계획을보고, 추가 인덱싱 옵션을 제안하는 플랫폼을 확보 할 수 있습니다. 더 유연합니다.

나는 여기에있는 사람들이 나와 동의하지 않을 것이라고 확신하지만 ORM은 복잡한보고 목적에 적합하지 않습니다. 가능하다면 나는 그것에서 멀어지고 구조적 쿼리 언어로 이동하는 것을 고려할 것 입니다.

일반적으로 코드를 읽기 어려운 것은 어디에서나 나쁜 생각입니다. 유일한 관리자 인 경우에도 몇 년 또는 몇 주 후에 몇 번의 코드로 돌아와서 머리를 돌리기가 어려웠습니다.

단일 쿼리에서 많은 작업을 수행해야하는 경우 주석이 포함 된 행으로 분할하십시오.

query(join(map(condition1, condition2), blah, blah, something(bah, blah, blah))) 

된다 :

// Why are we doing such an awful single query rather than a sequence of selects?
query( // Description of query
  join( // Why are you doing a join here
    map( // Why a map
      condition1, // What is this
      condition2  // And this
   ), // End Map
   blah, // What, Why?
   blah, // What, Why?
   something( // What does this do?
      bah, // What, Why?
      blah, // What, Why?
      blah // What, Why?
      ) // End Something
   ) // End Join
) // End Query

@DocBrown의 탁월한 답변 외에도 항상 "좋은"코드를 작성하는 사람이 없다는 것을 인식 할 가치가 있다고 생각합니다. 코딩은 절충점을 만들고 있으며, 때로는 자신이 원하는 것보다 조금 덜 깨끗한 것을 작성했다가 나중에 다시 오는 것을 받아들이는 것이 좋습니다. 리팩토링은 시간이 지남에 따라 코드를 개선하는 프로세스입니다. 제 경험상 이것이 "처음에 제대로 얻지"않고 좋은 코드 기반을 만드는 것입니다.

또한 개별 방법 / 코드 줄 수준이 아니라 응용 프로그램 수준에서 코드를 평가합니다. 따라서 복잡한 방법을 사용하지만 이름이 명확하게 지정되어 있으면 해당 방법이 응집력이있는 한 "나쁜"코드가 있다고 생각하지 않습니다.

이름 지정은 코드를 이해하기 쉽게 만드는 데 가장 큰 무기입니다. 메소드에 이름을 지정하면 코드를 읽는 사람들이 필요한 경우 본문을 건너 뛸 수 있습니다. 독자가 대 입문을 읽지 않고도 자신이 나타내는 것을 볼 수있는 방식으로 변수 등의 이름을 지정하십시오.

다음은 메서드가 실제로 한 가지 작업 만 수행하도록하는 것입니다. 부작용으로 인해 코드를 이해하기 어렵습니다. 따라서 메소드가 출력 형식의 데이터를 리턴하는 경우 데이터베이스의 상태를 "인쇄"또는 기타로 업데이트하지 않아야합니다.

레이어링 / 컴포넌트 화는 다음으로 할 수있는 일입니다. ORM 결과를 생성하는 복잡한 메소드가 여러 개있는 경우이를 묶어서 코드 리더가 모두 같은 방식으로 작동하고 부작용이없는 것으로 가정 할 수 있습니다.