diff --git "a/14\354\236\245/\355\231\251\353\217\231\354\244\200.md" "b/14\354\236\245/\355\231\251\353\217\231\354\244\200.md"
new file mode 100644
index 0000000..e248738
--- /dev/null
+++ "b/14\354\236\245/\355\231\251\353\217\231\354\244\200.md"
@@ -0,0 +1,24 @@
+## 14장 점진적인 개선
+
+<254p><br/>
+일단 진정하기 바란다. 나는 위 프로그램을 처음부터 저렇게 구현하지 않았다. 더욱 중요하게는 여러분이 깨끗하고 우아한 프로그램을 한 방에 뚝딱 내놓으리나 기대하니 않는다.
+~ 프로그래밍은 과학보다 공예에 가깝다는 사실이다. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.
+
+일단 프로그램이 돌아가면 다음 업무로 넘어간다. 돌아가는 프로그램은 그 상태가 어떻든 그대로 버려둔다. 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.
+
+<270p><br/>
+프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. 어떤 프로그램은 그저 그런 개선에서 결코 회복하지 못한다. '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다.
+
+<295p><br/>
+다음 변경은 10단계에 걸쳐 이뤄졌다. 물론 단계다마 코드는 테스트를 통과했다.<br/>
+=> 테스트에 대한 중요성을 알려주는 맥락이라고 생각해요. 그만큼 코드를 이상 없이 변경하기 위해선 테스트 코드가 필수적이라는 생각이 드네요.
+
+<321p><br/>
+그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례는 흔하다. 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다.
+
+나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다. ~ 하지만 나쁜 코드는 썩어 문드러진다.<br/>
+=> 항상 코드를 작성하고 기능을 구현할 때, 고려해야 하는 내용인거 같습니다.
+
+코드는 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다.
+
+반명 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다. 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다. 더욱이 5분 전에 엉망으로 만든 코드는 지금 당장 정리하기 아주 쉽다.