-
Notifications
You must be signed in to change notification settings - Fork 2
Chapter 01. Clean Code
2021.07.10 (SAT) 10:20-12:00 (100mins)
🚀 Lead by. 'Jeongyeol'
여러분이 이 책을 읽고 있다면 이유는 두 가지다. 첫째, 프로그래머라서. 둘째, 더 나은 프로그래머가 되려고.
다행이다! 우리 업계는 더 나은 프로그래머가 필요하니까.
이_책을_읽으면_얻을_수_있는_것들:
- "코드에 관련된 많은 사실"
- "좋은 코드와 나쁜 코드를 구분하는 능력"
- "좋은 코드를 작성하는 방법"
- "나쁜 코드를 좋은 코드로 바꾸는 능력"Q. 기술이 계속 발전해서 코드가 자동으로 작성될텐데, 프로그래머가 굳이 깨끗한 코드를 알아볼 필요가 없지 않나?
A. Absolutely No!!
코드는:
- "기계를 동작시키는 프로그램 구성"
- "모델이나 요구사항을 실제로 구현한 결과"
- "고도화되는 추상화되어도 복잡해져도 결국 기계를 동작시키는 것"
- "특정 분야에 적합한 프로그래밍 언어(Domain-specific Language)가 늘어나도, 결국 코드"
# 코드는 기계가 이해하고 실행할 정도로 엄밀하고 정확하고 상세하고 정형화되어 작성되어야 한다.# 언젠가 코드가 사라지리라 생각하는 사람들에게..
그건_헛된_꿈이야: |
요구사항을 모호하게 줘도 우리의 의도를 정확히 꿰뚫어 프로그램을 완벽히 실행하는 기계?
그것은 불가능의 영역이다. (창의력과 직관을 보유한 인간이 고객의 막연한 감정만 갖고 성공한 시스템을 구현하지 못하는 것과 비슷)
제대로 명시한 요구사항은 코드만큼 정형적이며, 테스트 케이스로 사용해도 좋은 상태를 의미
# 궁극적으로, 코드는 요구사항을 표현하는 언어라는 사실을 이해하라."우리는 모두 좋은 코드가 중요하다는 사실을 안다. 왜? 오랫동안 나쁜 코드에 시달려왔으니까."
killer_app:
80년대_후반: |
출시되어 큰 인기를 끌었으나, 프로그램에 버그가 하나둘 쌓여감
다음 버전이 출시되어도 버그는 늘어나고, 시동 시간이 길어지고, 죽는 횟수도 점차 증가..
저자 마틴 파울러는 화가나서 프로그램을 꺼버렸고 다시는 켜지 않았다.(!)
회사는 얼마 가지 못해 망했다.(!)
20년_후에: |
그 회사의 초창기 직원에게 들은 자초지종은..
당시에는 출시에 바빠 코드를 마구 짰다.
기능을 추가할수록 코드가 엉망이 되었다.
결국 감당이 불가능한 수준에 이르렀다.
결국_회사가_망한_원인은:
바로 나쁜 코드 탓이었다.프로그래머라면 누구나 나쁜 코드로 고생한 경험이 있다...😡
어째서_나쁜_코드를_짰는가:
- "급해서;; 👎"
- "서두르느라ㅠ 👎"
- "제대로 짤 시간이 없다고 생각해서.. 👎"
- "코드를 다듬느라 시간을 보냈다가 상사에게 욕 먹을까봐ㅠ 👎"
- "지겨워서 빨리 넘어가고! 👎"
- "다른 업무가 너무 밀려 후딱 해치우고 밀린 업무로 넘어가려고 👎"
- "..... 👎👎👎👎👎"
- "...!! 😡😡😡😡😡"
---
혹시_이런적은: |
자신이 짠 쓰레기코드를 쳐다보면서, 나중에 손보겠다고 생각하진 않았는가?
대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며...
안 돌아가는 것보다는 쓰레기 코드가 낫지, 하고 안도감을 느낀적은 없는가?
---
# 르블랑의 법칙
leblanc_s_law: "나중은 결코 오지 않는다"- 나쁜 코드는 개발속도를 크게 떨어뜨린다.
이런_경험_혹시:
- "남들이 저질러놓은 쓰레기 코드로 고생한 경험이 있으리라.."
- "코드가 하도 엉망이라 프로젝트 진도가 안나가는 경험도 있으리라.."- 만드는 것보다 고치는게 훨씬 어렵다.
왜_그럴까:
# ❓
만들_때는: "빨랐는데..?"
# ⁉️
코드를_고칠_때_마다:
- "엉뚱한 곳에서 문제가 생긴다."
- "얽히고 섥힌 덩쿨같은 코드를 '해독'해서 짠 코드는 '더 얽힌 코드'가 된다."
# 😡
시간이_지나면:
- "쓰레기(코드) 더미는 점점 높아지고, 깊어지고, 커진다."
- "청소할 방법이 없다"
- "불가항력이다."- 나쁜 코드가 쌓일 수록 팀 생산성은 떨어진다. 마침내 0에 근접한다.
관리층도_나름:
복구를_시도해본다:
어떻게?: "생산성 향상이라는 희망으로 인력 투입!" # Jesus..;
그런데_새_인력은:
시스템_이해도가: "없거나 낮다." # Fxxk..;;;
더불어: "생산성을 올려야한다는 극심한 압력은 덤" # Sxxt..;;;- 덕분에(?) 생산성은 더더욱 떨어져 결국 거의 0이 된다.
(팀)
"이따위 코드로 더이상 일 못하겠다ㅏㅏㅏㅏㅏㅏ"😡
"재설계합시다! 제발!!!"😡
(관리자)
'재설계에 시간과 자원을 사용하는건 아까운데.. 생산성이 바닥이라는건 동의해..'
"네, 허가합니다. 재설계 진행하세요"😔
-
새로운 타이거 팀 구성: 기존 인력에서 가장 유능하고 똑똑한 사람이 차출 (나머지는 현재 시스템을 유지보수)
-
대환장 레이싱
- 기존 기능을 모두 지원하는 새로운 프로그램 개발
- 그동안 시스템에 이루어지는 유지보수 변경점 커버
- 왜? 기존 기능을 완벽하게 대체할 수 없다면, 관리팀은 전환할 수 없으니까..
{
// 혹시..
"조금이라도": "자신의 이야기의 일부인것 같다면?",
// 이 책에서 이야기할
"깨끗한 코드를 작성하는 노력은": [
"비용을 절감하는 것",
"전문가로서 살아남는 것"
] // 이라는 사실을 인정할 것이다.
}<bad_code>
"어째서 이 코드는 나쁜 코드가 되었는가?"
</bad_code>
<!--
나쁜 코드로 분노한 아무개
몇시간이면 다 할 코드 변경인줄 알았는데,
하.. 열고보니 이거 몇 주는 족히 걸리겠는데? 허 참.. 지뢰밟았네..
조금만 고치면 될 줄 알아서 시킨거 하겠다했는데, 수백줄을 고쳐야하네.
아.. 이와중에 왜 아직 못했냐고 욕하네.. 아 젠장..
-->프로그램을 동작시키던 '코드'가 순식간에 '나쁜 코드'로 변하는 순간들
- 원래 설계를 뒤집는 방향으로 요구사항이 나올 때
- 일정이 촉박해 제대로 할 시간이 없어서 코드가 부족할 때
- 고객이 책임을 전적으로 프로그래머에게 지울 때
(억울..)
이런 상황에서 프로그래머는..?
- 마케팅은 약속과 공약이 있다며 정보와 기능 구현을 닥달한다.
- 사용자는 요구사항을 뿌리며 구현가능한 현실성을 자문한다.
- 관리자는 일정을 잡으며 도움을 요청한다.
- 더.. 더 깊게 프로젝트에 관여한다.
- 프로젝트 실패에 대한 커다란 책임이 있다.
- 나쁜 코드가 초래하는 실패는 더더욱 책임이 크다
// 환자가 빨리 치료해달라고 손씻는 시간이라도 줄여서라도
console.error(
"나쁜 코드의 위험을 이해하지 못하는 관리자의 말을" +
"그대로 따르는 프로그래머의 행동은 전문가답지 못하다"
);우리는:
나쁜코드가: "업무 속도를 떨어뜨린다는걸 잘 안다."
알지만:
기한을_맞추려면: "나쁜 코드를 양산할 수 밖에 없다고 느낀다."
그저:
빨리_하려고: "시간을 들이지 않기 때문일 것이다."
# 전문가라면, 이 말이 틀렸다는걸 바로 알 것이다.
기한을_맞추는:
유일한_방법은:
- "그러니까, 빨리 가는 유일한 방법은"
- "언제나 코드를 깨끗하게 유지하는 습관이다"// 1. 나쁜 코드는 심각한 장애물이다! 라는 사실을 납득했다.
// 2. 빨리 가려면 코드를 깨끗하게 유지해야한다. 라는 사실도 인정했다.
// 그렇다면..?
system.out.println("깨끗한 코드는 어떻게 작성할까?");깨긋한 코드에 대한 선배 거장들의 생각을 들여다보자.
"
논리적으로 간단해야 버그가 숨어들지 못한다.
의존성을 최대한 줄여야 유지보수가 쉬워진다.
오류는 명백한 전략에 의거해 철저히 처리한다.
깨끗한 코드는 한 가지를 제대로 한다.
"
"
깨끗한 코드는 단순하고 직접적이다.
깨끗한 코드는 잘 쓴 문장처럼 읽힌다.
깨끗한 코드는 결코 설계자의 의도를 숨기지 않는다.
오히려 명쾌한 추상화와 단순한 제어문으로 가득하다.
"
"
깨끗한 코드는 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
단위 테스트 케이스와 인수 테스트 케이스가 존재한다.
깨끗한 코드에는 의미있는 이름이 붙는다.
특정 목적을 달성하는 방법은 (여러가지가 아니라) 하나만 제공한다.
의존성은 최소이며 각 의존성을 명확히 정의한다.
API는 명확하며 최소로 줄였다.
언어에 따라 필요한 모든 정보를 코드만으로 명확히 표현할 수 없기 때문에,
코드는 문학적으로 표현해야 마땅하다.
"
"
깨끗한 코드의 특징은 많지만
그중에서도 모두를 아우르는 특징이 하나 있다.
깨끗한 코드는 언제나 누군가 주의 깊게 짰다는 느낌을 준다.
고치려고 살펴봐도 딱히 손 댈 곳이 없다.
작성자가 이미 모든 사항을 고려했으므로,
고칠 궁리를 하다보면 언젠가 제자리로 돌아온다.
그리고 누군가 남겨준 코드, 누군가 주의 깊게 짜놓은 작품에 감사를 느낀다.
"
"
켄트 백이 제안한 단순한 코드 규칙으로 구현을 시작했다.
중요한 순으로 나열하자면, 간단한 코드는
1. 모든 테스트를 통과한다.
2. 중복이 없다.
3. 시스템 내 모든 설계 아이디어를 표현한다.
4. 클래스, 메서드, 함수 등을 최대한 줄인다.
"
"
코드를 읽으면서 짐작했던 기능을 각 루틴이 그대로 수행한다면
깨끗한 코드라 불러도 되겠다.
코드가 그 문제를 풀기 위한 언어처럼 보인다면
아름다운 코드라 불러도 되겠다.
"
절대적으로 옳은 문파는 없다!!
이 책은 우리 오브젝트 멘토 진영이 생각하는 깨끗한 코드를 설명한다.
여기서 가르치는 교훈과 기법은 우리 진영이 믿고 실천하는 교리이다.
이 기법을 따른다면 우리가 느끼는 이익을 만끽하고, 깨끗하고 수준 높은 코드를 작성하리라.
우리가 '옳다'는 단정은 금물이다.
코드를 짜는 동안, 우리는 코드를 끊임없이 기존 코드를 읽는다. 비율이 거의 10:1을 훌쩍 넘긴다.
이렇게 높은 비율을 '읽기'에 치중하고 있으니, 깨끗한 코드가 생산성에 중요한 영향을 끼치는건 당연하다.
그러니:
급하다면:
서울러_끝내려면:
쉽게_짜려면: |
읽기 쉽게 만들면 된다! 😎
시간이 지나도 언제나 깨끗하게 유지해야한다. 그러나, 시간이 지날수록 엉망이 되는 코드는 계속 늘어난다.
{
"미국_보이스카우트_규칙": "캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라",
"우리_전문가들에게도_유용": [
"checkout(코드의 상태를 보러 진입)할 때보다",
"좀 더 깨끗한 코드를 checkin(코드의 상태를 변경)한다면",
"코드는 절대 나빠지지 않는다."
// 지속적인 개선이야말로 전문가 정신의 본질
]
}-
예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다.
그 책은 단지 도구, 기법, 사용법만 알려줄 뿐. -
이 책을 읽는다고 해서 뛰어난 프로그래머가 된다는 보장은 없다.
단지 뛰어난 프로그래머들이 생각하는 방식과 기교, 도구를 설명할 뿐이다. -
좋은 코드와 나쁜 코드의 예제가 함께 나오고 개선하고 열거해서 비교한다.
-
읽고 이해만 할지, 연습할지, 얻고 갈지는 결국 "읽고 있는 당신의 선택"이다.