18. 변하지 않는 것은 없다.

항상 시간이 해결해 준다고들 하지만, 실제로는 당신 스스로 변하게 만들어야 한다. –앤디 워홀

 

제품이 출시 되고 난 뒤의 소프트웨어 내부 구조는 더 이상 다뤄서는 안 되는 것으로 취급된다. 바깥 세계의 모든 인터페이스는 신성시 되고 절대 수정할 수 없게 된다.

이것은 바로 두려움 때문이다. 잘못될지도 모른다는 두려움과 어떤 것을 깨뜨려야 한다는 두려움, 추가 업무에 대한 두려움과 수정 비용에 대한 두려움 등이 있다.

우리는 아직 완벽하게 알지 못하는 코드를 바꿔야할 때 현실적 불안감을 느낀다. 만약 철저하게 이해하지 못한 로직이 있거나, 자신이 무엇을 하고 있는지에 대한 확신이 없거나, 변화에 따른 모든 가능한 결과를 알지 못할 경우 특이한 코너 케이스에 대한 처리를 변경하여, 제품에 미묘한 버그를 만들어 낼 수도 있다.

소프트웨어는 단단하지 않고 부드러워야 한다. 그러나 프로그래머는 두려움을 느끼고 코드를 깨뜨리지 않도록 하려다 보니, 코드를 단단히 얼에 붙게 만든다.

즉 코드는 변해야 한다. 제품 중에 불변의 코드가 있다면 그 소프트웨어는 썩어 버릴 것이다.

세상 어떠한 코드도 완벽할 순 없다. 세상은 끊임 없이 변화한다. 코드가 부지런히 세상의 요구 사항에 맞춰 나간다 해도, 요구 사항은 언제나 끊임없이 변화한다. 오래된 코드는 끊임없이 새로운 버그를 만들어낼 것이다. 수정하는 것에 두려워하지 말자.

자신이 작성한 소프트웨어의 주인은 바로 자신이다. 소프트웨어는 자신의 지배하에 있다. 코드나 개발 절차를 풀어두지 말고 코드가 성장하는 방향을 지배하자.

 

1. 용감한 수정

거대한 소프트웨어 프로젝트는 숙달해야 하는 무수한 미묘함과 복잡함을 내포한다. 우리는 뭇모한 수정을 통해 버그를 만들어내기를 원하지 않는다.

어떻게 하면 오류에 대한 두려움 속에서 용기 있게 수정할 수 있을까?

•         좋은 수정을 가하는 방법을 배우자. 작업의 안정성을 높이고 오류의 가능성을 줄일 수 있는 실천 방법이 존재한다.

•         소프트웨어를 쉽게 바꿀 수 있게 만드는 것이 무엇인지 배우고, 이런 특성을 가진 소프트웨어를 만들기 위해 노력하자.

•        매일 코드를 개선하여 더욱 수정이 용이한 상태로 만들자. 코드의 품질에 대해서는 타협을 거부하자.

•         건강한 코드로 이끄는 건강한 태도를 포용하자.

     결국 하고자 하는 말은 대담하게 수정하자는 것이다. 실패할지도 모르고 잘못될 수도 있다. 그러나 언제든지 코드를 정상적인 상태로 되돌릴 수 있으므로 다시 시도하면 된다.

시도하는 것은 부끄러운 일이 아니며 실수로부터 항상 배울 수 있다.

수정에 필요한 거은 무모함이 아니라 용기와 기술이다.

 

2.태도바꾸기

건강한 코드 수정을 위해 올바른 태도를 취해야 한다.

코딩 시 두려움이 많은 겁쟁이 같은 접근법을 취한다면 목표에 이르지 못할 것이다. 오래 묵은 코드는 정체되고, 새로운 방랑자가 그 주변을 더 어지럽힌다.

좋은 코드는 다른 사람의 문제가 아니다. 자신의 책임이다. 당신에게는 변화와 개선을 일으킬 수 있는 힘이 있다.

-      잘못되거나 위험한 코드, 나쁘거나 중복되거나 불쾌한 코드를 수정하는 것은 혼란이나 탈선 혹은 소중한 시간의 낭비가 아니다

