깨끗한 코드 작성 (제2부분)

본고에서 나는 포맷, 명명, 코드 삽입을 피하는 세 가지 간단한 실천을 개술했다.이 모든 것은 코드의 가독성을 높이기 위해서다.
2부에서는 팀을 좀 더 깊이 소개하고 싶다.내가 그룹을 나누자고 말했을 때, 나는 사실상 봉인된 대상 프로그래밍 모델에 대해 이야기하고 있었다.우리가 코드를 함수나 클래스로 나누는지 여부는 일반적으로 중요하지 않다.중요한 것은 우리가 코드의 가독성을 향상시켰는가 하는 것이다.
우리의 변화를 평가하기 위해서 우리는 반드시 물어야 한다.

Did we improve readability?

물론 주관적이긴 하지만, 너는 스스로 객관을 유지하도록 강요할 것이다.지난 2년 동안 나는 줄곧 대조 프로그래밍을 진행해 왔다.개발자들은 기본적인 가독성에 합의하는 경향이 있다.우리는 가장자리에 차이가 존재한다.이런 미세한 차이는 아주 좋은 토론을 불러일으킬 수도 있다.
그룹을 나누는 내용은 통상적으로 식별하기 쉽다.우리는 모두 우리가 싫어하는 코드를 지적할 수 있다.우리는 코드에 대해 어떻게 그룹을 나누는지는 결코 중요하지 않다고 말했다.나머지 문제는 코드를 언제 그룹으로 나누느냐 하는 것이다.나는 언제 그룹을 나누어 코드를 정리합니까?
코드에 대해 그룹을 나누는 세 가지 동기를 봅시다.

소통을 개선하다
추가 상하문이 필요한 코드는 그룹을 나누기에 적합하다.나는 나의 코드를 더 좋아한다. 내가 업무 논리를 이해하도록 요구하는 방식으로 작성한 것이 아니다.아무리 간단하게 이루어져도 나는 영원히 이해하지 못할 것이다.이 코드들을 그룹으로 나누는 것을 통해 우리는 추가 추상층을 제공했다.이것은 시스템 계승의 복잡성으로부터 우리 자신과 미래 개발자를 보호하는 방법이다.
이전 코드 예제를 고려하십시오.

function canView($scope, $owner_id)
{
    if ($scope === 'public') {
        return true;
    }

    if (Auth::user()->hasRole('admin')) {
        return true;
    }

    if ($scope === 'private' && Auth::user()->id === $owner_id) {
        return true;
    }

    return false;
}

비록 논리는 매우 간단하지만, 우리는 그것을 상하문 이름의 조수 방법으로 추출하여 통신을 개선한다.

function canView($scope, $owner_id)
{
    if ($scope === 'public') {
        return true;
    }

    if (isAdmin()) {
        return true;
    }

    if ($scope === 'private' && isOwner($owner_id)) {
        return true;
    }

    return false;
}

isAdmin()와 isOwner 등 방법으로 업무 논리를 중계하여 이해하기 쉽게 한다.일단 이해하면 코드 라이브러리의 다른 분야에 쉽게 적용할 수 있다.마지막으로 우리는 소통을 개선했을 뿐만 아니라 개발자에게 코드도 전수했다.
지적해야 할 것은 내가 모든 코드를 그룹으로 나누지 않았다는 것이다.각 조의 사람들은 모두 심리적 대가를 치러야 한다.모든 것은 원가를 보충하기 위해 충분한 가치를 제공해야 한다.이 예에서 나는 논리를 hasScope() 함수에 나누지 않았다. 왜냐하면 통신을 개선하지 않았을 뿐만 아니라, 방법 서명도 표현식과 같이 지루하기 때문이다.

결합 데이터
프로그래밍의 또 다른 원칙은 저결합이다.결합이 괜찮다.사실 데이터나 코드가 진정으로 함께 속할 때 매우 좋다.우리는 논리적 연결이나 유사한 변화율을 발견함으로써 결합 구역을 식별할 수 있다.
다음 코드 예제를 고려하십시오.

function plot($x, $y, $z)
{
    // ...
}

function transfer($amount, $currency)
{
    // ...
}

function substring($string, $start, $length)
{
    // ...
}

여기에 함수 서명만 제공합니다. 왜냐하면 나는 파라미터를 중점적으로 소개하고 싶기 때문입니다.너는 아마도 곧 팀을 나누는 기회를 보지 못할 것이다.걱정하지 마세요. 우리 모두primitive obsession의 고통이 있기 때문입니다.원어를 사용한 것은 틀림없다.그러나 우리가 그것들만 사용하는 경향은 우리가 이 데이터를 하나의 대상으로 나누는 것을 막을 수 있다.

function plot(Point $point)
{
    // ...
}

function transfer(Money $money)
{
    // ...
}

function substring($string, Range $range)
{
    // ...
}

데이터를 한 대상에 봉인함으로써 우리는 결합을 개선할 뿐만 아니라 추가 논리에 위치를 제공한다.우리는 이 데이터와 관련된 모든 내연 논리를 대상으로 이동할 수 있다.마틴 포러Range object의 책을 1분 동안 읽고 더 깊은 예를 이해하자.

조직 코드
마지막으로 가장 중요하지 않은 것은 조직이다.유사한 코드를 자신의 함수나 클래스로 나누는 것을 두려워하지 마라.그것의 분량만 있다면 코드 라이브러리를 개선할 수 있다.
이런 것들을 발견하는 것이 데이터 결합을 발견하는 것보다 더 고급스럽다.여기서 우리는 더욱 많은 시각적 방법을 채택한다.만약 어떤 것들이 현지의 미학과 맞지 않는 것 같다면, 그것은 다른 곳에 속할 수도 있다.
다음 코드 예제를 고려하십시오.

namespace App\Models;

class User
{
    public function find($id) {}

    public function create() {}

    public function save() {}

    public function destroy() {}

    public function displayName() {}

    public function displaySignature() {}

    public function displaySalutation() {}

    public function createBadge() {}

    public function printBadge() {}
}

우리는 모형이 하나 있다.일반적으로 모델에는 CRUD 메서드(생성, 읽기, 업데이트, 삭제)가 포함됩니다.모델에 다른 방법이 포함되어 있는 것은 충분히 받아들일 수 있지만, 우리는 모델에 있는 다른 방법 간의 관계를 주의할 수 있다.
이름만으로도 우리는 표시와 다른 휘장 방법과 관련된 방법을 발견할 수 있다.우리는 다른 곳에서 이 코드들을 조직할 수 있다.이 경우 디스플레이 메서드를 Presenter 클래스로 추출할 수 있습니다.프린터 클래스나 자신의 Badge 대상에badge 방법을 추가합니다.
이 동기들을 시험해 봐라.어떤 것은 당신의 코드 라이브러리에 유용할 수도 있고, 어떤 것은 그렇지 않을 수도 있습니다. 우리가 코드의 가독성을 향상시켰는지의 답은 개발자와 프로젝트에 따라 다를 수 있습니다.근데 자꾸 물어보니까...
더 깨끗한 코드를 보고 싶으세요?매주 알림을 정리하거나, 우리pair up와 함께 깨끗한 코드를 작성합시다.