소프트웨어 프로젝트에서 우발적 인 복잡성을 관리하는 방법

Murray Gell-Mann에게 Richard Feynman이 어떻게 그렇게 많은 어려운 문제를 해결할 수 있는지 물었을 때 Gell-Mann은 Feynman이 알고리즘을 가지고 있다고 응답했습니다.

1. 문제를 기록하십시오.
2. 진짜 열심히 생각하십시오.
3. 솔루션을 작성하십시오.

Gell-Mann은 Feynman이 다른 종류의 문제 해결사이며 자신의 방법을 연구하여 얻을 수있는 통찰력이 없다고 설명하려고했습니다. 중형 / 대형 소프트웨어 프로젝트에서 복잡성을 관리하는 것과 같은 방식으로 생각합니다. 선량한 사람들은 본질적으로 능숙하며 어떻게 든 다양한 추상화를 계층화하고 쌓아서 불필요한 횡목을 일으키지 않고 모든 것을 관리 할 수 ​​있습니다.

Feynman 알고리즘은 우발적 인 복잡성을 관리하는 유일한 방법입니까, 아니면 소프트웨어 엔지니어가 우발적 인 복잡성을 길들이기 위해 지속적으로 적용 할 수있는 실제 방법이 있습니까?

좋은 움직임이 보이면 더 좋은 움직임을 찾으십시오.
—27 세의 세계 체스 챔피언

내 경험상 우발적 인 복잡성의 가장 큰 원인은 프로그래머가 작동하기 때문에 첫 번째 초안을 고수하는 것입니다. 이것은 영어 작문 수업에서 배울 수있는 것입니다. 그들은 교사의 피드백을 통합하여 과제물에 몇 가지 초안을 겪을 시간을 갖습니다. 어떤 이유로 프로그래밍 클래스는 그렇지 않습니다.

차선책 코드를 인식하고, 표현하고, 고칠 수있는 구체적이고 객관적인 방법으로 가득 찬 책이 있습니다 : Clean Code , Legacy Code와 효과적으로 작업하기 등. 많은 프로그래머들이 이러한 기술에 익숙하지만 항상 적용하는 데 시간이 걸리지는 않습니다. 그들은 우발적 인 복잡성을 완벽하게 줄일 수 있으며, 시도 하는 습관을 갖지 않았습니다 .

문제의 일부는 다른 사람들의 코드가 초기 단계에서 동료 검토를 거치지 않는 한 종종 다른 사람들의 코드의 중간 복잡성을 보지 못한다는 것입니다. 깨끗한 코드는 실제로 여러 초안이 포함되어 있으면 작성하기 쉬운 것처럼 보입니다. 당신은 처음에 머리에 오는 가장 좋은 방법을 쓰고, 그것이 도입하는 불필요한 복잡성을 발견 한 다음, "더 나은 움직임을 찾고"리팩터링하여 그러한 복잡성을 제거합니다. 그런 다음 찾을 수 없을 때까지 "더 나은 움직임 찾기"를 계속하십시오.

그러나 코드가 변경되기 전에는 코드를 검토하지 않으므로 외부 적으로는 Feynman과 같은 프로세스 일 수 있습니다. 당신은 그렇게 한 덩어리를 모두 할 수 없다고 생각하는 경향이 있으므로, 당신은 노력하지 않아도되지만 진실은 당신이 일반적으로 읽은 아름답고 단순한 코드의 저자는 보통 한 덩어리로 그것을 쓸 수는 없다는 것입니다 그런 식으로 또는 가능한 경우 비슷한 코드를 여러 번 작성해 본 경험이 있기 때문에 중간 단계없이 패턴을 볼 수 있습니다. 어느 쪽이든 초안을 피할 수 없습니다.

"소프트웨어 아키텍처 기술을 가르 칠 수 없습니다"는 광범위한 오류입니다.

많은 사람들이 왜 그것을 믿는지 쉽게 이해할 수 있습니다. 그럼에도 불구하고 잘못되었습니다. 이 기술은 다른 소프트웨어 기술 (예 : 루프 이해, 포인터 다루기 등)보다 실습 집약적입니다.

나는 훌륭한 음악 가나 대중 연설자가되는 것과 같은 방식으로 큰 시스템을 구성하는 것이 반복적 인 연습과 경험으로부터의 학습에 영향을 받기 쉽다고 확신합니다. 대부분의 개업의의 도달.

