1장 깨끗한 코드
Xednicoder 🏆Front End Engineer
깨끗한 코드를 작성해냐 하는 목적과 원리에 대해서 알아보자.
1) 코드의 필요성#
문제제기 : 코드가 언젠간 사라질 것이다?- 코드란 요구사항을 상세하게 표현하는 수단이다.
- 앞으로 요구사항은 점점 더 복잡해지고 어려워질 것이다.
- 코드는 항상 존재할 것이다.
2) 나쁜 코드가 생겨나는 원리#
- 우리는 대충 짜둔 코드가 일단 돌아간다는 사실에 안도한다.
- 그리고 "꼭 다시 돌아와서 수정해야지" 라고 생각한다
- 그러나 "나중은 오지 않는다"
3) 나쁜 코드로 치르는 대가#
토론 : 책의 내용을 같이 고민해보자- 나쁜 코드가 쌓일수록 팀 생산성이 점점 떨어진다.
- 생산성이 0이 되는 시점에 원대한 재설계를 고민해야 한다.
- 재설계로 들어간 거대한 비용이 레거시를 운영하는 것 보다 더 비용이 절감된다.
- 나쁜 코드가 쌓인 이유를 우리는 외부에서 찾는다. (일정 촉박, 멍청한 관리자, 마케팅 등등)
- 나쁜 코드의 위험함을 이해하지 못하는 관리자의 말을 따르는 행동은 전문가답지 못하다. (전문가라는 단어에 대한 정의)
- 빨리 가고자 하는 이유에서도 클리한 코드가 유리하다.
4) 클린한 코드는 어떻게 작성할까?#
(1) 바야네 스트롭스트룹 [우아한 코드]#
- "보기에 즐거운 코드"
- 의존성이 적은 코드(유지보수)
- 성능과 효율성(바쁜 코드로의 유혹에 빠지지 않는다)
- 철저한 오류처리(메모리 누수, 경쟁 상태, 일관성 없는 명명법)
(2) 그레디 부치 [가독성]#
- "명쾌한 추상화"
- 구체적인, 사실에 기반한, 단호한 코드
(3) 큰 데이브 토마스 [가독성 + 의존성 최소 단위]#
- 고쳐쓰기 쉬운 코드
- 테스트 케이스
- 문학적(?)
(4) 마이클 페더스 [주의]#
- 주의 깊게 작성한 코드 (
이런 얘긴 나도 할 수....)
(5) 론 제프리스 [중복, 표현, 추상화]#
- 중복을 제거 (변수, 메서드, 클래스, 함수 모두를 포함)
- 설계 아이디어를 모두 표현한다(ex : 의미있는 이름으로 자주 바꾼다)
- 집합의 추상화로 진짜 문제에 집중
(6) 워드 커닝햄 [직관적인 표현]#
- 단순, 명백한 코드
(7) 이 책의 저자#
- 읽기 쉽게 만들어야한다
- 보이스카웃규칙(점점 더 나아지는 코드)
- 우린 책을 통해 많은 예시를 보여줄게 "넌 더 노력해"
5) 단원 정리#
가독성이 좋은 최소 단위의 코드로 작성하자 유지 보수가 편한 테스트가 간편한 코드로 작성하자 우리의 목표를 해결하기 위한 최적의 코드로 진화시키자 (리펙토링 맨날 하란 얘기)