20.05.14 클린 코드 Day 1

1장. 깨끗한 코드

 

1. 코드가 존재하리라!

- 시스템의 자동화는 어느정도 이루어지나 한계점이 분명히 존재하기 때문에 코딩은 절대 사라지지 않는다.

또한 코딩은 요구사항을 표현하는 언어이다. 그러므로 분명하고 명시적으로 만들줄 알아야 한다.

 

2. 나쁜코드

- Leblanc' Law (Later Equals Never), 나쁜코드는 수정하지 않고 지나친다면 눈덩이가 불어나듯 감당할 수 없는 

큰 문제로 다가오게 된다. 지금 문제에 직시했다면? 바로 고쳐나가자

 

3. 나쁜코드로 치르는 대가

- 처음에는 진도가 빨리 나가지만 얼마 안가 개발속도를 크게 저하시킨다.

(몇 날 몇일을 버그를 고치는 것에 소비하게 된다.) 

어느 시점에 도달하게 되면 더 이상 정리할 수 없을 정도로 커지게 된다. 물론 재설계의 방법도 있지만 유지보수를 

하면서 재설계를 하는 것은 단지 꿈에 불과하다.

(관리자는 새로운 기능을 요구할 것이고, 재설계는 직접적으로 다가오는 작업이 아니기 때문이다.)

 

4. 태도

- 그렇다면 나쁜코드를 양성하게 되는 원인의 제공자는 누구인가? 마감기한을 독촉하는 관리자인가? 

말도 안되는 요구사항을 늘어놓는 마케터인가? 바로 개발자이다. 우리는 그들에게 정확한 정보를 전달할 의무가 있고,

좋은 코드를 사수할 필요가 있다. (최소한 개발자라는 타이틀을 가지고 일을 하는 사람으로써)

 

5. 원초적 난제

- 깨끗한 코드를 작성하는 것은 속도를 늦춘다? 오히려 나쁜 코드 때문에 속도가 더 늦는 경우가 많다.

 

6. 보이스카우트 규칙

- "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라" 라는 보이스카우트 규칙을 기억하자. 우리는 우리 자신이

작업한 코드를 좀 더 깨끗한 코드로 만들어야할 책임이 있다.

 

7 . 프리퀄과 원칙

- SRP, OCP, DIP 등의 원칙을 공부해 적용해보자.

 

8. 깨끗한 코드란?

- 많은 프로그래머들이 생각하는 깨끗한 코드는 서로가 다르지만 중복, 읽기 쉬운, 최대한 내용을 줄일 코드가 좋은 코드

임은 아무도 부정하는 개발자는 없을 것이다.