복잡성을 다루는 것은 몇 번 시도하고 실패함으로써 크게 얻는 기술입니다. 커뮤니티가 대규모 프로그래밍에 대해 발견 한 많은 일반 지침 (계층 사용, 머리를 where는 곳 어디에서나 중복 복제, 종교적으로 0 / 1 / 무한도 준수 ...)이 정확하고 필요한 것은 아닙니다. 그들이 실제로 큰 것을 프로그램 할 때까지 초보자. 실제로 몇 달 후에 문제를 일으킨 복제에 물렸을 때까지 그러한 원칙의 중요성을 '얻을'수는 없습니다.

Andy Hunt의 실용적인 사고 가이 문제를 해결합니다. 그것은 다양한 기술에 5 단계의 숙련도가있는 Dreyfus 모델을 말합니다. 초보자 (1 단계)는 무언가를 올바르게 수행하려면 정확한 지침이 필요합니다. 반대로 전문가 (5 단계)는 주어진 문제에 일반적인 패턴을 적용 할 수 있습니다. 책을 인용하면서

전문가가 자신의 행동을 세부적인 수준으로 설명하기가 어려운 경우가 많습니다. 그들의 반응 중 상당수는 너무 잘 연습되어있어 의식적인 행동이됩니다. 그들의 광대 한 경험은 뇌의 비언어적, 의식적 영역에 의해 채굴되어 우리가 관찰하고 표현하기 어렵게 만듭니다.

전문가가 자신의 일을 할 때, 그것은 우리의 나머지 사람들에게 거의 마술처럼 보입니다. 질문에 대해. 물론 마술은 아니지만 전문가가 세상을 인식하는 방식, 문제 해결 방법, 사용하는 정신 모델 등은 모두 비전문가와는 크게 다릅니다.

우연히 복잡한 문제에 대해 다른 문제를보고 그 결과 피하는 일반적인 규칙을 적용 할 수 있습니다. 주어진 규칙 세트를 갖는 것만으로는이 문제를 피할 수 없습니다. 해당 규칙에 포함되지 않는 상황이 항상 있습니다. 우리는 문제를 예측하거나 솔루션을 식별 할 수있는 경험을 얻어야합니다. 경험은 가르 칠 수없는 것입니다. 끊임없는 노력, 실패 또는 성공과 실수로부터 배우는 것만으로 얻을 수 있습니다.

Workplace 의이 질문 은 관련이 있으며 IMHO는이 맥락에서 읽는 것이 흥미로울 것입니다.

설명하지는 않지만 "우발적 복잡성"은 "필수적"복잡성에 비해 문제의 고유하지 않은 복잡성으로 정의됩니다. "Taming"에 필요한 기술은 출발지에 따라 다릅니다. 다음은 대부분 불필요한 복잡성을 이미 얻은 시스템을 나타냅니다.

나는 다수의 대규모 다년간 프로젝트에서 경험 한 경험을 통해“우발적 인”구성 요소가“필수”측면을 능가했으며 그렇지 않은 프로젝트도있었습니다.

실제로, Feynman 알고리즘은 어느 정도 적용되지만,“진정하게 생각하라”는 것은 성문화 될 수없는 마법만을 의미한다는 의미는 아닙니다.

두 가지 접근 방식이 필요하다는 것을 알았습니다. 둘 다 가져 가십시오 – 대안이 아닙니다. 하나는 단편적인 문제를 해결하고 다른 하나는 주요 재 작업을 수행하는 것입니다. 확실히,“문제를 적어 라”. 코드 모듈, 상태 (냄새, 자동화 된 테스트 수준, 이해하는 직원 수), 전체 아키텍처 (문제가있는 경우에도 하나 있음) 등 시스템 감사 형식이 될 수 있습니다. ), 요구 사항 상태 등

"우발적 인"복잡성의 특성 때문에 해결해야 할 문제가 하나도 없습니다. 따라서 심사해야합니다. 시스템을 유지하고 개발을 진행할 수있는 능력면에서 어디가 아파요? 어쩌면 일부 코드는 실제로 냄새가 나지만 우선 순위가 높지 않으므로 기다릴 수 있습니다. 반면에 리팩토링에 소비 된 시간을 빠르게 반환하는 코드가있을 수 있습니다.

더 나은 아키텍처가 될 계획을 정의하고 새로운 작업이 해당 계획과 일치하는지 확인하십시오. 이는 점진적인 접근 방식입니다.

