# 코드 추가 및 제거

## 코드 제거의 미학

> 코드는 꾸준히 이자를 내야 하는 부채와 같다.

* 코드가 가치 있다고 느끼게 되는 이유는 생산 비용이 비싸기 때문
* 코드를 작성하려면 많은 시간을 소비하고 많은 카페인을 섭취해야 한다.
* 시간이나 노력을 드렸기 때문에 어떤 것에 가치를 부여하는 것을 **매몰 비용의 오류(sunk-cost fallacy)**&#xB77C;고 한다.
* **가치는 투자 자체에서 나오는 것이 아닌&#x20;**<mark style="color:red;">**투자의 결과**</mark>**에서 나온다.**

### **복잡성을 제거하기 위한 코드 제거**

> 어떤 것을 구현할 때 시스템이 어떻게 동작하는지에 대한 멘탈모델(인식모형)을 구축하고, 이에 영향을 미치도록 변경해야 한다.

* 복잡성은 **도메인 복잡성**과 **부수적 복잡성** 두 유형으로 나뉜다.
  * **도메인 복잡성**: 도메인이 기본적으로 가지고 있는 것
  * **부수적 복잡성**: 도메인에서 요구하지 않았지만 우연히 추가된 모든 복잡성

#### 부수적 복잡성

> 기술 부채의 동의어
>
> 개발이 더디고 더 어려워지는 원인이 된다.

기술적 무지, 기술적 낭비, 기술적 부채, 기술적 방해물로 네 가지 유형의 부수적인 복잡성이 있다.

* **기술적 무지**: 경험 부족으로 무의식적으로 코드에서 잘못된 결정을 내림으로써 좋지 않은 아키텍처를 만든다.
  * 무지해서 불필요한 결합을 추가하지 않고도 문제를 해결할 수 있는 기술이 부족해서 발생
  * 이 문제의 유일하게 지속 가능한 해결책은 "**지속적으로 주의를 기울이는것(투자)**" - 애자일 소프트웨어 개발을 위한 선언문
* **기술적 낭비**: 시간 압박으로 코드에 잘못된 결정을 내림으로써 아키텍처가 좋지 않은 결과를 초래하는 것
  * <mark style="color:purple;">**문제나 모델을 충분히 이해하지 못하기 때문**</mark>에 테스트나 리팩터링을 건너뛰거나, 기한을 맞추기 위해 프로세스를 우회
  * 이런 나쁜 결정은 **의도적인 것**
  * 외부 압력으로 인해 더 나은 지식을 거스르는 방향을 선택함
* **기술적 부채**: **일시적**으로 차선의 해결책을 선택해서 이익을 얻는 것
  * ex: 적절한 아키텍처 고려 없이 핫픽스를 구현하고 중요 문제를 해결하기 위해 적용한 다음 나중에 적절한 수정을 구현하기 위해 다시 해야할 때
  * 기술적 부채를 발생시키는 것은 전략적인 결정
  * 만료일이 있는한 본질적으로 잘못된 것이 없다
* **기술적 장애물**: 개발을 더디게 만드는 모든 것
  * 문서, 테스트 및 기존 코드 등 모든 범주가 포함됨
  * 무언가를 구축하는데 따르는 **부작용**

{% hint style="info" %}
"거기 두어도 아무런 방해가 되지 않는다"라는 말은 모두 거짓말

* 해결책은 더 이상 삭제할 것이 없을 때까지 가능한 한 많은 것을 삭제하는 것
* 조금이라도 사용하지 않는 것들은 사라져야 한다.
* 사용하지 않으면 기능은 퇴화한다.
  {% endhint %}

### **레거시 코드**

> 수정하기 겁나는 코드 (이 상황은 종종 서커스 팩터의 결과이다.)

{% hint style="info" %}
**서커스 팩터(circus factor)** - 버스 또는 로터리 팩터라고도 함

* 너무 많은 시스템에 대한 지식이 소실되어 개발의 일부가 중단되기 전까지 얼마나 많은 사람이 이탈해서 서커스에 합류해야 하는지를 나타낸다.
* "시스템을 배포하는 방법은 존밖에 모른다" 는 해당 시스템에 서커스 팩터가 있다고 말한다.
* 서커스 팩터를 잃는 순간 우리는 건드리기 꺼려지는 미지의 코드, 즉 레거시 코드를 가지게 된다.
  {% endhint %}

#### 스트랭글러 무화과나무 패턴

> 이 패턴은 기존 나무 줄기에 씨를 뿌리고 자라면서 숙주를 감싸 궁극적으로 숙주 나무를 교살해 죽이는 스트랭글러 무화과나무의 이름을 따서 명명됨

## 코드 추가에 대한 두려움 떨쳐내기

> 완벽한 코드에 대한 부담감

* 코드가 결함을 갖게 되는 방법이 얼마나 많은지를 생각해보자
* 완벽한 코드라는 것은 완전히 비현실적 목표이다.
* 성능, 구조, 추상화 수준, 사용의 용이성, 유지보수 비용, 참신함, 창의성, 정확성, 보안 등 많은 고려사항이 '완벽함'에 영향을 미침
* 이 모든 것을 염두에 두는 것은 불가능하다.
* <mark style="color:orange;">코드를 추가하는 것이 수정하는 것보다 안전하다는 것을 인식하자.</mark>

### 불확실성 받아들이기: 위험 감수

> 겁을 먹으면 효과적으로 일할 수 없다.

* <mark style="color:red;">**소프트웨어 개발은 도메인을 학습하고 그 지식을 프로그래밍 언어로 코드화하는 것**</mark>
* 팀 생산성의 가장 큰 예측 변수는 심리적 안정이다.
  * 팀원들이 서로를 신뢰하고 위험을 감수하는 것이 안전하다고 느껴지는지의 여부
* 무언가를 시도하기 전 만드는 방법에 대해 토론하거나 설계해야 한다는 강박관념이 들게한다.
  * 이것은 잘못된 것을 만드는 것에 대한 두려움이 제데로 못 만드는 것에 대한 두려움을 압도할 때 나타남

{% hint style="info" %}
낭비나 위험에 대한 두려움 극복을 위한 사용 시간 비율 지정

* 이해관계자의 요청에 의해 발생되지 않는 모든 작업을 의미하는 비티켓 작업들을 **금요일에 몰아서 하자.**
* 금요일에 개발자들은 실험과 주요 리팩터링을 수행하거나 개발 작업을 자동화하여 품질을 개선하거나 낭비를 줄이기
* 일상적인 티켓 작업에 활력을 불어넣을 수 있는 변화이기도 하다.
  {% endhint %}

### 가면 증후군

> 스스로를 자격이 없는 사람으로 간주하여 누군가 자신을 사기꾼으로 폭로할까봐 두려워 하는 것

* 자신을 보호하기 위해 코드를 완벽하게 만들려는 마음에 코드를 공개하지 않거나 -> 생산성에 실질적인 영향
* 사소한 문제에 대해 완벽한 코드를 작성하는 것은 특히 어렵기 때문에 질질 끌거나 대부분의 시간을 허비
* 개발자는 종종 다른 사람의 코드를 경솔하게 비판한다.&#x20;
  * "누군가 내 코드에 대해 그런 말을 하고 있나요?"
  * "그 사람이 내 코드를 본다면?", "그가 내 코드를 보고 있는건가?"&#x20;
  * 이러한 생각은 나를 가면 증후군으로 만들게 한다.
* **"나는 완벽한 코드가 존재한다고 믿지 않는다."**
* **"코드에서 가장 안전한 것은 아무것도 변경하지 않는 것임을 상기" -> 수정이 아닌 확장**
