클린 코드 1주차

올해 목표 중에 하나가 책이랑 친해지기이다.
목표를 위해 최근 '클린코드' 도서를 구매했고 아침에 일어나서 매일 30분을 읽을 것이다.
매일 내가 생각하고 배운 점을 기록하려고 한다.

나의 하루 루틴의 일부가 프로젝트 개발인데, 여기에 그날 배운 것을 써먹을 수 있도록 의식을 하며 노력해야겠다.

일주일 뒤에 클린 코드에 대한 생각이 성장할 것인지, 그때의 나는 얼마나 더 나은 코드를 짤 수 있을지, 아니면 그냥 그대로 일지... ㅋㅋ 기대가 된다.
열심히 읽어봐야겠다.

1일차

1장, 깨끗한 코드

• 단기적인 측면에선 나쁜 코드가 나쁘지 않을 수있다. 겉으로 봤을 땐 말이다. 왜냐면 생각하는 시간을 들이지 않고 짧은 시간내에 기능을 만들 수 있기 때문이다. 하지만, 장기적으로 봤을 땐 좋은 코드가 압압압승이다. 좋은 코드는 코드품질을 지켜주며, 이는 유지보수를 편리하게 해주고 개발 생산성을 향상시켜준다.
• 좋은 코드의 기준은 다양했다. 나는 효율적인 코드, 가독성 좋은 코드, 이유있는 코드를 기준으로 세우며 노력을 해왔다. 책을 보며 다양한 개발자 분들이랑 의견이 맞는 것도 몇 부분있어서 많이 공감을 했다. 가장 기억에 남고 공감이 갔던 것은 중복이 없는 코드이다. 중복이 많다면 설계가 부족했다는 것이고 이는 유지보수를 힘들게 한다. 그렇게 되면 소중한 시간과 인력을 낭비하게 된다.
• 나도 충분한 설계의 중요함을 여러 플젝을 하면서 매번 깨달아왔고, 설계를 잘하려고 노력하고 있다.
• 말고도 표현력 높이기, 추상화하기. 이번 프로젝트를 하며 내가 노력했던 부분들이어서 많이 공감을 한 내용이다. 론 제프리스 개발자님이랑 많은 공감을 했다.

2일차

2장, 의미있는 이름

• 명확한 이름을 사용하자. Product, ProductData or ProductInfo. 두 클래스는 각각의 개념을 구분하기 어렵다. Data, Info와 같은 불용어(의미가없는 단어) 사용을 지양하자. 의미가 분명히 다르다면 ok지만 그렇지 않다면 지양해야한다. 그렇지않고 그저 구분하기 위해 붙인 의미없는 단어의 사용을 피하자는 말이다.
• 그릇된 정보를 피하자. 예를 들어, hp, aix, sco 같은 변수 이름은 유닉스 플랫폼이나 유닉스 변종을 가리키는 이름이다. 본인에겐 훌륭한 약어로 보일지라도 독자에게 그릇된 정보를 제공할 수 있으며 혼란을 줄 수 있다.
  또, 다양한 데이터를 담고있는 변수를 표현할 때 우리는 변수명 끝에 list를 붙여 표현하곤 한다.
  list와 같은 것은 프로그래머에게 특수한 의미다. 다양한 데이터를 담고있는 컨테이너가 실제로 List가 아니라면 그것은 그릇된 정보를 제공하는 셈이여 이에 유의해야한다
• 시간을 들여 의미있고 의도가 분명한 이름을 짓는다면, 절약하는 시간이 훨씬 더 많다. 그렇기 때문에 이름을 지을 때 성의를 보이자. 또, 더 좋은 이름이 생각난다면 개선하도록 하자.

• 나는 변수명, 함수명 짓기를 어려워한다. 이름을 생각하는 시간이 낭비되는 시간이라고 생각했다. 하지만, 이 시간은 미래의 나, 그리고 팀원들에게 행복을 준다. 프로젝트를 해오면서, 내가 짠 변수 그리고 함수에 혼란스러웠던 적이 한 두 번이아니다. ㅎㅎ;
  그래서 적어도 나는 이해시키려는 목적으로, 머리를 데굴데굴 굴려 의미있는 이름을 적용하려고 노력 중이다.
  현업에서는 나만 이해한다고 되는 게 아니라, 팀원들도 이해시켜야한다.
  책에서 얘기하는 꿀팁들만 따라해도 나의 코드를 읽게될 팀원 그리고 나에게 행복을 가져다 줄 수 있을 것만 같다.

