Thoughts2014.01.24 12:19

#1.


코드에 새로운 기능을 추가하는 시간이 점점 길어지고 느려지고 따분해지고 지겨워진다면 바로 그 때가 리팩터링 시점이다. 물론 '코드에 새로운 기능을 추가하는' 것은 대체로 '요구사항의 변화'를 의미하므로, 요구사항이 계속 밀려드는 바쁜 시점에 코드를 리팩터링한다는 것이 부담이 될 수도 있겠다. 만일 지금 당장 리팩토링 할 수 없다면, 나중에 따로 시간을 내서라도 프로그램 구조를 변경해 놓는 것이 바람직하다. 그렇지 않으면 나중에 유지보수해야 할 시점이 되었을 때 피를 보게 될 것이다.


#2. 


프로그램이 너덜너덜해져서 보기 끔찍할 지경이 되어가고 있다면, 리팩터링을 심각하게 고려하는 것이 바람직하다. 그렇게 될 지경까지 대체 뭐 했느냐고 묻는 사람이 있을 수도 있으나, 일정 시점까지는 합리적이었던 구조가 시간이 자나면서 점점 불합리하게 바뀌는 경우도 있으므로 (소프트웨어 개발 과정은 생산 공정과는 다르다는 것에 유의하자) 처음에 아무리 잘 설계한 프로그램이라 해도 이런 일이 생기지 않으리라는 보장은 없다.


#3. 


당신의 라이브러리의 유저가 라이브러리의 사용성에 대해 의문을 제기하기 시작한다면, 아마 본인으로는 만족스럽더라도 리팩터링을 고려해봐야 할 것이다. 사용성이 만족스럽지 않다는 것은 잘못 설계되었다는 증거일 수도 있다. 잘못 설계된 구조를 계속 고수한다는 것에는 별로 의미가 없다. 그리고 결정적으로 사용하기에 문제가 있는 라이브러리들은 '유저가 원하는 대로 확장하기 곤란한' 라이브러리라는 문제도 갖는다. 





#4. 


파일명, 클래스명, 함수명을 봐서는 대체 뭘 하는 모듈인지 정확하게 알 수 없을 때는 역시 리팩터링을 심각하게 고려해 봐야 한다. 문서를 봐도 알 수 없다면 상황이 심각한 것이므로, 역할에 따라서 모듈을 적절히 나누어 주어야 한다. 그런 작업을 할 때는 다른 개발자들에게 혼란을 줄 수 있으므로 주의해야 한다. 


#5. 


더 나은 구조가 있을지도 모른다는 생각이 든다면, 그 때가 아마 리팩터링을 하면 좋은 시점일 것이다. '더 나은 구조'에 대한 갈망은 대체로 현재 구조에 대한 불만에서 출발한다. 해결책이 없다면 일단은 포기하더라도, 문제를 머리에 넣어놓고 일정한 시간이 지나면 대체로 해결 방안이 떠오른다. 해결 방안을 적용할 때는 바로 소스코드를 수정하려는 시도를 하는 대신, 원래 구조와 비슷한 구조의 모형 프로그램을 만들어서 시험해 본 다음에 적용하는 것이 좋다. 




저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^