TIL (Today I Learned)

// 2022.01.22

오늘 읽은 범위

// 1장. 깨끗한 코드

책에서 기억하고 싶은 내용을 써보세요.

• 어떤 언어를 사용하든 코드는 기계가 이해하고 실행할 정도로 엄밀하고 정확하고 상세하고 정형화되어야 한다.

• 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법일 뿐만 아니라 전문가로서 살아남는 길이다.

• 비야네 스트롭스트룹

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

• 깨끗한 코드는 무엇일까? 비야네는 ‘보기에 즐거운’코드가 깨끗한 코드라고 한다. 즉 깨끗한 코드는 보는 사람에게 즐거움을 선사해야 한다는 뜻이다.

• 비야네는 나쁜 코드는 나쁜 코드를 ‘유혹’한다! 흔히 나쁜 코드를 고치면서 오히려 더 나쁜 코드를 만든다고 한다.

• 비야네는 철저한 오류 처리도 언급한다. 세세한 사항까지 꼼꼼하게 신경쓰라는 말이다. 예로 메모리누수, 경쟁 상태, 일관성 없는 명명법 이런 오류를 세세한 사항까지 꼼꼼하게 처리하는게 깨끗한 코드다.

• 마지막으로 비야네는 깨끗한 코드란 한 가지를 잘 한다고 단언한다. 무슨 말이냐 나쁜코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤섞이고 목적이 흐려진다. 깨끗한 코드는 한가지에’집중’한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다.

• 그래디 부치

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

• 그래디는 가독성을 강조한다. 깨끗한 코드가 잘 쓴 문장처럼 읽혀야 한다.

• 깨끗한 코드는 해결할 문제의 긴장을 명확히 드러내야 한다.

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

• ‘큰’데이브 토마스

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

• 데이브도 그래디와 마찬가지로 ‘가독성’을 강조하지만 한 가지 중요한 반전을 더한다. 데이브는 깨끗한 코드란 다른 사람이 고치기 쉽다고 단언한다.

• 테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. 아무리 코드가 우아해도, 아무리 가독성이 옾아도, 테스트 케이스가 없으면 깨끗하지 않다.

• 큰 코드보다 작은 코드에 가치가 더 있다.

• 요점은 인간이 읽기 좋은 코드를 작성하라.

• 마이클 페더스

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

• 한 마디로 요약하면 ‘주의’다.

• 마이클은 정곡을 찌른다. 깨끗한 코드는 주의 깊게 작성한 코드다. 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드다.세세한 사항까지 꼼꼼하게 신경쓴 코드다. 주의를 기울인 코드다.

• 론 제프리스

  론의 의견은 신중하게 고려할 가치가 있다. 코드에 중요한 순으로 나열하자면 1.모든 테스트를 통과한다. 2.중복이 없다. 3.시스템 내 모든 설계 아이디어를 표현한다. 4.클래스, 메서드, 함수 등을 최대한 줄인다. 물론 론 제프리스 본인은 중복에 집중한다. 같은 작업을 여러 차례 반복한다면 코드가 아이디어를 제대로 표현하지 못한다는 증거다. 나는 문제의 아이디어를 찾아내 좀 더 명확하게 표현하려 애쓴다.

  론에게 있어 표현력은 의미 있는 이름을 포함한다. 보통 론은 확정하기 전에 이름을 여러 차례 바꾼다. 하지만 표현력은 이름에만 국한 되지 않는다. 나는 여러 기능을 수행하는 객체나 메서드도 찾는다. 객체가 여러 기능을 수행한다면 여러 객체로 나눈다. 메서드가 여러 기능을 수행한다면 메서드 추출 리팩터링 기법을 적용해 기능을 명확히 기술하는 메서드 하나와 기능을 실제로 수행하는 메서드 여러 개로 나눈다.

  중복과 표현력만 신경 써도 (론이 생각하는) 깨끗한 코드라는 목효에 성큼 다가선다. 지저분한 코드를 손볼 때 이 두 가지만 고려해도 코드가 크게 나아진다. 하지만 나는 한 가지를 더 고려한다. 이는 설명하기 조금 까다롭다.

  오랜 경험 끝에 론은 모든 프로그램이 아주 유사한 요소로 이뤄진다는 사실을 깨달았다. 한 가지 예가 ‘집합에서 항목 찾기’다. 직원 정보가 저장된 데이터베이스든, 키/값 쌍이 저장된 해시 맵이든, 여러 값을 모아놓은 배열이든, 프로그램을 짜다 보면 어떤 집합에서 특정 항목을 찾아낼 필요가 자주 생긴다. 이런 상황이 발생하면 론은 추상 메서드나 추상 클래스를 만들어 실제 구현을 감싼다. 그러면 여러 가지 장점이 생긴다.

  이제 실제 기능은 아주 간단한 방식으로, 예를 들어 해시 맵으로, 구현해도 괜찮다. 다른 코드는 추상 클래스나 추상 메서드가 제공하는 기능을 사용하므로 실제 구현은 언제든지 바꿘도 괜찮다. 지금은 간단하게 재빨리 구현했다가 나중에 필요할 때 바꾸면 된다.

  게다가 집합을 추상화하면 ‘진짜’ 문제에 신경 쓸 여유가 생긴다. 간단한 찾기 기능이 필요한데 온갖 집합 기능을 구현하느라 시간과 노력을 낭비할 필요가 없어진다.

  중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기. 론에게는 이 세가지가 깨끗한 코드를 만드는 비결이다.

• 위 론의 얘기만으로 이 책 내용을 요약했다.

• 중복을 피하라. 한 기능만 수행하라. 제대로 표현하라. 작게 추상화하라.

• 워드 커닝햄

  코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면 깨끗한 코드라 불로도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름다운 코드라 불러도 되겠다.

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

• 명백하고 단순해 마음이 끌리는 코드가 깨끗한 코드다.

• 각 모듈은 다음 무대를 준비한다. 모듈을 읽으면 다음에 벌어질 상황이 보인다. 이만큼 깨끗한 코드는 너무도 잘 짜놓은 코드라 읽는 이가 그 사실을 모르고 넘어간다. 이는 코드를 어이 없을 정도로 단순하게 설계했기 때문이다.

• 워드는 “코드가 그 문제를 풀기 위한 언어처럼 보인다면”아름다운 코드라 말한다.

• 즉 언어를 단순하게 보이도록 만드는 책임이 우리에게 있다는 뜻이다!

• 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다!

다음

• 주변 코드를 읽지 않으면 새 코드를 짜지 못한다. 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다. 주변 코드를 읽기가 어려우면 새 코드를 짜기도 어렵다.

보이스카우트 규칙

• 잘 짠 코드가 전부는 아니다. 시간이 지나도 언제나 깨끗하게 유지해야한다.

• 캠핌장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

• 체크아웃할 대보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수이름 하나를 개선하고, 조금 긴 함수 하나를 분할하고, 약간의 중복을 제거하고, 복잡한 if문 하나를 정리하면 충분하다.

• 지속적인 개선이야말로 전문가 정신의 본질이 아니던가?

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 평소에는 문제를 풀든 뭘 하든 그냥 풀기만 하면 그만이었는데 이제는 이 책에서 설명하는 깔끔한 코드를 어떻게 하면 더 깔끔하게 코딩을 할 수 있을지 시간을 많이 들여야 겠다는 생각을 했다.

• 코딩을 하고 끝이 아니라 수없이 줄이고 고치고 개선 해야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

.