💉 팬데믹 상황에서 배우는 리팩토링<!-- --> | <!-- -->identity16
Book

💉 팬데믹 상황에서 배우는 리팩토링

2022-02-12

Featured Image

혼자 코딩 vs 회사 코딩

학생일 때와 개발자가 되어 회사에 다닐 때 체감되는 차이점이 뭐냐고 한다면
나는 수많은 사이드 이펙트를 고민하게 되는 것라고 할 것이다.

혼자 코딩

우리가 공부를 위해 프로젝트를 할 때를 생각해보자.

  1. 만들고 싶은 프로그램/서비스를 정한다
  2. 구현하는 데 필요한 언어/프레임워크를 공부한다.
  3. 새 프로젝트를 만든다.
  4. 머리를 쥐어뜯으며 프로그램/서비스를 완성한다.
  5. 잘 만든거 같으면 내 깃허브 프로필에 고정시키고 뿌듯해한다.
  6. 다음엔 또 뭘 만들까 고민한다.

이 방식은 어떤 기술이나 프로젝트에 대한 경험이 없는 상태에서
흥미를 가지고 공부를 하게 만드는 아주 효과적인 방식이다.

다양한 코딩교육 컨텐츠에서 강조하는 것도
흥미있는 주제로 원하는 걸 하나 만들어 보라는 것이다.

나도 코딩교육 프로젝트를 했을 때
[작심 10시간! - 나만의 웹사이트 기획하고 개발하기]라는 주제로 했을 정도로
배울 때 도움이 된다고 확신하고 남들에게 권장하는 편이다.

그러나 이 방식을 지금까지 고수해오면서 느낀 치명적인 단점이 하나 있다.

다 죽어가는 내 프로젝트의 생명선

바로, 프로젝트가 일회성으로 반짝 개발되고 죽어버린다는 점이다.

운동으로 비유하자면
근력은 충분히 키울 수 있는 방식이지만
지구력을 키우는 방식은 아닌 것이다.

회사 코딩

회사에서 하는 코딩은 개인 코딩과 정반대의 상황이다.

아무리 개판으로 짠 코드라도
당시에 이미 배포했다면
큰 문제가 없는 한
그 누구도 감히 손대지 않은 채
방치되는 경우가 대다수이다.

사명감을 갖고 괜히 건드렸다가
미처 체크하지 못한 사이드이펙트가 발생한다면
잘 돌아가던 코드 들쑤시다가
버그 만드는 사람 밖에 안되기 때문이다.

어이 김씨, 꼭 저걸 건드려야 하겠는가..

그래서 당신이 어떤 회사에 들어가더라도
레거시코드에 맞게 코드 스타일을 맞추는 것이
첫 번째 임무가 될 것이다.

아마도 그동안 공부한 것들을 마음껏 펼치고자 생각했던
(나 포함) 신입/인턴 개발자들은 극심한 현타를 맞게 될 것이다.

마치 외계인이 인류를 지배하려고 지구에 쳐들어왔는데
코로나 바이러스 때문에 비실비실 거리고 있어서
공격은 커녕 일단 살려놓고 생각해야하는 느낌..?

팬데믹과 리팩토링

어느 순간 회사에 다니면서
어떻게든 레거시 코드를 개선하려고 아등바등하는 내 모습이
지금 팬데믹 상황을 극복하려는 시대 상황과 겹쳐보였다.

프로젝트에 팬데믹을 선포합니다

통제할 수 없이 퍼지는 전파력은
내가 수정하면 어떤 사이드 이펙트가 발생할지 모르는 코드와 같고,
끝없이 변이하는 바이러스는
계속해서 변하고 더해지는 요구사항과 같았다.

이 사태를 진압하기 위해 <리팩토링> 책을 집어들었다.
1장을 읽고 나서
이 책의 접근법 역시 코로나를 진압하기 위한 시도들과
유사하다는 생각이 들어 글을 쓰게 되었다.

건강한 코드란?

우선, 우리가 리팩토링을 막연하게 생각하는 경향이 있기 때문에
개선의 지향점인 건강한 코드에 대해 정의할 필요가 있다.

우리가 백신을 맞는 이유가 뭘까?
그리고 백신을 맞고도 아직까지 안심할 수 없는 이유가 무엇일까?
핵심은 '항체'이다.

우리의 몸은 코로나19 바이러스가 들어오면
자연적으로 대응할 수 있는 능력이 부족했기 때문에
백신을 통해 항체를 만들어서 방어했다.

백신을 맞더라도 그걸 무력화하는 변이 바이러스가 계속 등장해서
주기적으로 맞는 부스터샷까지 이뤄지고 있다.

개발할 때도 마찬가지이다.

항체가 없는 코드는
무자비하게 몰아치는 변경사항(변이 바이러스)에
점점 망가지다가 결국 복구불능 상태가 되어버린다.

그렇기 때문에 우리는 백신이 필요하다.
항체를 만들어주는 과정이 바로 '리팩토링'이다.

백신 = 리팩토링

<리팩토링> 책에서는 1장에서 예시 코드 하나를
수십장에 걸쳐 리팩토링하는 과정을 보여준다.

리팩토링 기법을 하나하나 적용하면서
적용한 이유를 함께 설명해주는데,
큰 맥락에서 '코드를 언제든지 쉽게 바꿀 수 있게'라는 메시지를 담고 있다.

DRY(Do not Repeat Yourself) 원칙 같이
이상적인 원칙을 고수하기 보다
가독성/성능을 해치지 않는 반복 정도는
변수 선언 수정 없이 코드 덩어리를 그대로 퍼서 옮길 수 있기 때문에
오히려 더 권장하기도 하는 실용적인 관점을 보여준다.

필요할 때 바로 옮길 수 있다는 게 곧 코드의 유연성 아닐까?

어떤 변경사항(변이 바이러스)이 몰아쳐도
대응할 수 있는 구조(항체)를 만드는 과정이
리팩토링(백신)인 것이다.

부스터샷 = 점진적 변화

사실 코드만 놓고 봤을 때
베스트 케이스는 당연히 코드를 처음부터 재설계하는 것이다.

하지만 우리가 코로나에 취약한 몸을 가진다고
인류를 멸종시키고 재탄생시킬 수는 없는 노릇이다.

그렇다면 리팩토링 기간을 따로 잡고 집중적으로 고치는 건 어떨까?

그것도 안된다.
이미 사용자가 존재하는 프로그램은 생명체다.

큰 수술에서 심장을 잠시 멈추는 경우는 있어도
며칠 내내 심장을 멈춘다면 세포들은 이미 죽어있을 것이다.
프로그램이 비즈니스 관점에서 죽게 될 수도 있다.

우리가 취할 수 있는 최선의 접근법은
발열이 조금 나더라도 백신을 통해 항체를 만드는 것이다.

한 번에 모든 변이에 대응할 수 없다면
발열이 떨어질 때 쯤 주기적으로 부스터샷을 맞히는 것이다.

그게 내가 생각하는 리팩토링이다.

Loading script...