Chean code chapter 1
- 1. Clean Code Ch.1 클린코드 chois79 12년 7월 14일 토요일
- 2. 목차 • 코드가 중요한 이유 • 나쁜 코드가 문제인 이유 • 클린 코드 정의 및 작성법 12년 7월 14일 토요일
- 3. 코드가 존재하리라 • 코드를 다루는 책이라니? • 시대 착오적 생각? <== No • 코드는 요구 사항을 상세히 표현하는 수단 • 어느 수준에 이르면 상세 표현은 불가피 12년 7월 14일 토요일
- 4. 나쁜 코드 • 톰 홀웨다(http://www.osnews.com/story/19266/WTFs_m) • 코드 품질을 측정하는 유일한 척도 = 분당 내지르는 WTF! 횟수 • 왜 나쁜 코드가 생성 되는가? • 급해서? 서두르느라? 나중에 수정? • 르블랑의 법칙: “나중은 결코 오지 않는다” 12년 7월 14일 토요일
- 5. o way at all. As the mess builds, the productivity of the team continues to decrease, asymptotically roaching zero. As productivity decreases, management does the only thing they can; y add more staff to the project in hopes of increasing productivity. But that new staff is 나쁜 코드로 치르는 대가 versed in the design of the system. They don’t know the difference between a change t matches the design intent and a change that thwarts the design intent. Furthermore, y, and everyone else on the team, are under horrific pressure to increase productivity. So y all make more and more messes, driving the productivity ever further toward zero. e Figure 1-1.) • 점진적인 생산성 저하 Figure 1-1 • 그럼 기존 시스템을 처음부터 다시 만들면 될까? Productivity vs. time • 새 시스템이 개발되는 동안 기존 시스템에 변경이 가해짐 • 결국, 두 시스템 간의 차이를 없애는데 많은 시간이 소요 됨. 12년 7월 14일 토요일
- 6. 무엇이 문제인가? • 좋은 코드가 왜 나쁜 코드로 변할까? • 설계를 뒤집는 방향으로 변경된 요구사항 때문에? • 일정이 촉박해서? • 조급한 고객 및 관리자 때문에? • No, 프로그래머가 전문가 답지 못했기 때문이다 • 좋은 코드를 사수하는 것은 프로그래머의 책임 • 나쁜 코드는 오히려 업무 속력을 떨어 뜨린다 12년 7월 14일 토요일
- 7. 클린 코드라는 예술 • 클린 코드를 어떻게 작성할까? • 나쁜 코드 식별 능력이 클린코드 작성 능력은 아님 • “청결”이라는 감각으로 자잘한 기법들을 적용하는 절제와 규율이 필요 • “코드 감각”이 중요 12년 7월 14일 토요일
- 8. 클린 코드 정의 • 비야네 스트롭스트룹 - C++ 창시자 • 나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의 거해 철저히 처리한다. 성능을 최적으로 유지해야 사람들이 원칙 없는 최적화로 코드를 망치려는 유혹에 빠지지 않는다. 클린 코드는 한가지를 제대로 한 다 • 그래디 부치 - “Object Oriented Analysis and Design with Application” • 클린코드는 단순한고 직접적이다. 클린코드는 잘 쓴 문장처럼 읽힌 다. 클린코드는 결코 설계자의 의도를 숨기지 않는다. 오히려 명쾌한 추상화와 단순한 제어문으로 가득한다. 12년 7월 14일 토요일
- 9. 클린 코드 정의 • 데이브 토마스 - OTI 창립자이자 이클립스 전략의 대부 • 클린 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 단위 테스트 케이 스와 수용 테스트 케이스가 존재한다. 의미 있는 이름이다. 특정한 목적을 달성 하는 방법은 (여러가지가 아니라) 하나만 제공한다. 의존성은 최소이며 각 의존 성을 명확히 정의한다. API는 명확하며 최소로 줄였다. 때로는 필요한 정보 전부를 코드만으로 명확하게 드러내기 어려우므로 언어에 따라 문학적 표현이 필요하다. • 론 제프리 - “Extreme Programming Installed” • 모든 테스트를 통과한다. 중복이 없다. 시스템 내 모든 설계 아이디어 를 표현 한다. 클래스, 메소드 함수 등을 최대한 줄인다. 12년 7월 14일 토요일
- 10. 클린 코드 정의 • 마이클 페더 - “Working Effectively with Legacy Code” • 클린 코드가 보이는 특징은 많지만 그 중에서도 모두를 아우르는 특징이 하나 있 다. 클린 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다. 고치려고 살 펴봐도 딱히 솔 댈 곳이 없다. 작성자가 이미 모든 사항을 고려했으므로 고칠 궁 리를 하다보면 언제나 제자리로 돌아온다. 그리고는 누군가 남겨준 코드, 누군가 주의 깊게 짜 놓은 작품에 감사를 느낀다. • 워드 커닝엄 - 위키 창시자, 익스트림 프로그래밍 공동 창시자 • 코드를 읽으며 짐작했던 기능을 각 루틴이 그대로 수행한다면 클 린 코드라 불러도 되겠다. 코드가 그 문제를 풀기 위한 언어처럼 보인다면 아름 다운 코드라 불러도 되겠다. 12년 7월 14일 토요일
- 11. 저자의 생각 - 엉클 밥 • 이 책은 오브젝트 멘토 진영의 생각을 반영 • 책에 전반적으로 자세히 표현 • 읽기 쉬운 코드가 매우 중요 • 개발 과정에서 코드 읽기와 작성의 비율은 10:1이상 • 보이 스카우트 규칙 • “캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라” • 코드를 잘 짰다고 끝나는 것이 아니라 항상 깨끗하게 유지하는 것이 중요! 12년 7월 14일 토요일