또한 문제의 비용을 설명하고이를 사용하여 리 팩터를 정당화하는 비즈니스 사례를 작성하십시오. 여기서 중요한 것은 잘 설계된 시스템이 훨씬 강력하고 테스트 가능하여 변경을 구현하는 데 훨씬 더 짧은 시간 (비용 및 일정)이있을 수 있다는 것입니다. 이는 실제 가치가 있습니다.

중대한 재 작업은 "실제로 생각하기"범주에서 이루어집니다. 제대로 이해해야합니다. 이곳은 "Feynman"(작은 것 중 일부는 괜찮을 것입니다)을 갖는 것이 크게 돈을 지불하는 곳입니다. 더 나은 아키텍처를 제공하지 않는 주요 재 작업은 재난이 될 수 있습니다. 전체 시스템 재 작성은 이것으로 유명합니다.

어떤 접근 방식이든 "우발적"과 "필수"를 구별하는 방법을 알고 있습니다. 즉, 시스템과 그 목적을 실제로 이해하는 훌륭한 건축가 (또는 건축가 팀)가 필요합니다.

모든 것을 말했듯이, 나에게 가장 중요한 것은 자동 테스트 입니다. 충분하면 시스템이 제어됩니다. 당신이하지 않으면. . .

" 모든 것이 가능한 한 간단해야하지만 더 단순해서는 안됩니다. "
— Albert Einstein

실수로 인한 복잡성을 처리하기위한 개인 알고리즘을 스케치하겠습니다.

1. 사용자 스토리 또는 사용 사례를 작성하십시오. 제품 소유자와 검토하십시오.
2. 기능이 없기 때문에 실패한 통합 테스트를 작성하십시오. 팀에 해당 사항이 있으면 QA 또는 수석 엔지니어에게 문의하십시오.
3. 통합 테스트를 통과 할 수있는 일부 클래스에 대한 단위 테스트를 작성하십시오.
4. 단위 테스트를 통과 한 클래스에 대한 최소 구현을 작성하십시오 .
5. 동료 개발자와의 단위 테스트 및 구현을 검토하십시오. 3 단계로 이동하십시오.

전체 디자인 마술은 3 단계에 있습니다. 이러한 클래스를 어떻게 설정합니까? 이것은 당신이 문제에 대한 해결책을 갖기 전에 문제에 대한 해결책을 가지고 있다고 어떻게 생각 하십니까?

놀랍게도, 당신은 단지 상상 솔루션 (전화에서 아벨과 서스에 의해 "소망 적 사고"문제 해결에 쓰기 사람들의 주요 권고 사항 중 하나가 될 것으로 보인다 컴퓨터 프로그램의 구조와 해석 폴리 -A의와 "뒤로 작업" 방법 해결 )

반면, 모든 사람이 동일한 " 상상적인 솔루션에 대한 취향 "을 갖는 것은 아닙니다. 여러분 만이 우아하게 생각하는 솔루션이 있으며 더 많은 사람들이 이해할 수있는 솔루션이 있습니다. 그렇기 때문에 성능을 조정하는 것이 아니라 이해되는 솔루션에 동의하기 위해 동료 개발자와 코드를 동료 검토해야합니다. 일반적으로 이것은 다시 디자인되고 일부 반복 후에는 훨씬 더 나은 코드로 이어집니다.

테스트를 통과하기 위해 최소한의 구현을 작성 하고 많은 사람들이 이해하는 테스트를 작성하는 경우 돌이킬 수없는 복잡성이 남아 있는 코드베이스로 끝내야 합니다.

우연한 복잡성

원래 질문 (낙서)은 다음과 같습니다.

건축가는 소프트웨어 프로젝트에서 우발적 인 복잡성을 어떻게 관리합니까?

프로젝트에 대한 지시를 가진 사람들이 일회성 기술을 추가하기로 선택하고 프로젝트의 원래 건축가의 전체 전략이 프로젝트에 도입하지 않으려는 경우 실수로 복잡성이 발생합니다. 이러한 이유로 전략 선택에 대한 추론을 기록하는 것이 중요합니다.

우발적 인 복잡성은 전략에서 의도적으로 벗어날 때까지 원래의 전략을 고수하는 리더십에 의해 막힐 수 있습니다.

불필요한 복잡성 방지

