[clean code] 6일차

• 오늘의 책읽기: 5장.형식 맞추기 까지!
• 오늘의 과제: TIL 작성하기
• 제출기간: 익일 오전 6시까지

지난번 미션을 이렇게 해결했어요!

• 미션 2. 리팩토링
• 정해진 정답은 없어요! 참고하시면 됩니다.
• 다들 수고하셨어요 ;)

TIL 작성하기

• TIL, Today I Learned 는 책 감상평을 쓰는 방법 중 하나 입니다.
• TIL 작성방법을 숙지한 후. TIL을 작성해주세요.
• TIL 책 감상평 예시 를 참고하세요.

좋은 TIL 엿보기

• 이름! 사람은 이름대로 산다는 말이 있다. 한치 앞도 모르고 살아가는 사람 또한 그러한데, 뚜렷한 목적을 가지고 태어나는 변수와 함수, 클래스에게 이름의 중요성은 몇 번을 강조해도 부족하지 않다. 그런 의미에서, 이 책의 첫 장에서 의미 있는 이름에 대해 기술하는 것은 당연하다. 잘 지은 이름으로 가득 찬 코드는 읽는 이로 하여금 무엇을 위한 코드인지, 어떻게 작동하는지 직관적으로 알 수 있게 해준다. - @leeq
• 더 자세히 읽어보기

제출방법

• 제출기간: 익일 오전 6시까지
• 업로드 하신 게시물 링크를 아래 제출하면 끝!

---

p 96 형식을 맞추려는 목적 ... 코드 형식은 중요하다.... 어쩌면 돌아가는 코드가 전문개발자의 일차원적인 의무라 여길지도 모르겠다. 하지만 이 책을 읽으면서 생각이 바뀌었길 바란다. 오늘 구현한 기능이 다음 버전에 바뀔가능성이 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드 품질에 지대한 영향을 미친다.

정말 오랜만에 코드 품질이라는 단어를 보는것 같다. 

항상 생각컨데 주제처럼 형식을 맞춘다는 것은 각 개인의 생각이 반영된 코드에서 '너 잘못 생각하고 있어'라는 의미로 들렸던거 같다. 심지어 정답인 없다고 생각하는 프로그래밍에서.. 어떻게 사용하던 상관없잖아??

이렇게 생각했던 나는 리뷰를 하면서 많은 벽에 부딫혔다. 왜 이렇게 사소한걸로? 하지만 결국 이 모든 사소함들이 조금씩 쌓여가며 실력을 만들어 가는 것이다. 

 

코드를 짜는 것은 한권의 책을 쓰는 것이라 생각해보자. 전공서적을 만드는데 어떤책은 베스트 셀러이지만 어떤 책은 존재조차 모르는 책도 있을 것이다. 분명 같은 내용을 담고있어도 차이가는데 이 차이는 코드 품질과 유사하다고 생각한다. 우리 모두 수많은 독자가 있는 하나의 책을 쓰고있는게 아닐까?

---

p97 ... 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다는 사실이다. p101 ... 수직거리...이 조각 저 조각이 어디에 있는지 찾고 기억하느라 시간과 노력을 소모한다.  p104 ... 종속함수. 한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치해야 한다. p106 ... 개념적 유사성. 어떤 코드는 서로 끌어당긴다. 개념적인 친화도가 높기 때문이다. 친화도가 높을 수록 코드를 가까이 배치한다.

오늘 읽은 부분은 책에서 가장 이해도 어렵고, 내용도 어려운 부분이라고 생각한다. 

분명 함수는 재사용성이 뛰어나도록 짜야하고 해당 함수를 여러곳에서 호출하게 될 것이다. 그러다보면 

수직거리, 종속함수, 개념적유사성 등등 다양한 이유에서 주변에 넣으려다보면 200줄은 순식간에 넘친다. 

 

어떻게 해결할 수 있을까? 

해결책은 내가 생각하는 최고의 방법인 설계도를 그리는 것이다. 

집을 짓기위해서 필요한 것은 벽돌이 아니라 설계도다. 

어떻게 집을 지을까? 집을 다 지으면 어떤 집이 나올지 모든 고민과 구상이 들어간것이 바로 설계도

코드도 똑같다. 위의 문제들을 잘 처리하려면 설계도가 잘 나와야하고 우리는 sw공학시간에 배운 uml을 통해 설계도를 그릴 수 있다. 

하지만 일부 개발자는 설계도 그리기를 싫어할 수도 있다. '변경사항이 계속 발생합니다.', '현실적인 문제를 반영하지 못합니다.' 등등 다양한 이유에서 uml을 그리기 싫어한다. 

하지만 집을 지을때 만약 지반이 약하다는 평가를 받으면? 중간에 땅이 조금 팔려버렸다면? 이유가 좀 이상하긴하지만 가장 먼저 진행하는 것은 설계도의 수정과 안정성 평가일 것이다.

우리 개발자도 하나의 건물, 도시를 만드는 구성원이다. 좋은 코드 짧은 코드 이해하기 쉬운코드는 얼마나 좋은 설계에서 프로그램을 구성했는지에 따라 달라지는 부분으로 저자의 말을 현실로 꺼내려면 OOP가 기본적으로 이해하고 설계할 수 있는 능력이 되어야한다고 생각한다. 

---

p. 113 팀 규칙 ... 팀은 한 가지 규칙에 합의 해야한다. 그리고 팀원은 그 규칙을 따라야한다....

너무나도 지켜지기 어려운 부분인것 같다. 

하지만 절대적으로 지켜야한다고 생각하고 노력하는 중이다. 

심지어 규칙을 깨려는 사람을 막으려고 노력하고있다.

 

회사규칙 > 팀규칙 > 개인 규칙 까지 이렇게 서로가 마치 우리 법률처럼 ( 헌법 > ... > 기타 법 ) 지켜져야 의미가있다. 

팀만 이용한 MSA로 코드를 분리하는 상황이라면 회사 규칙을 지키지 않아도 되는가?

아니라고 생각한다. 

MSA로 가더라도 컨밴션은 지켜져야한다. 

마치 국가대표선수가 조기축구에 가서 마음대로 하겠다라고 하는 느낌을 지울 수 없다.