📔중복의 해악

프로그램을 개발하는 중에 지식을 중복해 넣는 경우가 많다 그렇게 된다면 애플리케이션이 완성되기 전부터 유지보수의 악몽이 시작될 것이다.

소프트웨어를 신뢰성 높게 개발하고 개발을 이해하고 유지보수하기 쉽게 만드는 유일한 길은 DRY원칙을 따르는 것이다

DRY - 반복하지 마라 Don't Repeat Yourself
모든 지식은 시스템 내에서 단일하고 애매하지 않고 정말로 믿을만한 표현양식을 가져야한다.

DRY원칙을 따르지 않는다면 똑같은 것을 2군데 이상 표현했을 경우 하나를 바꾼다면 나머지 하나도 바꿔야함을 기억해야한다.

• 이것을 기억하느냐 마느냐의 문제가 아니다, 단지 언제 잊어버릴 것인가의 문제이다.

📔언제 중복이 생기는가?

1. 강요된 중복 : 개발자들은 다른 선택이 없다고 느낀다. 환경이 중복을 요구하는 것처럼 보인다.

   • 프로젝트 표준이 중복된 정보가 기록된 문서를 요구하거나 코드에 중복 정보가 생기는 문서를 요구하는 경우
   • 여러플랫폼을 지원해야하는 경우
   • 각각에 프로그래밍 언어, 라이브러리, 개발환경이 필요하고 여기서 공유된 정의와 프로시저들이 중복되는 경우
   • 프로그래밍 언어 자체가 정보가 중복되는 어떤 구조를 요구하는 경우

   해결법

   1. 정보의 다양한 표현양식
      • 서로 다른 언어를 사용하지만 공통된 구조를 양쪽 모두에서 표현해야할 때가 있다. ex) 서버 - 클라이언트
        
      • 간단한 필터나 코드 생성기를 작성하는 것이 해답이다.
        • 공동의 메타데이터 표현에서 여러 개의 언어에 걸쳐있는 구조를 만들어 낼 수 있다.
   2. 코드내의 문서화
      • 주석을 작성하는 것은 좋다 하지만 짧은 코드에서도 주석을 작성하는 것은 좋지 않다.
        • 나쁜 코드는 많은 주석을 필요로 한다.
        • 코드는 코드로 말을 한다, 어려운 코드는 이해를 돕기 위해 주석을 작성해주면 좋다.
   3. 문서화와 코드
      • 우리는 주로 문서를 작성하고나서 코드를 작성한다.
      • 뭔가를 바꾸면 문서를 수정하고 코드를 갱신한다.
        • 문서와 코드 둘 다 동일 지식에 대한 표현이다.
      • 바쁜 시기에는 코드만 바꾸고 문서의 갱신은 뒤로 미루게 된다.
      • 문서를 자동으로 바뀌게 하는 것이 개발자 입장에서 좋다.

   언어의 관한 문제

   • 헤더 파일과 구현 파일에 있는 주석에 대해 생각해봐라
   • 함수 혹은 클래스 헤더 주석을 2개 파일에 걸쳐 중복할 이유는 없다
   • 헤더 파일에는 인터페이스에 대한 사항을 기록하라
   • 구현 파일에는 그 코드의 사용자가 알필요가 없는 상세한 것들을 기록해라

2. 부주의한 중복 : 개발자들은 자신이 정보를 중복하고 있다는 것을 깨닫지 못한다.

   예를들어 Line이라는 클래스의 시작점, 끝점, 길이 라는 속성값이 있다,

   이 클래스는 그럴싸해보이지만 길이는 시작점과 끝점으로 정의가 된다, 그중 하나라도 바뀌면 길이도 바뀌게 된다, 그러니까 길이는 계산되는 필드로 만드는 것이 낫다

   • 클래스 내의 메서드들만 좀 고생하면 된다.

3. 참을성 없는 중복 : 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 중복을 하게 된다.

   • 하지만 나중의 고통을 피하기 위해서 시간을 투자해서 중복을 하지 않아야 한다.