질문의 본문을 바탕으로 다음과 같이 바꾸겠습니다.

건축가는 소프트웨어 프로젝트의 복잡성을 어떻게 관리합니까?

이 표현은 문제의 본문에 대한 제안으로 Feynman 알고리즘이 도입되어 최고의 건축가가 문제에 직면했을 때 능숙하게 솔루션을 구성 할 수있는 게슈탈트를 제안하는 컨텍스트를 제공합니다. 우리 나머지는 이것을 배우기를 희망 할 수 없습니다. 이해의 대상이되는 것은 주제의 지능과 범위 내에있을 수있는 건축 옵션의 특징을 배우려는 의지에 달려 있습니다.

프로젝트 계획 프로세스는 조직의 학습을 사용하여 프로젝트의 요구 사항 목록을 작성한 다음 가능한 모든 옵션의 목록을 구성한 다음 요구 사항과 옵션을 조정하려고 시도합니다. 전문가의 게슈탈트는이 작업을 신속하게 수행 할 수 있으며, 분명한 작업이 거의 없어서 쉽게 알아볼 수 있습니다.

나는 그의 준비 때문에 그에게 온다는 것을 당신에게 제출합니다. 전문가의 게슈탈트는 모든 옵션에 대한 지식과 프로젝트가 제공해야 할 미래의 요구를 수용 할 수있는 직관적 인 솔루션을 제공하고 변화하는 요구에 적응할 수있는 유연성을 요구합니다. 프로젝트. Feynman은 이론 및 응용 수학 및 물리학의 다양한 접근 방식에 대해 깊이 이해하고있었습니다. 그는 선천적으로 호기심이 많았으며 주변 자연계에 대해 발견 한 것들을 이해할만큼 밝았습니다.

전문가 기술 설계자는 기본에 대한 깊은 이해와 다양한 기술에 대한 광범위한 노출을 바탕으로 비슷한 호기심을 가질 것입니다. 그 (또는 그녀)는 여러 영역에서 성공한 전략 (예 : Unix Programming의 원칙 )과 특정 영역에 적용 되는 전략 (예 : 디자인 패턴 및 스타일 가이드 ) 을 활용하는 데 지혜 가 있습니다 . 그는 모든 자원에 대해 잘 알고 있지는 않지만 자원을 찾을 수있는 곳을 알 것입니다.

솔루션 구축

이 수준의 지식, 이해 및 지혜는 경험과 교육에서 얻을 수 있지만 우발적이고 불필요한 복잡성을 피하는 방식으로 함께 작동하는 게슈탈트 전략 솔루션을 구성하려면 지능과 정신 활동이 필요합니다. 전문가는 이러한 기본 사항을 종합해야합니다. Drucker는 처음이 용어를 만들었을 때 예견 한 지식 근로자였습니다.

구체적인 최종 질문으로 돌아 가기 :

우발적 인 복잡성을 길들이는 구체적인 방법은 다음과 같은 종류의 소스에서 찾을 수 있습니다.

