[Clean Code] 1장 :깨끗한 코드

안녕하세요 :) Zedd입니다.

클린코드를 꼭 지금 읽어야 하는데....또 나중에 되면 까먹을까바 ㅎㅎㅎ..

정리를 해보려고해요 ㅎㅎ

얼마전에 읽는데 

1장이 나오기까지가 넘나 오래걸리는것..

옮김이 서문 > 추천사 > 들어가면서..

ㅋ....ㅎㅋㅎㅋㅎㅋ..

이것도 그냥 막 뻘소리가 아니라..다 도움이 되는? 그냥 넘기기에는...그냥 넘기기에는 내 마음이 너무 불편한 글들입니다.

추천사도 간지 bb;;

그래서.......옮김이...서문...부터..........정리해보려고....합니다....

제일 좋은 방법은 사거나 빌려서 읽는게 좋겠죠? 제가 밑에 적은거는 그냥 정말 "요약"이구요....요약도 정말 제 개인적인 생각으로 중요하다는 것만 적었어요. 그렇다고 밑에 안적은게 중요하지 않다..!!이거는 아닙니다......

그리고 이제 여러분은 딜버트에요.

[Clean Code] 1장 : 깨끗한 코드

---

[옮김이 서문]

● 프로그램을 짤 때, 코드를 쓰는시간보다 코드를 읽는 시간이 훨씬 더 많다면 "보이스카우트 규칙"을 다른 모든 규칙에 앞서 특히 신경써야함.

"보이스카우트 단원들에게 야영장에 들어올 때 보다, 나갈 때 더 깨끗한 상태로 만들 의무가 있다면, 우리 개발자들에게는 체크아웃해 코드를 꺼낼 때 보다 체크인해서 코드를 넣을 때 더 깨끗한 상태로 만들어야 할 의무가 있다"

● 이 책(클린코드)에  정말 클-린한 코드를 쓸 수 있게 하는 엄청난 비밀이 있는건아니고..한번쯤 들어봤을 이야기를 걍 체계적으로 정리한거임

[추천사]

● 유지보수가 중요함. TPM(Total Productive Management)라는 품질관리론이 등장. 이 TPM을 지탱하는 기둥 하나가 소위 5S원칙.

< 5S원칙 >

 

1. 정리 또는 조직(정렬) : 명명법 등을 통해 무엇이 어디에 있는지 알아야함.

2. 정돈 또는 단정함(체계화) :코드는 누구나 예상하는 위치에 있어야한다.

3. 청소 또는 정리(광내기) : 과거이력이나 미래바람을 기억한 주석 혹은 주석으로 처리한 코드는 제거

4. 청결 또는 표준화 : 작업공간을 청소하는 방식에 그룹이 동의한다.

5. 생활화 또는 규율 : 관례를 따르고, 자기 작품을 자주 돌아보고, 기꺼이 변경하는 규율 - "작은것에도 충실한 사람이 큰 것에도 충실하다"

● 사소한 것이 집중 할 뿐아니라, 사소한 것에 정직해야한다. 다시 말해, 코드에 정직하고, 코드의 상태에 관하여 동료들에게 정직하고, 무엇보다도, 자기코드에 대해서 자신에게 정직해야한다.

● 아키텍쳐도, 깨끗한 코드도, 완벽을 주장하지는 않는다. 단지 최선을 다해 정직하라 요구할 뿐이다.

[들어가면서]

(아직도 1장 안시작함)

● 깨끗한 코드를 작성하는 방법은 배우기 어렵다. 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 고생을 해야한다. 

[1장] (드디어)

● 좋은코드는 중요하다.