4. 개발자간의 중복 : 한 팀에 있는(혹은 다른 팀에 있는) 여러 사람들이 동일한 정보를 중복한다.

   • 최선책은 개발자간의 적극적이고 빈번한 소통을 장려하는 것이다.
     • 공통의 문제를 다루기 위한 토론장

재사용하기 쉽게 만들어라

• 개발자들이 조성해야할 환경은 뭔가를 직접 만드는 것보다 기존의 것을 재사용하는 환경이다.

---

📔직교성

하나를 변경할 때마다 다른 네개의 무언가가 이상해진다면? 끔직하다

설계, 빌드, 테스트 그리고 확장하기에 쉬운 시스템을 만드는 데에 있어 직교성은 매우 중요한 개셤이다.

직교성의 원칙을 적용하는 걸 직접 배우면 여러분이 만드는 시스템의 질을 즉각 개선할 수 있을 것이다.

직교성이란?
컴퓨팅에서 직교성이란 모듈간의 독립성(independence)이나, 결합도 줄이기(decoupling)을 의미한다.

직교성과 반대되는 개념은 상호의존적인 것이다, 특정 부분을 변화시키면 그것만 변화되는 것이 아닌 상호의존적인 어떤 것도 같이 변하기 때문에 어떠한 에러를 발생시킬지 모른다.

그러니까 어느 하나를 바꿀 때 나머지 것들을 걱정하지 않아도 되도록 설계를 해야한다.

관련 없는 것들 간에 서로 영향이 없도록 하라.

직교성의 장점

1. 생상성 향상
   • 변화가 지역에서만 일어나서 개발 시간과 테스트 시간이 줄어든다.
   • 상대적으로 작은 컴포넌트를 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 쉽다.
   • 또한 직교적인 접근법은 재사용을 촉진한다.
     • 컴포넌트들이 명확하고 잘 정의되어 있다면 코드를 또 짜지 않고도 잘 결합하여 사용할 수 있다.
2. 리스크 감소
   • 직교적인 접근법은 어떤 개발에도 잠재적인 리스크를 감소시켜 준다.
   • 감염된 코드를 격리시키고 그 코드만 도려내고 새롭게 코드를 짜기 쉽다.
   • 어떤 부분을 약간 바꾸고 수리해도 거기에서 생기는 문제점들은 그 부분에 한정되어 있기 때문에 에러처리하기도 좋다.

직교성의 원칙을 일에 적용하기

프로젝트팀

팀 내 업무가 겹치는 영역이 많다면 구성원들은 책임영역에 대해 혼동하게 된다, 뭘 하나 바꾸려고 해도 그들 중 누구라도 영향을 받을 수 있기 때문에 전체 팀원이 모여야한다.

팀 구조를 직교적으로 구성해야 한다 얼마나 직교성을 갖는지 측정해볼 수 있는 것은 요청된 개별 변화에 대한 토론에 참여할 필요가 있는 사람이 몇명인가를 보는 것이다.

숫자가 클수록 그룹의 직교성은 낮다.

직교적인 팀이 더 효율적임이 명백하다.

설계

각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다.

계층식 접근은 직교적 시스템을 설계하는 강력한 방법이다.

각 계층은 자기 밑에 있는 계층들이 제공하는 추상화만을 사용하기 때문에 코드에 영향을 끼치지 않으면서 아래에 있는 다른 구현들을 바꾸는 높은 유연성을 얻을 수 있따.

계층을 두는 것은 또한 모듈 간의 종속성이 발리 늘어나는 위험을 감소시킨다.

컴포넌트를 나누었을 때 스스로에게 물어보라

'특정 기능에 대한 요구사항을 극적으로 변경했을 경우, 몇 개의 모듈이 영향을 받는가?'

• 직교적인 시스템에서는 답이 '하나' 여야 한다.

툴킷과 라이브러리

