2007년 11월 8일 목요일 okjsp 세미나~

Refactoring 세미나를 듣고...

refactoring 이란 무엇인가?

re + factor + ing 로 이루어진 단어로 있는 사실(코드)를 재구성한다는 의미입니다.
좀더 알기 쉽게 표현하자면 기능은 똑같은데 코드 구조를 바꾼다는 의미입니다.

사람들이 sm을 하는 경우 일반적인 생각이 잘 돌아가는 것은 건드리지 말자 라는 생각을 갖고 있다.
그렇기 때문에 사람들한테 수정사항, 요구사항들을 들을 때마다 코드에 if문이 생기면서 코드의 효율이 떨어집니다.

예를 들면(이건 제가 이해하는 겁니다.)
소스가 일을 하고 있다.
a에서 b 까지 3kg의 옮기는 일을 하고 있습니다.

갑에서 요구가 들어왔습니다.
"소스씨 a에서 b 까지 옮길때 2kg 의 짐을 더 추가해줘야겠어~."
그럼 소스는 갈때...5kg의 무게의 짐을 들고 갑니다.

이런 일들이 반복 되다보면 5kg의 무게가 7kg..10kg...100kg이 됩니다.
이걸 갖고 갈 수있을까요?
너무 힙듭니다. 불가능하구요.

실제로 처음의 data는 몇 바이트로 시작해서 요구 사항에 대해 계속 추가하면서 리소스를 그만큼 잡아먹게 됩니다.

이걸 해결하기 위해서 많은 짐들을 옮기기 위해서 차를 이용해야 합니다.
전반적인 구조조정이나 전면적인 방법론 자체를 뜯어 고쳐야 합니다.

여러 내용들이 있었는데...
제가 잘 이해하고 많이 느낀 부분을 토대로 설명드리자면

rename 과 move , code review , extract method , inline 등이 있다.
(eclipse를 중점적으로 한 설명입니다.)

rename은 알다시피 이름을 다시 정해서 통일 하는 것다.
사람들마다 variable이나 method name 이 다르다.
그렇기 때문에 팀 내의 다른 사람들의 소스를 볼때
이것을 먼저 파악하는게 하나의 업무가 될 수도 있고
생산성을 떨어뜨리는 결과로 이어질 수가 있다.
eclipse에서는 이런 것들을 한번에 일괄적으로 해결 할 수 있는 기능을 제공하고 있다.

move는 말 그대로 위치를 옮기는 것이다.
여기에 대해서는 그리 느끼는 바가 없어서 그냥 넘어간다.

extract method
반복되는 구문은 메소드로 뽑아낸다.

3 Strike 법칙이란게 있습니다.
"한번 일어난 사고는 우연이지만...2번 3번 일어난 사고는 또 다시 일어날 확율이 있다."는 겁니다.

이런 것들은 함수로 뽑아내는 것이 좋다.

inline
extract mathod와는 반대로 변수를 한번 쓸 경우 굳이 변수로 선언 할 필요가 없습니다.
오히려 효율을 떨어뜨리게 됩니다.

개발을 하다 보면 비슷한 기능들을 구현하는 일들이 많습니다.

이때 조심해야 할 일. 리팩토링을 해야 할 일들이 생긴다.
개발자들은 copy & paste 를 하고 , 하다 보면 이미 구현된 페이지에 필요없는 기능 및 소스들이 추가가 된다.

예를 들자면 게시판에 5가지 기능 읽고 쓰고 수정하고 삭제하고 검색하는 페이지가 있었는데
다른 페이지 개발을 하면서 이 페이지를 그대로 옮겨 쓰게 된다.
새로 시작된 페이지는 읽기만 하면 되는 것이였다.
그럼 사람들이 소스를 수정하고 고치기는 하지만 그렇게 많은 신경을 쓰지 않게 된다.

그러면서 쓰레기 코드들이 있게 되는데...
여기서 깨진 유리창의 법칙이 적용된다.

뉴욕 소득이 낮은 지역이 있었다.
어느날 그 지역의 차 유리가 한대 깨졌다.
몇일 지나자 그 차는 털리고 점점 망가져 간다.
사람들이 부속품을 띄어가고 차는 완전 폐차 직전까지 갔다.

그 몇일후 근처에 있던 차가 유리창이 깨진다.
그러다가 그 주위에 차들이 부서졌다.
얼마 안가 그 주변에 사고들이 잦아들고 우범지대로 바뀌었다.

이게 깨진 유리창의 법칙입니다.

다른 하나의 예로 귤 상자를 들 수 있습니다.
귤 상자에 썩은 귤 하나가 있으면 그 귤이 점점 시간이 지나면서 귤 상자 전체를 썩게 한다는 것이다.

코드 하나를 귀찮아서 안 바꾸고 놔두는 경우 그 소스가 점점 그 프로그램 전체를 망치게 한다는 의미 입니다.

결론은 잘못된 점을 알았을때는 미루지 말고 바로 바로 고치자~
좀더 나은 방법을 위해 고민하고 여러 사람과의 의사소통이 필요하다.입니다.
세미나에서 가장 감명받은건 이런걸 하기 위해선 코드리뷰를 해야 한다. 입니다.