● 르블랑의 법칙(leblanc's Law) : 나중은 결코 오지 않는다.  <- 이 말 진짜 너무 멋있는것 같아요. 여러분 나중은 오지 않습니다.

- 나쁜 코드가 쌓일 수록 팀 생산성은 떨어진다. 

- 코드가 너무 엉망이라 몇시간으로 예상한 업무가 몇주로 늘어진 경험이 있다면? => 기간, 일정, 요구사항 별별 핑계를 다 대지만 프로그래머 탓임ㅇㅇ 

- 좋은 코드를 사수하는 일은 프로그래머들의

- 좋은 코드를 사수하는 일은 프로그래머들의 책임이다. - "아니 왜 내책임이야;;;;상사가 시키는 대로 안하면 짤리는데;;;;;;" => 나쁜코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가 답지 못하다.

우리는 나쁜코드가 업무속도를 늦춘다는 것을 안다 -> 그럼에도 불구하고 기간을 맞추기위해 나쁜코드 양산 -> 하지만 나쁜코드를 양산하면 기한을 맞추지 못한다. 오히려 엉망진창인 상태로 인해 속도가 늦어지기 때문에 ㅇㅇ -> 기한을 맞추는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. 

ㅇㅇ다 알겠음. 그럼 깨끗한 코드는 어떻게 작성하는건데?

애초에 "깨끗한 코드"가 뭔데????

깨끗한 코드가 무엇인지 모르면 깨끗한 코드를 만들려고 애써봤자 소용이 없음.

너가 깨끗한 코드와 나쁜코드를 구분할 줄 안다고 깨끗한 코드를 작성 할 수 있는것도 아님ㅎㅎ;

깨끗한 코드를 작성하려면

- 청결

- 절제

- 규율

핵심은 "코드 감각"

코드감각이 있으면 좋은 코드와 나쁜코드를 구분한다. 그뿐만이아니라, 절제와 규율을 적용해 나쁜코드를 좋은 코드로 바꾸는 전략도 파악한다.

C++창시자 "비야네 스트롭스트룹" : "나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다 / 의존성을 최대한 줄여야 유지보수가 쉬워진다 / 오류는 명백한 전략에 의거해 철저히 처리한다 / 성능을 최적으로 유지해야 사람들이 원칙없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. "

==> 비야네에 따르면 깨끗한 코드는 '보기에 즐거운'코드임. 비야네가 말하는 효율도 단순히 속도를 의미하는게 아님. CPU자원을 낭비하는 코드도 우아하지 못함.

나쁜코드는 나쁜코드를 유혹한다!!!!!!!나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다.

비야네는 철저한 오류처리도 언급. == 세세한 사항까지 꼼꼼하게 신경쓰라는 말ㅇㅇ (메모리 누수, 경쟁상태, 일관성없는 명명법..등)

- 나쁜 코드는 너무 많은 읽을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려짐. 깨끗한 코드는 한가지에 '집중'한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.

그래디 부치 : "깨끗한 코드는 단순/직접적이고 잘 쓴 문장 처럼 읽힌다. 깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득하다"

그래디는 가독성을 강조 ㅇㅇ

코드는 추측이 아니라 사실에 기반해야하며 반드시 필요한 내용만 담아야 한다. 코드를 읽는 사람에게 프로그래머가 단호하다는 인상을 줘야한다.

데이브 토마스 : "깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고, 단위 테스트케이스와 인수 테스트 케이스가 존재한다. 고치기 쉽다. 깨끗한 코드에는 의미있는 이름이 붙는다. 특정 목적을 달성하는 방법은 오직 하나만 제공한다. 의존성은 최소이며, 각 의존성을 명확히 정의한다. 언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기 때문에 코드는 문학적으로 표현해야 마땅하다"

데이브도 가독성을 강조함과 동시에 깨끗한 코드는 다른사람이 고치기 쉽다고 함 ㅇㅇ

실제로 읽기 쉬운 코드와 고치기 쉬운 코드는 엄연히 다르다!!!!!!!!(인정합니다)

또한 TDD도 중요 ㅇㅇ 테스트케이스가 없는 코드는 아무리 우아하고 가독성이 높아도 깨끗한 코드가아니다.

마일클 페더스 : "깨끗한 코드의 특징은 많지만 모두를 아우르는 특징이 하나 있음 ㅇㅇ 깨끗한 코드는 언제나 누군가 주의깊에 짰다는 느낌을 준다.(진짜 공감..) 고치려고 살펴봐도 딱히 손 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로. 고칠 궁리를 하다 보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의깊에 짜놓은 작품에 감사를 느낀다"

(마이클 페더스가 한 말을 보고 진짜 한구절 한구절 공감가는 느낌 진짜..........)

마이클은 정곡을 찌르죠. 깨끗한 코드는 주의깊게 작성한 코드다. 

론 제프리스 : "모든 테스트를 통과한다 / 중복이 없다 / 시스템 내 모든 설계 아이디어를 표현한다 / 클래스, 메소드, 함수등을 최대한 줄인다. 나는 '중복'에 집중한다. 같은 작업을 여러차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다. 표현력은 변수 이름에만 국한되지 않는다. 객체가 여러 기능을 수행한다면, 여러 객체로 나눈다. 메소드가 여러 기능을 수행한다면, 메소드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메소드하나와 기능을 실제로 수행하는 여러개로 나눈다. 지저분한 코드를 손볼때 '중복'과 '표현력'만 고려해도 코드가 크게 나아진다.

론 제프리스꺼 길어서 안읽은 분들을 위해 요약 : 중복ㄴㄴ / 한기능만 수행ㅇㅇ / 제대로 표현ㅇㅇ / 작게 추상화ㅇㅇ

워드 커닝햄 : "코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다." (굉장히 맞는말)

워드는 깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다고 말함ㅇㅇ. 코드를 독해하느라 머리를 쥐어짤 필요가 없어야 한다. 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다. 

이제 이 저자의 생각이 나오는데, 저자가 이제 말할 교훈들은 진리임 ㅇㅇ 근데 절대적으로 옳다라는 단정은 금물이다. 그 점에 유의해서 봐주세요~.~

- 우리는 새 코드를 짜면서 끊임없이 기존코드를 읽는다. 그러므로 읽기 쉬운 코드가 매우매우 중요. 그니까 쉽게짜려면 읽기쉽게 만들면된다 ㅇㅇ

● 보이스카우트 규칙 

잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야한다. 체크아웃할 때 보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 그냥 변수 이름 하나 개선하고, 긴 메소드 분할하고, 중복 쪼끔 제거하고 이러는것도 충분하다.

● 결론

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다. 즉, 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다. "코드감각"을 확실히 얻는다는 보장도 없다. 단지 이 책은 뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구를 소개할 뿐 ㅇㅇ

==>결국 나한테 달렸다는말임

이렇게 1장이 끝났습니다~~~예에

진짜 아니 읽는데 너무 구구절절 맞는말이라서 진짜...진짜...좋은 코드(=깨끗한 코드)를 짜야겠다고 생각이 들었습니다. 

2장은 "의미있는 이름"에 관한거에요. 

오늘도 도움이 되었으면 좋겠고! 진짜!!!!!꼭 사거나 빌리셔서 읽으셨으면 좋겠어요!!! 프로그래머라면 정말 1장부터 끄덕끄덕하면서 읽게 되실겁니다. XD