써드파티 툴킷이나 라이브러리를 도입할 때, 시스템의 직교성을 보존할 수 있는지 주의깊게 살펴보고 기술을 현명하게 선택하라.

코딩

자신이 작성하는 코드를 항상 비판적으로 검토해보는 습관을 기르길 바란다.

기회가 있을 때마다 코드의 구조와 직교성을 향상시키도록 노력해라.

이러한 프로세스를 리팩토링(refactoring)이라고 부르며 매우 중요하다.

직교성을 유지하기 위한 3가지 기법

1. 코드의 결합도를 줄여라

   불필요한 어떤 것도 다른 모듈에 보여주지 않으며 다른 모듈의 구현에 의존하지 않는 코드를 작성하라

   객체의, 상태를 바꿀 필요가 있따면, 객체 스스로가 그러한 일을 수행하게 만들어라.

2. 전역 데이터를 피하라

   코드가 전역 데이터를 참조할 때마다, 코드는 해당 데이터를 공유하는 다른 컴포넌트와 묶이게 된다.

   읽기 전용 목적으로 전역 데이터를 사용한다 하더라도 문제가 발생할 수 있다.

3. 유사한 함수를 피하라

   종종 유사해 보이는 함수의 집합을 구현해야 할 때가 있다.

테스트

직교적으로 설계, 구현한 시스템은 테스트하기 더 쉽다.

시스템 컴포넌트 간의 상호작용이 형식화되고 제한되었기 때문에 시스템 테스트의 더 많은 부분을 각각의 모듈 수준에서 수행할 수 있기 때문이다.

이는 모듈(단위) 수준의 테스트가 통합 테스트보다 테스트케이스를 만들고 수행하기 훨씬 쉽다는 점에서 좋은 소식이다.

우리는 모든 모듈이 자신만의 단위 테스트를 위한 테스트케이스를 갖고 테스트가 정규 빌드 과정의 일부로 수행되어야 한다고 생각한다.

단위 테스트를 만든다는 것 자체가 직교성을 테스트해볼 수 있는 흥미로운 작업이다.

문서화

정말로 직교적인 문서라면 내용 변화 없이 표현을 극적으로 바꿀 수 있다.

현대의 워드 프로세서는 이를 도와주는 스타일스트와 매크로를 제공한다.

직교적으로 살기

DRY원칙과 매우 밀접한 관계가 있다 시스템 내부의 중복을 최소화시키고 직교성은 시스템 컴포넌트 간의 상호의존도를 줄인다.

당연한 말이겠지만 DRY원칙으로 무장하고 직교성 원리를 충실히 사용한다면 개발하고 있는 시스템이 더 유연하고, 이해하기 쉽고 또한 디버그,테스트 유지도 쉬워질 것이다.

---

📔가역성

가역성이란 ?
물질이 어떤 상태로 변하였다가 본래 상태로 되돌아갈 수 있는 성질.

결정이 돌에 새겨지는 것이라고 생각하고 발생할지도 모를 우연할 사건들에 대해 준비하지 않는 데에서 실수가 나온다.

결정이 돌에 새겨진 것이 아니라 해변가의 모래 위에 쓰인 글씨라고 생각해보라, 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

최종 결정이란 없다.

항상 객관적으로 판단하여 문제가 있을 것인지 판단해서 다가올 안좋을 미래를 대처하기 위한 방안을 세워야 한다.

---

📔예광탄

어둠 속에서 예광탄을 넣고 총을 쏘면 그안에 든 인 성분이 발화하여 총알의 궤적을 보여준다.

어둠 속에서 총을 쏘는 방법은 2가지이다.

1. 목표물에 대해서 정확히 계산하는 것
2. 예광탄을 사용하는 것

예광탄을 사용하면 즉각적인 반응을 통해서 조준을 다시 한다던가 빠르게 조치할 수 있기 때문이다.

새로운 프로젝트에서도 마찬가지로 예광탄처럼 해야한다.

