고장나지 않은건 고치지 않는다?

요즘 "디자인 패턴을 이용한 리팩터링" 이라는 책을 읽고 있습니다.

프로젝트란 것은 끝이 나더라도 한동안 또는 끊임없이 수정사항과 QA를 계속 하게 되어 있습니다.

구조를 잘 잡아서 일정내에 끝을 낸 상황에서 처음 한두번의 수정사항이나 QA는 금방금방 처리를 하죠.

그런데 횟수가 거듭될수록 소스는 꼬여가고 주석도 점점 달 시간이 없어지고

처음에 한번에 고쳤더라면 이렇게까지는 안해도 되었을텐데 라는 후회섞인 원망을 하게되죠.

작은 수정사항도 횟수가 거듭되면 점점 손대는 양이 불어나게 됩니다.

왜 그럴까요?

Refactoring 이라는 것은 이미 개발된 또는 현재 개발중인 코드를

재 편성하는것을 뜻하죠.

기능을 추가하기 위해, 소스의 중복을 줄이기 위해, 유지보수를 편하게 하기위해...

하지만 현실에서는

이미 프로젝트가 끝나고 클라이언트에게 전달되서 실서버에 반영되고 나면

보통 손을 놓는게 다반사입니다.

제목에서 언급했다시피

고장나지 않았다고 해서 손을 놓게 되면

그후에 들어오는 수정사항이나 QA는 말그대로 혹에 혹을 붙이는 처참한 결과를 빚게 됩니다.

때문에 일정에 치여 프로젝트가 겨우겨우 끝이 났더라도

안도하지 말고 미쳐 못봤던 부분이나 중복되어 있는 부분, 시간이 없어서 제대로 구현하지 못했던 부분이나 캡슐화가 제대로 되어 있지 않은 부분들은 고쳐줘야 합니다.

제가 읽는 저 책은 디자인 패턴을 리팩토링을 하면서 어떻게 적용을 해야하는지 조언을 해주는 책이죠.

또 수정사항을 작업하면서 이 수정사항만 제대로 돌아가도록 막코딩식으로 작업을 해버리면

그 다음 수정사항이 왔을때 손을 댈 수 없는 상황이 빚어지곤 합니다.

이때는 if else 문으로만 처리해도 되는 문제일지라도

기능과 역할이 다르다면 확실히 영역을 나눠주고 각자 메소드가 자기 역할을 수행할 수 있도록 리팩토링 해줘야 한다는 말이죠.

그래야 다음 수정사항이 왔을때 보다 효율적으로 적용할 수 있기 때문입니다.

무엇보다 중요한 부분은 바로 이런 시간과 노력이 필요한 이유를

상사와 다른 팀에게 인식을 시켜줘야 한다는 것입니다.

0.9 의 10 제곱이야기처럼 일단 제대로 돌아가니까 손대지 않고 놔둬버리면

횟수가 거듭될수록 더 많은 시간과 땀이 들어야 한다는것을 분명히 인식시켜야 합니다.

처음에는 0.9의 완성도로 만족했지만 그다음에는 0.81 그다음은 0.72... 10번을 반복하면 1/3 수준인 0.34밖에 되지 않습니다.

우리 모두 고급개발자가 되기 위해서는 우리가 필요한것이 무엇이며 왜 필요한지를

내가 아는것뿐만이 아니라 다른팀원에게 이해시키는것도 반드시 필요한 일 일거라 생각합니다.

왜냐하면 아직은 우리나라에서 특히 플래시 개발에 있어서는 이러한 인식이 부족하기 때문이죠.