diff --git "a/14\354\236\245/\352\263\265\354\230\210\354\230\201.md" "b/14\354\236\245/\352\263\265\354\230\210\354\230\201.md"
new file mode 100644
index 0000000..dc06bdf
--- /dev/null
+++ "b/14\354\236\245/\352\263\265\354\230\210\354\230\201.md"
@@ -0,0 +1,14 @@
+**📕Ch14. 점진적인 개선**
+
+> 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다.
+
+> 나쁜 코드는 썩어 문드러진다. 코드가 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다. 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다.
+
+> 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다.
+
+
+이번 장은 Java 기반 객체지향 프로그래밍의 리팩터링 예시가 중심이라, 아직 완전히 와닿지는 않았다. 시간을 두고 다시 읽으며 객체지향 코드를 더 깊게 이해하고 싶다. <br>
+다만, 새로운 인수를 추가하면서 코드가 복잡해지는 문제는 프론트엔드 함수형 프로그래밍에서도 쉽게 마주친다. 예를 들어 컴포넌트를 설계하다 보면 props가 방대해지고 관리가 어려워진다. 이때 합성 컴포넌트 패턴으로 전환하고 Context API를 도입해 구조를 단순화하는 방식을 적용할 수 있다.<br>
+
+프론트엔드 코드는 디자인 변경, API 스펙 수정, 신규 기능 추가 등 잦은 변화에 노출된다. 변화가 많을수록 누구나 쉽게 이해하고 수정할 수 있도록 작성하는 것이 중요하다. <br>
+책에서 강조한 것처럼, 테스트는 리팩터링을 두렵지 않게 만드는 안전망임을 다시 한 번 느꼈다.