익숙하지 않은 알고리즘, 막막한 요구사항등 수많은 미지의 것들과 조우를 하게 된다 그럴 때 모두 다 정확히 계산해서 일을 처리한다는 것은 매우 어려운 일이다.

그래서 실용주의 프로그래머는 예광탄을 선호한다.

목표물을 찾기 위해 예광탄을 써라.

예광탄은 요구사항부터 최종시스템까지 눈에 보이고, 빠르게 도달해줄 수 있다.

예광탄의 장점

1. 사용자들은 뭔가 작동되는 것을 일찍부터 보게 된다.
2. 개발자들은 들어가서 일할 수 있는 구조를 얻는다.
   • 아무것도 써있지 않은 백지가 가장 채우기 어렵다.
3. 통합작업을 수행할 기반이 생긴다.
4. 보여줄 것이 생긴다.
   • 프로젝트 후원자나 고위층 인사들은 눈으로 확인을 하고 싶어한다.
5. 진전 상황에 대해 더 정확하게 감을 잡을 수 있다.

• 만약 틀린 방향으로 가더라도 조준을 다시 할수 있다.

예광탄과 프로토타이핑이 다른 점

프로토타이핑은 누군가에게 보여주려고 대충 만들고 버리는 코드이다.

예광탄은 나중에 버리려고 만드는 것이 아니라 계속해서 사용할 코드이다.

---

📔프로토타입과 포스트잇

꼭 코드가 아니라도 화이트보드와 포스트잇으로 프로토타입을 만들 수 있다.

프로토타입의 대상

• 위험을 수반하는 모든 것
• 이전에 해본적이 없는 것
• 최종 시스템에서 매우 중요한 것

프로토타입을 통해 학습하라

프로토타입을 만들 때 무시해도 좋은 세부사항

1. 정확성 : 가짜 데이터를 사용해도 된다.
2. 완전성 : 완전하지 않은 기능이고 제한된 기능만 제공해도 된다.
3. 안정성 : 에러 검사가 불완전할수 있고 원하는데로 작동하지 않을 수 있다.
4. 스타일 : 프로토타입에 대한 문서를 많이 만들지 않아도 된다.

---

📔도메인 언어

언어의 한계가 곧 자기 세계의 한계이다. -루트비히 비트겐슈타인-

도메인이란 전문분야에서 어떠한 것에 대한 지식의 범위를 말한다.

상대는 배추 김치를 생각하고 김치를 말해도 나는 파김치라고 생각할 수 있다.

이런식으로 상대와 나의 도메인을 맞춰가는 작업은 매우 중요하다.

어떤 시스템을 제안하는 사용자의 말을 듣다보면 그들이 정확히 시스템이 어떻게 동작해야하는지 우리에게 말해주는 경우가 있다.

그런 경우에 그들이 원하는 내용대로 코드를 작성을 하는 것이다.

문제 도메인에 가깝게 프로그래밍하라.

---

📔추정

추정을 통해 놀람을 피하라.

어떤 의미에서 모든 답은 추정치이다,

질문자가 매우 높은 정확도의 답을 요구하는가? 아니면 단순히 큰 그림만을 요구하는가?

언제쯤 도착하냐고 물어보시는 할머니, 아마도 점심을 준비하실지, 저녁을 준비하실지에 대한 것이다,
당신이 사고를 당한 다이버라면 구조대에게 정확히 언제 도착할 것인지에 대해 초 단위까지 관심이 
있을 것이다.

전달하려는 정확도를 고려하여 답변의 단위를 선택하는 것이 중요하다.

좋은 추정 기술은 이미 그 일을 해본 사람에게 물어보라는 것이다.

추정치가 잘못되었더라도 움츠리거나 도망가지 마라.

여러분의 추측과 실제 값이 달라졌는지 원인을 찾아야 한다.

누군가 추정에 대해 물으면?

저자는 "나중에 전화드릴께요"라고 말한다고 한다.

자판기 앞에서 말한 추정치는 여러분에게 해를 끼칠 것이라고 말한다.