1장. 깨끗한 코드

깨끗한 코드를 작성하는 방법은 배우기 어렵다.

단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다.
(생각해보면 패턴은 그저 도움을 주기 위해 이런게 있다뿐, 어떠한 법칙 같은 것이 아니다...)

코드가 존재하리라

프로그래밍은 요구사항을 명시하는 작업이다.
또한 코드는 요구사항을 상세히 표현하는 수단이다.

언젠가 코드를 자동으로 생성하는 시대가 오더라도 프로그래머는 사라지지 않는다고 한다.

이유를 설명하기 위해 저자는 코드를 수학에 비유한다. 코드가 사라진다는 것은 비정형적인 수학이 나오리라 기대하는 수학자와 비슷하다고 표현한다.

또한 고객이 원하는 서비스를 정확히 구현하기 위해서는 어느정도 ai의 도움을 빌릴 수 있겠지만, 이 또한 마무리는 사람이 직접 해야 한다.

결국 프로그래머는 사라질 수 없다. (아직 치킨집 안해도 되겠네 ㅎ)

프로그래밍 언어에서 추상화 수준을 계속 높아질 것이다.

나쁜 코드

나쁜 코드는 회사를 망하게 할 수도 있다.

• 버그가 남아 있고, 프로그램이 죽는 횟수가 늘어남
• 출시에 바빠 코드를 마음대로 짜고, 기능을 추가할 수록 엉망이 됨

코드를 잘 짜야하는 좋은 이유는 여러가지가 있겠지만 그 중에 하나를 꼽자면 르블랑의 법칙이 있다.

르블랑의 법칙

나중은 결코 오지 않는다.

나쁜 코드로 치르는 대가

개발 속도를 크게 떨어뜨린다.

나쁜 코드일수록 코드를 읽는 것이 아닌 해독을 하게 된다.

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

나쁜 코드는 재설계를 하게 만들고, 재설계 또한 추가기능을 따라잡느라 재재설계를 하게 될 수도 있다.

처음부터 잘 짜자.

특히 요즘 일하면서 느낀다... 처음부터 잘 짜놔야 나중에 코드를 다시 읽는 시간이 정~말 많이 줄어든다.

일단 개발하면서 생각하는게 아니라, 구체적으로 구조를 어떻게 가져갈지 생각하는게 중요하다고 느낀다.

리팩토링...?

개인적으로... 리팩토링은 개발의 중점사항이라고 생각한다.

아무리 코드를 클린하게 짜려고 노력해도 리팩토링은 할 수 밖에 없다.

책에서는 메서드 추출이라는 리팩터링 기법을 이용해서 메서드를 여러개로 나누는것도 좋다고 한다.

중복과 표현력만 신경써도 깨끗한 코드라는 목표에 성큼 다가선다.

특히 글쓴이는 추상 클래스나 추상 메서드를 만들어 실제 구현을 감싸는데, 이렇게 하면 '진짜' 문제에 신경 쓸 여유가 생긴다고 한다.

즉 가장 중요한 것들은,

• 중복 줄이기
• 표현력 높이기
• 초반부터 간단한 추상화 고려하기

라고 한다.

초반부터 간단한 추상화를 고려할수록, 메서드간의 의존성이 적은 자그만한 함수들이 많이 생긴다.

그것들을 이용해서 기능교체가 쉬워지는 여러 기능을 수행하는 메서드를 만들 수 있을텐데... 개인적으로 굉장히 좋은 방법이라고 생각한다.

짐작 가능하고 단순한 코드가 깨끗한 코드다.

그렇다. 말 그대로다. 코드를 독해할 일이 줄어들수록 단순할수록 깨끗한 코드다.

단순해서 짜기 쉬워보일수도 있지만, 그렇게 짜기까지 얼마나 많은 노력이 필요한지 알듯 모를듯 하다....