14장. 점진적인 개선 - 자바스크립트 클린코드

점진적인 개선(Progressive Improvement)

 

출발은 나쁘지 않았다. 그러나 소스가 방대해지면서, 확장성이 부족했던 모듈을 어떻게 개선해 나갈지에 대해 정리해보자.

 

처음에 코드를 작성할 때는 나름의 함수 그리고 변수명을 고려하여, 작성을 한다.

그러나 완성된 코드를 보면, 지저분하기 짝이 없었던 경험을 누구나 다 해봤으리라 짐작한다.

 

# 프로그래밍은 과학보다는 “공예”에 가깝다.

처음 부터 완벽한 작품을 만들기란 어려운 것이다. 거듭한 리팩토링 끝에 그나마 깨끗한 코드를 만들 수 있다.

 

우선 수정 작업에 들어가기 전, 1차 초안을 보며 자신을 되돌아본다.

내가 대충 짜서 방치해둔 코드를 다른 사람이 보게 되면 어떨지 항상 생각하면서 작성하는 습관을 들이자

 

# 점진적으로 개선하다

개선 이라는 명목하에 구조를 완전히 뒤바꾸는 것은 어리석은 행위이다.

TDD 도입을 통해 시스템 변경 전/후가 동일하다는 사실을 확인할 필요가 있다.

TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다.

검증하면서, 구조를 개선해야 올바른 방향이 될 수 있고, 확신을 가질 수 있다.

 

# 프론트엔드 관점

• 접근성: 콘텐츠는 모든 방문객이 이용할 수 있다.
• 휴대성: 크로스 브라우징 및 다양한 디바이스 지원.
• 모듈성: 구성 요소를 스마트 경계로 분리하면 사이트 구축이 쉽고 내결함성을 높일 수 있다.
• 사이트 성능: 페이지 로딩 시간(사용성에 영향을 미침)의 개선이 보다 쉽게 구현됨

- 궁극적인 목표 : html, css, js 를 분리하는 것

# 결론

나쁜 코드보다 최악인 건 없다

나쁜 일정은 다시 짜면 되고, 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 되지만, 나쁜 코드는 오래될 수록 복구가 어려워진다.

숨겨진 의존성을 찾아내 얽히고 설킨 코드를 풀어내려면 엄청난 시간과 비용, 그리고 인내심이 필요하다. 설사 시간과 비용을 투자했다고 한들, 의존성을 완벽하게 찾아내는 것도 어려울 것이다.

그러니, 시간이 없어서…라는 핑계를 대지 말고, 5분전에 작성한.. 혹은 오늘 오전에 작성한 코드를 지금 당장 끄집어내서 수정하자. 방치는 금물이다.