3일차

3장, 함수

• 함수는 한 가지를 해야한다. 그 한가지를 잘 해야 한다. 지정된 함수 이름 아래에서 추상화 수준이 하나이게 하면 된다.
• 일정한 추상화 수준을 유지하도록해서 읽는 사람을 행복하게 해주자. 근본 개념을 나타내는 부분과 세부사항을 나타내는 코드가 뒤섞인 코드는 읽는 사람을 힘들게 한다.
• if, else, while문 등에 들어가는 블록은 한 줄로 내부에서는 추상화된 작업을 한다. 반복된 추상화를 통해 짧은 함수를 작성할 수 있게된다. 또한 들여쓰기 수준은 1단이나 2단 이내여야 한다. 읽고 이해하기 쉬운 함수를 만들 수 있다.

• 함수로 넘어오고, 추상화 수준에 대한 얘기가 나와서 이해하기가 급 어려워졌다. 하지만 함수를 잘 쫌 짜보고 싶은 욕구가 있어 이해가 안되는 부분은 반복해서 봤다. 오늘 배운 것은 함수는 한 가지일만, 잘 하게 하자!라는 것이다.
  추상화 수준을 일관성있게 유지하면 코드를 개발하거나 리팩토링을 할 때 즐거울 것 같다. 추상화 없이 하나의 함수에서 6, 7개의 기능의 코드를 다 때려넣는다면 코드간의 경계가 모호해지고 코드를 읽기 어려워질 수가 있다.
  또, 깊은 블록 그리고 들여쓰기 수준은 함수의 크기를 크게하며 이 또한 코드의 가독성을 해칠 수 있다.

4일차

3장, 함수

• 추상화한 수준이 모두 같다면 그 함수는 하나의 일만 하는 것이라 할 수 있다. 각각 추상화 수준 1단계, 추상화 수준 3단계인 코드가 섞여있다면, 추상화 수준을 맞추기 위해 추상화를 해야할 필요가 있다.
• Switch문. 새로운 유형이 추가될 때 마다 코드를 변경해주어여한다(OCP위반). 또 이 switch문이 등장하는 함수가 무한정 존재한다면..? 아래처럼 switch문을 포함된 함수를 어떻게 개선할 수 있을까.

public Money calculatePay(Employee e) {
	switch (e.type) {
		case COMMISSIONED: return calculateCommisionedPay(e);
		case HOURLY: return calculateHourlyPay(e);
	}
}

• 다형성 + 추상화를 적용하자.
• switch 문은 다형성 객체를 생성할 때 딱 한 번 사용하자.
• 단항함수 다음으로 이항 함수가 이상적이고 그 이상은 가능한 피하는 게 좋다. 복잡한 인수는 함수를 더욱 이해하기 어렵게 만든다.
• 이항 함수의 인수들은 한 값을 표현하도록 또는 자연적인 순서를 따르도록 하는 것이 좋다.
• writeField(name) vs. writeField(outputstream, name) => 전자의 함수가 더 쉽게 읽히고 이해하기도 쉽다. outputstream인수의 뜬금없는 등장에 주춤하게 된다.

• 내가 써 먹을 수 있는 팁들이 많은 것 같지만 이해를 모두 하지는 못했다. 그리고 왜 좋은지도 완벽히 이해를 못해서 따라하기 힘들 것 같다. 3장 함수를 다 읽고 한 번 더 반복해서 읽어봐야겠다.

5일차

3장, 함수

• 부수 효과를 일으키지 마라. 이를 숨기는 것은 혼란을 초래한다. 그래도 필요한 작업이라면, 함수명에 이런 작업을 한다는 것도 나타내자.
• 명령과 조회를 분리하라. 함수는 뭔가를 수행하거나 또는 뭔가에 답하거나 둘 중 하나만 해야한다.

if (set("username", "hyeondoonge"))...