-      리팩토링을 권장한다. 올바른 동작을 위해 코드의 근본적인 부분을 고쳐야 하는 작업이라면 팀 전체가 리팩토링이 필요하다는 것을 이해하고 그러한 문제는 시간이 더 걸린다는 것을 이해해야 한다.

-      누구도 코드의 어떤 영역을 소유하고 있지 않다. 누구든 코드의 어떤 부분이든 수정할 수 있다. 코드에 대한 편협한 취향을 피하자.

-      의도치 않게 실수를 하거나, 잘못된 코드를 작성하는 것은 범죄가 아니다.

-      어떤 사람의 의견을 다른 사람의 의견보다 중요하게 여겨서는 안 된다. 어떤 사람의 코드를 다른 사람의 코드보다 더 정확 하거나 보다 나은 것으로 취급하는 것은 코드를 거짓된 기초 위에 세우는 것이며, 팀의 나머지 사람들의 기여를 손상시키는 것이다.

-      좋은 프로그래머는 변화를 기대한다.

 

 

3. 수정하기

중요한 것은 코드를 해석하는 방법을 배우는 것이다. 부작용이 숨어 있는 곳을 찾아내고, 따라가고, 잘못된 지점이 튀어나오는 지점을 파악하는 방법을 배워야 한다.

3-1. 수정을 위한 설계

우린 수정을 장려하는 코드를 위해 노력한다. 모양과 의도를 드러내고 간결함과 명확함, 일관성을 표방하는 코드들이다. 반면 코드를 수정할 때 불안정하다는 이유로 부작용이 있는 코드를 피한다. 만약 두 가지 기능을 하는 함수를 만났다면 두 부분으로 나누자, 함축적인 것은 명백히 하고 융통성 없는 결합과 불필요한 복잡함을 피하자.

한 번에 전체 코드베이스와 싸우려 하지 말자. 위협적이고, 고치기 어려운 일이 될 것이다 그 대신 변경해야 하는 제한된 영역을 정한 뒤 그것을 손보는 데 집중하자

 

3-2. 수정을 위한 도구

좋은 도구는 가장 빠른 속도로 안전하게 변경하는 데 도움이 된다. 훌륭한 자동화 테스트 도구는 신속하고 제대로 일할 수 있도록 도와준다 이러한 도구는 수정된 부분이 무엇을 망가뜨리는지에 대해 빠르고 믿을 만한 피드백을 준다.

개발의 중요한 요소로 지속적 통합을 꼽을 수 있다 이는 지속적으로 소스를 체크아웃하고 코드의 가장 최근 버전을 빌드하는 서버이다. 어떤 악질적 요소가 몰래 침투하여 빌드를 고장 내도 재빨리 발견할 수 있을 것이다.

 

3-3 싸워야 할 때를 가리자.

새로운 작업을 추가하는 동시에 모든 코드를 고치는 것은 불가능하다. 언제나 불쾌한 코드를 발견하지만, 고치고 싶어도 지금 당장 고칠 수 없는 경우가 대부분이다. 작업이 지나치게 광범위할 수도 있다. 혹은 대규모의 리팩토링을 필요로 할 수도 있다.

추후 개선할 때까지 감수해야 할 기술 부채의 일정량이 존재한다. 이는 프로젝트 계획에 포함되어야 한다. 부채의 상당수가 그대로 잊히고 곪아가도록 버려두기보다는 개발 일정표에 넣어 작업 대상으로 만들어야 한다.

 

4. 변경하면 할수록

동시다발적인 변화를 따라가는 것은 매우 어려울 뿐더러 악몽과도 같은 일이다. 따라서 많은 것을 동시에 처리하지 말고 하나씩 처리하자.

그러나 코드가 변한다는 사실 역시 받아들여야 한다. 가만히 있는 코드는 부채나 다름없다 그 어떤 코드도 변경을 피할 수는 없다 두렵다고 해서 코드의 어떤 부분을 피해야 하는 것으로 취급한다면 오히려 역효과만 날 뿐이다.