• 유닉스 프로그래밍의 원리
• 디자인 패턴
• 및 스타일 가이드 ( 예 : Python 's PEP 8 )

Unix Programming의 원칙을 따르면 잘 작동하고 공통 인터페이스로 강력한 간단한 모듈 식 프로그램을 만들 수 있습니다. 다음 디자인 패턴을 사용하면 필요 이상으로 복잡한 복잡한 알고리즘을 구성 할 수 있습니다. 스타일 가이드를 따르면 코드를 작성하는 언어에 맞게 코드를 읽고 유지 관리하며 최적으로 사용할 수 있습니다. 전문가들은 이러한 리소스에서 발견 된 많은 원칙을 내면화하고이를 일관된 방식으로 통합 할 수 있습니다.

이것은 몇 년 전에 어려운 질문 이었지만 요즘 우발적 인 복잡성을 제거하는 것은 더 이상 IMO가 아닙니다.

켄트 Becksaid 자신에 대해 어떤 시점에서 : "나는 훌륭한 프로그래머가 아니에요, 나는 좋은 습관을 가진 좋은 프로그래머입니다."

IMO는 강조 할 가치가있는 두 가지입니다. 그는 자신을 건축가가 아닌 프로그래머 라고 생각하며 지식이 아닌 습관에 중점을 둡니다.

어려운 문제를 해결하는 Feynman의 방법은 그것을 할 수있는 유일한 방법입니다. 설명이 반드시 이해하기 쉽지는 않기 때문에 설명하겠습니다. Feynman의 머리는 단지 지식으로 가득 차있을뿐만 아니라, 그 지식을 적용하는 기술로 가득했습니다. 지식과 기술을 모두 사용하면 어려운 문제를 해결하는 것이 어렵거나 쉽지 않습니다. 가능한 유일한 결과입니다.

깨끗한 코드를 작성하는 완전히 마술이 아닌 방법이 있습니다. 우연히 복잡하지는 않지만 Feynman이 한 것과 비슷합니다. 필요한 모든 지식을 습득하고 그것을 익히지 않고 작동시키는 데 익숙해 지도록 훈련하십시오. 뇌의 어느 구석 에선 깨끗한 코드를 작성하십시오.

이제 많은 프로그래머들은 깨끗한 코드를 작성하는 데 필요한 모든 지식을 알지 못합니다. 젊은 프로그래머는 알고리즘과 데이터 구조에 대한 지식을 버리는 경향이 있으며 대부분의 나이든 프로그래머는이를 잊어 버리는 경향이 있습니다. 또는 큰 O 표기법 및 복잡성 분석. 나이가 많은 프로그래머는 패턴이나 코드 냄새를 없애거나 심지어 존재하는지조차 모릅니다. 어떤 세대의 프로그래머라도 패턴에 대해 알고 있더라도 사용시기와 드라이버 부분을 정확히 기억하지 마십시오. SOLID 원칙에 따라 지속적으로 코드를 평가하는 모든 프로그래머는 거의 없습니다. 많은 프로그래머들이 가능한 모든 추상화 수준을 어디서나 혼합합니다. 나는 한 동료 프로그래머가 당분간 리팩터링 책에서 Fowler가 묘사 한 스텐트에 대해 자신의 코드를 지속적으로 평가한다는 것을 알지 못합니다. 일부 프로젝트는 일부 메트릭 도구를 사용하지만 가장 많이 사용되는 메트릭은 일종의 복잡성입니다. 반면에 두 개의 다른 메트릭 (커플 링 및 응집성)은 깨끗한 코드에 매우 중요하더라도 무시됩니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 가장 많이 사용되는 측정 항목은 복잡성이며, 한 종류 또는 다른 유형이지만, 다른 두 측정 항목 (커플 링 및 응집력)은 깨끗한 코드에 매우 중요하더라도 무시됩니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 가장 많이 사용되는 측정 항목은 복잡성이며, 한 종류 또는 다른 유형이지만, 다른 두 측정 항목 (커플 링 및 응집력)은 깨끗한 코드에 매우 중요하더라도 무시됩니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 반면에 두 개의 다른 메트릭 (커플 링 및 응집)은 깨끗한 코드에 매우 중요하더라도 무시됩니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 반면에 두 개의 다른 메트릭 (커플 링 및 응집)은 깨끗한 코드에 매우 중요하더라도 무시됩니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 거의 모든 사람들이 무시하는 또 다른 측면은인지 부하입니다. 단위 테스트를 문서로 취급하는 프로그래머는 거의 없으며, 단위 테스트를 작성하거나 이름을 지정하는 것이 어려운 또 다른 코드 악취라는 사실을 아는 사람은 거의 없습니다. 소수의 사람들은 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지하기위한 도메인 중심 설계의 진로를 알고 있습니다. 불일치로 인해 문제가 발생할 수 있기 때문입니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 기억할 수없는 많은 것들이 있습니다. 불일치로 인해 문제가 발생할 수 있으므로 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지해야합니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 더 이상 기억할 수없는 것들이 많이 있습니다. 불일치로 인해 문제가 발생할 수 있으므로 코드 모델과 비즈니스 도메인 모델을 가능한 한 가깝게 유지해야합니다. 코드를 깨끗하게하려면 이러한 모든 사항을 항상 고려해야합니다. 그리고 지금은 더 이상 기억할 수없는 것들이 많이 있습니다.

깨끗한 코드를 작성하고 싶습니까? 마법이 필요하지 않습니다. 필요한 모든 것을 배우고 코드의 청결도를 평가하고 행복해질 때까지 리팩터링하십시오. 그리고 계속 배우십시오-소프트웨어는 아직 젊은 분야이며 새로운 통찰력과 지식은 빠른 속도로 습득됩니다.