이름만 봐선 한 가지만 일만 하는 함수인데, 반환을 하는 걸 봐서 2가지 일을 하고 있다. 혼란스럽다.

if (attributeExists("username")) {
	setAttribute("username", "hyeondoong");
  ...
}

위의 코드 처럼 명령과 조회를 구분하도록 하자.

• 오류 코드보다는 예외를 사용하라. 오류 코드로 처리하게 되면 무진장 중첩된 if문들을 야기한다. 또 if 문 내부에서는 각각의 오류들을 처리하는 코드를 작성해야한다.
• 대신, 예외를 사용해서 오류들을 catch문으로 다 던져버리면 원래 로직과 오류 처리 로직이 분리되므로 깔끔한 코드를 작성할 수 있다.
• try-catch 블록 뽑아내기. try/catch 문은 코드 구조에 혼란을 일으킨다. 오류를 처리하는 것도 하나의 작업이다. 이를 별도 함수로 뽑아낸다면, 좀 더 기능적인 것에 집중할 수 있을 것 같다.
• 함수 내부에서 여러가지 일을 처리하는 것은 하나의 일을 처리하는 것보다 복잡하고 이해하기 힘들다.

• 반복하지 마라. 중복은 악의 근원이다. 중복은 코드 길이를 늘리고 알고리즘이 변한다면 중복되는 만큼 손봐야할 코드도 많다. 또, 어느 한 곳을 빠뜨리고 수정을 한다면... 오류도 발생하기 쉽다. 중복을 제거해서 가독성이 뛰어나고 유지보수하기 좋은 코드를 생산하자.

• 함수를 처음 짤 때는 길고 복잡할 수 밖에 없다. 거기서 다듬어 가면 되는 거다. 이름을 바꾸고 중복을 제거하고, 메서드를 줄이고 하는 등등의 노력을 해서 말이다.

• 프로그래밍 언어라는 수단을 사용해 좀 더 풍부하고 좀 더 표현력이 강한 언어를 만들어 시스템이라는 이야기를 풀어나가자.

• 이야기처럼 술술 읽혀 읽기 즐거운 코드를 짤 수 있는, 팀원들에게 행복을 주는 개발자가 되고 싶다 🤩

6일차

3장, 함수

7일차

4장, 주석
주석을 많이 쓰는 편은 아니다 보니, 이해가 안가는 부분이 꽤 있었다.
그래서 이 장은 내가 현재 상황에서 도움이 될 만한 부분만 몇 개 꼽아서 기억해두고 적용해야겠다.

• 우리는 코드로 의도로 표현하지 못해, 그러니까 실패를 만회하기 위해 주석을 사용한다. 상황을 역전해 코드로 의도를 표현할 방법이 없는지 생각해보자.
• 나쁜 주석 (예를 들어 잘못된 정보를 전달하는...)에 한해서는 경계를 해야하고 개선해나가야한다.
• 코드만이 자기가 하는 일을 진실되게 말하고, 정확한 정보를 제공하는 유일한 출처다. 그러므로 최대한 코드에 의도를 표현할 수 있도록 하자.
• 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 지금까지 내가 짰던 코드에 대해 다시금 생각해볼 수 있게한 문장이었다. 지금까지 코딩테스트를 치를 때, 시간에 쫓겨 코드 품질은 전혀 신경쓰지 않은 코드를 작성하곤 했다. 하지만, 남이 내 코드를 볼 수 있다는 걸 생각하고 시간이 남았을 때는 주석을 붙이는데 시간을 썼다. 이런 난장판인 코드를 주석으로 설명하려 애쓰는 대신, 이 난장판을 깨끗이 치우는데 시간을 보내자.
• 내가 구현한 기능은 내가 짠 코드 그 자체다. 개선해야할 것 또한 주석이 아니라 내가 짠 코드이다. 때문에 최대한 코드에 내 의도를 표현해야한다.

1주일 간 읽으면서 클린코드 팁들을 의식하며 코드를 작성하려고 노력하고 있다. 하하
클린코드를 짜는데 익숙하지 않아서, 익숙해지는데 시간을 들여야겠다.
3장의 함수 섹션은 현재 자바스크립트로 개발하는 나에게 많은 도움이 될 거 같아 또 다시 읽을 것이다.