BooK Plus2008.02.15 12:49

출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)

---------------------------------------------------------------------------------------------------
메소드 정리 - > Extract Method

그룹으로 함꼐 묵을 수 있는 코드 조각이 있으면, 코드의 목적이 잘 드러나도록 메소드의 이름을 지어 별도의 메소드로 뽑아낸다.

void printOwing(double amont){
printBanner();
// 상세 정보 표시
System.out.println("name:"+_name);
System.out.println("amount:"+amount);
}
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

void printOwing(double amount){
printBanner();
printDetails(amount);
}

void printDetails(double amount){
 System.out.println("name:"+_name);
System.out.println("amount:"+amount);
}


☆ 동기

Extract Method는 내가 가장 자주 사용하는 리팩토링 가운데 하나이다. 나는 지나치게 긴 메소드를 보거나, 목적을 이해하기 위해서 주석이 필요한 코드를 보면 그 부분을 하나의 메소드로 뽑아낸다 .
나는 다음과 같은 이유료 짧고, 이해하기 쉬운 이름으로 된 메소드를 좋아한다. 첫째, 메소드가 잘게 쪼개져 있을 때 다른 메소드에서 사용될 확률이 높아진다. 둘째, 고수준의 메소드를 볼 때 이련의 주석을 읽는 것 같은 느김이 들도록 할 수 있다. 또한, 메소드가 잘게 쪼개져 있을 때 오버라이드 하는 것도 훨씬 쉽다. 만약 큰 메소드에 익수해져 있다면 메소드를 잘게 쪼개는 것에 익숙해지는 데는 약간 시간이 걸릴 것이다. 작은 메소드는 실제로 이름을 잘 지었을 때문 그 진가가 드러나므로, 이름을 지을 때 주의해야 한다.
사람들은 때때로 나에게 한 메소드의 길이가 어느 종도 되ㅇ야 할 지를 묻는다. 그러나 나는 길이가 중요하다고 생각 하지 않는다. 중요한것은 메소드의 이름과 메소드 몸체의 의미적 차이다. 뽑아내는 것이 코드를 더욱 명확하게 하며느 새로 만든 메소드의 이름이 원래 코드의 길이보다 길어져도 뽑아낸다.

☆ 절차
 - 메소드를 새로 만들고 , 의도를 잘 나타낼 수 잇도록 이름을 정한다(어떻게 하는지를 나타내는 방식으로 이름을 정하지 말고, 무엇을 하는지를 나타내게 이름을 정한다).
 ->  뽑아내고자 하는 부분이 한줄의 메시지나 함수 호출과 같이 아주 간단한 경우에는 새로운 메소드의 이름이 그 코드의 의도를 더 잘 나타낼수 있을 때만 뽑아낸다. 더 이해하기 쉬운 이름을 지을 수 없다면 코드를 뽑아내지 않는 것이 낮다.
- 원래 메소드에서 뽑아내고자 하는 부분의 코드를 복사하여 새 메소드로 옮긴다.
- 원래 메소드에서 사용되고 있는 지역변수가 뽑아낸 코드에 있는지 확인한다. 이런 지역변수는 새로운 메소드의 지역변수나 파라미터가 된다.
- 뽑아낸 코드내에서만 사용되는 임시변수가 있는지 본다. 있다면 새로 만든 메소드의 임수변수로 선언한다.
- 뽑아낸 코드내에서 지역변수의 값이 수정되는지 본다. 만약 하나의 지역변수만 수정된 다면, 뽑아낸 코드의 질의를 보고ㅡ 주정된 결과를 관련된 변수에 대입할 수 있는지 본다. 이렇게 하는 것이 이상하거나, 값이 수정되는 지역변수가 두개 이상있다면 쉽게 메소드로  추출할 수 없는 경우이다. 이럴때는 split Temporart Variable(155)을 사용한 다음 다시 시도해야 한다. 임시변수는 Replace Temp with Quert(147)로 제거할 수 잇다.(예제에서 토의된 내용 참조).
- 뽑아낸 코드에서 읽기만 하는 변수는 새 메소드의 파라미터로 넘긴다.
- 지역변수와 관련되 사항을 다룬 후에는 컴파일을 한다.
- 원래 메소드에서 뽑아낸 코드 부분은 새로 만든 메소드를 호출하도록 바꾼다.
 => 새로 만든 메소드로 옮긴 임시 변수가 잇는 경우 그 임시변수가 원래 메소드의 밖에서 선언되었는지를 확인한다. 만약 그렇다면 새로 만들 메소드에서는 선언을 해줄 필요가 없다.
- 컴파일과 테스트를 한다.

---------------------------------------------------------------------------------------------------

extract method 는 이클립스에서도 자동으로 지원 되는 리펙토링중 하나이다. 그만큼 많이 쓰인다는건가;?
저자가 말한것 처럼 가장 많이 사용하는 리팩토링 가운데 하나라고 하는것 처럼..

음냥;; 나도 뭐 저자를 따라하려고 많이 노력하고 있는데..
참.. 그게 새로운 메소드를 이름으로 짓는다는것이 어렵던지... ;; 쩝;;

영어에 약한 사람은... 힘들어요;;

무튼... 이 리팩토링을 사용하면.. 코드가 좀더 깔끔해 보인다.
분산을 시켜서 그런지;;
뭐 단점은... 보려면.. 여기 봤다가 저기 봤다가 해야 하니;;ㅋ
그래도.. 저자 말대로 이름을 잘지으면... 중간에 새로 뽑아낸 메소드도 그냥 단순히 코드의 한줄로 읽을 수
있지 않을까 하는 생각입니다~~~~

Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.24 12:33
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)

---------------------------------------------------------------------------------------------------

언제 리팩토링을 해야 하는가 ? - 삼진규칙;

 여기서 Don Roberts가 내게 알려준 가이드라인이 있다. 어떤것을 처음 할 때는, 그냥한다.
두번째로 비슷한 어던 것을 하게 되면, 중복 때문에 주춤하지만 그냥 중복되도록 한다. 세번째로 비슷한 것을 하게 되면, 그때 리팩토링을 한다. [스트라이크 세개면 리팩토링을 한다.]

언제 리팩토링을 해야 하는가 ? - 기능을 추가할 때 리팩토링을 하라.

 리팩토링을 해야 하는 가장 일반적인 시점은 소프트웨어에 새로운 기능을 추가하고 싶을 때이다.이 시점에서 리팩토링을 해야 하는 첫 번째 이유는 종종 수정해야 할 코드에 대한 이 해를 돕기 위해서 이다. 수정하려는 코드는 다른 사람이 작성했을 수도 있고, 내 자신에게 물어본 후 리팩토링을 한다. 부분적으로는 나중에 내가 그 부분을 다시 볼 때를 위해서 하는 것이지만, 주된 이유는 코드를 명확하게 하면 더 많은 것을 이해할 수 있기 때문이다.
 여기서 리팩토링을 하도록 만드는 다른 이유는 기능 추가가 쉽지 않은 디자인디다. 디자인을 보고는 스스로에게 "만약 이런 식으로 디자인을 했더라면 기능 추가각 쉬웠을 텐데" 라고 말한다면, 이런 경우 나는 지난날의 잘못때문에 초조해 하지 않고, 리팩토링으로 그것을 고친다. 이렇게 하는 것은 수정을 쉽게 하기 위해서 이기도 하지만, 더 큰 이유는 이렇게 하는 것이 가장 빠르다는 것을 알기 때문이다. 리팩토링은 빠르지만 매끄러운 프로세스이다. 한번 리팩토링을 해놓으면, 기능을 추가하는 것은 훨씬 더 빠르고 매끄럽다.

---------------------------------------------------------------------------------------------------

리팩토링을 하는건 매우 귀찮은 일이다. 잘 돌아가던 코드를 리팩토링을 하게 되면 다시 테스트를 하여 잘 되었는지 반드시 확인 해주어야 하는 일이 동반 되기 때문이다.
무언가를 할 때 비용이 드는건 사실이다. 일반적으로 프로젝트를 하다보면 경력이 많은 개발자들도 그냥 아무 생각 없이 카피엔 페이스트를 한다. 그렇게 하다 보면 분명히 반드시 중복이 생긴다.
하지만 그냥 잘 돌아가는걸 왜 건들어야 하고, 왜 귀찮은 작업을 하느냐라고 한다. 물론 .. 맞는 말이다.
굳이 비용을 들여 리팩토링을 할 이유가 없기 때문이다. 완전 하나는 알고 둘은 모르는 생각 같다.

한번 작성하고 다시는 수정이 안되는 프로그램이면 모를까 대부분은 거의 한번.. 아니 그이상 수정을 가하게 된다. 추가 요구사항이나 프로세스가 변경되어... 수정 하게 된다.

그때 아무 생각 없는 사람은 변경 되는 원인만 탓하게 되고 ... 자신이 만들어 놓은 코드를 다시 이해 하기 위해 많은 비용을 들인다. 실타래 처럼 꼬여 있는 코드들을 보면서 수정하면서 엄청난 오류들을 보면서 한숨 쉬며 꾸역꾸역 ... 변경을 하게 된다.

만약 ....... 잘 정리 된 코드였으면....... 아니 개발자들은 개발 하고 나가고 .. 남아서 운영하는 사람들에게는..
곤역이 따를 뿐이다.

덩치가 커지는 프로세스 일수록 리팩토링을 하여 코드를 잘 정리 해놓는 다면.. 좋으련만..

하지만 언제나 생각과 실천은......... 좀 동떨어져 있다. 이렇게 글 적는 나도...ㅋ 잘 안되지만.
잘 쓰인 향기로운 코드를 위해서...... 오늘 하루도 화이팅!!
Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.23 12:40
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)

---------------------------------------------------------------------------------------------------
리팩토링에 대해 이야기를 할 때 어떻게 일정을 세워야 하냐는 질문을 종종 받는다. 리팩토링을 위해 두세 달에 한번씩 2주 정도의 시간을 할당해야 하는가?

대부분의 경우, 나는 리팩토링을 위해 별도의 시간을 내는 것에 반대한다. 내가 보기에 리팩토링은 별동의 시간을 내서 할 것이 아니라, 틈틈이 계속 해야 하는 것이다. 리팩토링 자체를 목적으로 삼는 것이 아니라, 어떤 다른 것을 하기위해 리팩토링을 하는 것이고, 리팩토링은 그 다른 것을 하는 데 도움을 준다.

- 삼진 규칙.
- 기능을 추가할 때 리팩토링을 하라
- 버그를 수정해야 할 때 리팩토링을 하라
- 코드 컴토를 할 때 리팩토링을 하라.
---------------------------------------------------------------------------------------------------

리팩토링을 언제 적용 해야 할까?
이건 꼭 정해진 것이 없는것 같다. 뭐 책에선 저러한 때에 리팩토링을 하라고 하는데...
내가 볼 때는 코드를 작성하고 다시 한번 보게 될 적에 틈틈이 코드를 정리 하는것이 필요 하다고 생각한다.
특히 중복된 코드로 인한 코드 량이 늘어나고.. 늘어다 보면 지저분해지고, 그 기능이 수정하게 되면
복사해서 사용한 코드들을 일일이 찾아가서 수정해주고..
완전 뻘짓.....

물론 대부분의 한국형 프로젝트에선 이러한것들을 중요시 여기지 않는 것 같다.
높으신 윗분들 중에 ..... 몇명이나 이러한 것에 깨어 있어서... 중요시 여길까 ? 의문이 생긴다.
해당 일정 기간동안 원 하는 기능만 수행되면 ... 만사 OK...
리팩토링을 해가면서 투자 되는 시간은 ........ 아깝다고만 생각 한다..
어떻게 어디로 가든 서울로만 가면 되듯이.......
돌아가기만 하면 되니.. 안타까운 현실이다..

이러한 현실에서도 꿋꿋하게 .. 나름 자신만의 신념을 가지고 향기로운 코더가 되어 보지 않으실래요 ?
Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.21 12:36
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)


---------------------------------------------------------------------------------------------------
왜 리팩토링을 해야 하는가 ? - 리팩토링은 프로그램을 빨리 작성하도록 도와준다.

 결국 앞에서 언급했던 사항들은 다음 한 문장으로 압축할 수 있다. 즉 리팩토링은 코드를 보다 빨리 개발할 수 있도록 도와준다.
 언뜻 행각하면 이해할 수 없는 말이다. 리팩토링에 대해 말을 하면, 사람들은 리팩토링이 품질을 향상시킬 것이라는 데는 쉽게 이해를 한다. 디자인을 개선하고, 가독성을 향상시키고, 버그를 줄이고.... 이모든 것은 품질을 향상시킨다. 그러나 이런 것은 개발 속도를 줄이는 것이 아닐까?

나는 소프트웨어를 빨리 개발하는 데에는 좋은 디자인이 가장 중요하다고 강력하게 믿는다. 실제로 좋은 디자인이 필요한 이유는 개발 속도를 빠르게 하기 위해서 이다. 좋은 디자인 없이 한동안 빠르게 진행할 수 있겠지만 곧 그 형편없는 디자인 때문에 작업 속도가 느려진다. 새로운 기능을 추가하는 데 시간을 보내는 것이 아니라, 버그를 찾고 고치는 데 시간을 소모하게 된다. 코드를 이해하고, 중복된 부분을 찾느라 수정 작업을 더욱 오래 걸릴 것이다. 원래 코드를 패치하고, 다시 패치하고 또 패치하고... 새로운 기능을 추가하기 위해서는 더 많은 코딩을 해야 할 것이다.
 소프트웨어 개발의 속도를 어느 정도로 유지하기 위해서는 좋은 디자인이 필수다. 리팩토링은 시스템의 디자인이 나빠지는 것을 멈추게 하여 소프트웨어를 보다 빨리 개발할 수 있도록 도와준다. 또한 디자인을 향상시키기도 한다.

---------------------------------------------------------------------------------------------------

오늘로써 왜 리팩토링을 해야 하는가라는 항목에 대해서 끝이 났다.
소프트웨어의 디자인을 개선시키고, 더 이해하기 쉽게 만들고 , 버그를 찾는데 도움을 주고, 프로그램을 빨리 작성하도록 도와준다고 하는 리팩토링..

오늘 까지 왜 리팩토링을 해야 하는지를 살펴봤으니까..
다시 한번 숙지 하고..........

그럼 언제 리팩토링을 해야 하는지 공부 해야 겠수다~;;

어려워.. 리팩토링..... 음.......

Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.18 12:39
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)


---------------------------------------------------------------------------------------------------
왜 리팩토링을 해야 하는가 ? - 리팩토링은 버그를 찾도록 도와 준다.

 코드를 잘 이해하게 되면 버그도 쉽게 찾을 수 있게 된다. 나는 버그를 찾는 데 별로 익숙하지 않다는 것을 인정한다. 어떤 사람은 코드 한 덩어리를 보고는 바로 버그를 발견할 수 있지만 나는 그렇지 못하다. 그러나 코드를 리팩토링 하면, 코드가 무슨 작업을 하는지 깊이 이해할수 있게 되고, 나는 새로 이해한 것을 바로 코드에 반영한다. 프로그램의 구조를 명확히 함으로써 내가 만든 가정의 진위가 명확해지면, 이 시점에서는 버그가 눈에 들어오지 않을 수 없다.
 이것은 Kent Beck이 자신에 대해 했던 말을 떠오르게 한다. "나는 훌륭한 프로그래머는 아니다. 그냥 훌륭한 습관을 가지고 있는 좋은 프로그래머이다." 리팩토링은 훨씬 더 효과적으로 견고한코드를 작성하도록 도와준다.
---------------------------------------------------------------------------------------------------

>>ㅑ~ 난 프로그래밍을 하다 보면 언제나 버그가 생긴다.(내가 워낙 허접해서.. ) 버그.. 음...
분명 내 생각이 맞다면 제대로 동작해야 할 코드가 ... 실행 해보면 엉뚱한 실행과 결과를 뺃어 버리곤 한다.
테스트 없는 프로그래밍의 한계인것 같다. 또한 버그를 찾기 위해 얼마나 수많은 밤을 지세웠는지..

잘 되던 코드가 어떤 알수 없는 예외 상황에 에러가 나고 그 에러를 찾기 위해... 다시 짜놓은 코드들을 보면서
처음부터 일일이 찾아가는 것이... 코드를 작성할 때 보다 더 어려운것 같다. 왜 내가 이렇게 코딩을 했을까..
하면 다시 정리를 하다 보면 구멍을 발견 하곤 한다.

왜 처음부터... 깔끔하고 향기로운 코드를 만들지 않았을까....... 그때 까진 리팩토링이라는걸 알지 못했다.
이제 배워가는 단계이니... 이런 반복을 하지 않도록.... 조금씩 조금씩 점진적으로 리팩토링을 적용하며~
향기로운 코드를 만들어가도록...... 음하하~ 노력 합시다~!

버그 딱걸려라~~ !!
Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.17 12:50
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)


---------------------------------------------------------------------------------------------------
왜 리팩토링을 해야 하는가 ? - 리팩토링은 소프트웨어를 더 이해하기 쉽게 만든다.

많은 면에서 프로그래밍은 컴퓨터와의 대화라고 할 수 있다. 우리가 컴퓨터가 해야 할 일을 코드로 써서 컴퓨터에게 말하고, 컴퓨터는 정확하게 코드에 있는 대로 작동함으로써 반응한다. 오래지 않아 우리가 하고자 하는 것과 그것을 하도록 말하는것 사이의 차이는 줄어든다. 이런식으로 프로그래밍은 우리가 원하는 것을 정확하게 말하는 것에 대한 모든 것이다. 그러나 우리의 소스 코드를 사용하는 다른 사용자가 있다. 몇 달안에 누군가 어떤 변경을 하기위해 우리의 코드를 읽으려 할 것이다. 우리는 코드의 다른 사용자를 쉽게 잊지만, 그 사용자야 말고 실제로는 가장 중요하다. 컴퓨터가 어떤 것을 컴파일 하기위해 몇 단계를 더 거친다고 한들 누가 상관하겠는가? 그러나 어떤 프로그래머가 코드를 이해했다면 수정하는데 단지 한 시간이면 될것을 일주일씩 걸리는 것은 문제다.

 문제는 우리가 프로그램을 만들 때, 나중의 개발자에 대해 생각하지 않는다는 것이다. 코드를 더 쉽게 이해할 수 있도록 변경하기 위해서는 리듬의 변화가 필요하다. 리팩토링은 코드를 더 읽기 쉽게 만들도록 도와준다. 리팩토링을 시작할 때 코드가 작동은 하지만 구조는 완벽하지 않다. 리팩토링을 하는데 얼마간의 시간을 보내면, 그 코드의 목적은 더욱 명확해질 것이다. 이런 식으로 프로그래밍이 우리가 뜻하는 바를 정확하게 말하는 것에 대한 모든 것이다.

 이렇게 나중의 개발자를 염두에 둔 프로그래밍을 하기 위해 이타적이 될 필요는 없다. 그 나중의 개발자가 내 자신이 될 수도 있기 때문이다. 여기서 리팩토링이 특히 중요하다. 나는 매우 게으른 프로그래머이다. 나는 내가 작성한 코드도 기억을 못할정도로 게으르다. 실은 머리가 꽉 차버리는 것이 두려워, 찾아볼 수 있는 것은 일부러 기억하려 하지 않는다. 나는 나중에 기억할 필요가 없도록, 기억해야 할 모든 것을 코드에 넣는다. 이런 방법으로 오래된 기억이 내 뇌세포를 죽이는 것에 대한 걱정을 덜 수 있다.

이해하기 쉽게 만듣다는 것은 다른 면으로도 유용하다. 나는 익숙하지 않은 코드를 이해하는 데 도움을 받고자 리팩토링을 사용한다. 익숙하지 않은 코드를 볼 때 나는 그 코드가 무엇을 하는것인지 이해해야 한다. 나는 몇 줄의 코드를 보면서 그래, 바로 이게 이 코드가 하는 일이구나, 하고 말한다. 나는 이런 것을 기억하기 보다는 리팩토링을 한다. 실제로 내가 이해한 것을 더 잘 반영하도록 코드를 수정하고, 그 코드를 다시 실행시켜 여전히 제대로 동작하는지를 봄으로써 내가 제대로 이해했는지 확인하다.

 초기에는  이런 식으로 좀 자세하게 리팩토링을 한다. 코드가 점점 명확해짐에 따라, 나는 그 전에는 보지 못했던 디자인에 관한 것을 볼 수 있게 된다. 나는 이 모든것을 머리속에서 시각화 할 수 있을 정도로 똑똑하지는 못하기 때문에, 코드를 바꾸지 않았더라면 아마 이런 것을 보지 못했을 것이다 . Ralph Johnson은 이런 초기단계의 리팩토링을 유리창에 있는 먼지를 닦아 그 너머를 볼 수 있게 되는 것으로 묘사했다. 리팩토링은 코드를 볼 때 내가 그냥은 보지 못했을 더 놓은 수준으로 이해로 나를 이끌어준다.
---------------------------------------------------------------------------------------------------

4번째 포스팅이다. 뭐 이건 포스팅이 책을 보고 그대로 타이핑하는 수준이네요ㅋ
냠냠.. 저작권에 걸리는 행위 인가? 이정도의 인용은 상관이 없는건가 갑자기 의문이 생기는 이유가 무엇일까?
어찌 되었건.. 타이핑 치면서 다시 한번 책을 정독 할수 있는 계기가 되었다.
한동안 서랍장에서 먼지와 친구를 하던 책을.. 다시 한번 볼수 있는 좋은 기회인것 같다.

난 개발자이다. 대한민국의 개발자.. 언제가 부터 IT 업계의 SI 개발자는 3D 업종으로 분류된것 같다. 정해진 출근 시간... 그리고 정해지지 않은 ... 퇴근 시간과 휴일...
그 속에서 나는 좀더 낳은 개발자가 되기 위해 노력을 하려고 한다.

이제 2번째 프로젝트를 하고 있는데;; 첫번째 프로젝트에서 해보지 못한... 것을 이번 프로젝트에서 연습해보려고 한다. (이러다가 프로젝트가 망하겠나;;ㅡㅡ) 아직은 생소하지만.. 리팩토링을 적용해보려고 노력중이다.
한번 작성하고 또 수정하고 또 수정하고 또 수정하고... 다듬어 가는 중이다. 하지만 내가 제대로 하고 있는지는 나도 잘 모르겠다. 나름. 나름. 조금씩 조금씩. 나만은 스토리를 만들어가려고 노력중이다~

시간이 흐른후에 내가 만들어 놓은 스토리를 보면 내가 왜 이렇게 했을까? 이렇게 하면 좀 더 깔끔하고 보기 좋은 코딩이 되었을것을... 이렇게 느끼게 되리라고 믿는다.. 그 때는 지금보다 좀더 향기로운 코드를 만들 수 있는 센스가 생겼을 꺼라고 믿기때문에...
Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.16 12:52
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)


---------------------------------------------------------------------------------------------------
왜 리팩토링을 해야 하는가 ? - 리팩토링은 소프트웨어의 디자인을 개선시킨다.

 나는 리팩토링을 소프트웨어의  모든 문제점에 대한 치료방법이라고 말하고 싶지는 않다. 은탄한(만병통치약)이 아닌것이다. 그러나 리팩토링은 유용한 도구이고, 코드를 잘 잡고 있게 해줄 은집게 정도는 된다. 리팩토링은 여러가지 목적으로 사용될 수 있고, 사용되어야 하는 도구이다.

- 리팩토링은 소프트웨어의 디자인을 개선시킨다.
리팩토링이 없다면, 소프트웨어의 의도된 디자인은 망가져갈 것이다. 사람들이 코드를 수정함에 따라 - 단기적인 목절을 이루기 위해서 또는 코드 전체의 디자인을 제대로 이해하지 못하는 상태에서 코드를 변경할 때 - 코드는 원래의 구조를 잃을 것이다. 코드를 보고 디자인을 파악하는 것은 더욱 어려워질 것이다. 리팩토링은 이런 코드를 정돈 하는 것이다. 정말 적절한 곳에 있지 않은 코드는 제거 한다. 코드의 구조가 망가지는 효과는 누적된다. 코드에서 그 디자인을 파악하기 어려워질수록, 디자인을 유지하기 어려워지고 결국 디자인은 더 빨리 시들어 갈 것이다. 정기적인 리팩토링은 코드가 디자인을 유지하도록 도와준다.

디자인이 좋지 않은 코드는 같은 작업을 할 경우 더 많은 코드를 사용한다. 왜냐하면 같은 작업을 하는 코드가 여러 곳에 중복해서 있을 경우가 많기 대문이다. 따라서 디자인을 개선하는 중요한 측면 가운데 하나가 중복된 코드를 제거하는 것이다. 이것의 중요성은 나중에 코드를 수정할 때 나타난다. 코드의 양을 줄이는 것이 스스템의 속도를 빠르게 하지는 않느데 이는 프로그램이 차지하는 공간이 속도에 미치는 효과가 별로 중요하지 않기 때문이다. 그러나 코드의 양을 줄여 놓으면 코드를 수정할 때 큰 차이가 나타난다. 코드가 많을수록 정확하게 고치기는 러렵다. 이해해야 할 코드가 더 많기 때문이다. 한쪽의 코드를 조금 고친다고 하더라도 시스템이 기대한 대로 작동하지 않는데, 그것은 다른쪽에 잇는 약간 다른 컨텍스트에서 거의 동일하게 작동하는 부분에 대한 코드를 고치지 않았기 때문이다. 중복을 제거함으로써, 각각의 작업에 대한 코드가 오직 한곳에만 있게 할 수 있다. 이것은 좋은 디자인의 필수 조건이다.
---------------------------------------------------------------------------------------------------

타이핑을 칠 무렵 주위의 한 지인이 ... 왜 리팩토링을 해야해 ? 라고 물어 보았는데..
난 거기의 대한 대답을 웃음으로 넘기고 말았다. 리팩토링을 왜 해야 하는거지? 라는 거에 대해서 나도 그대답을 찾지 못하고 있는듯 하다.
왜 해야 하는가 ?
음..... 왜 해야하지?
책에는 좋은 내용들이 구구절절 적혀 있다. 하지만 그게 자기 자신에게 와 닿지 않고 필요치 않으면...
그냥 하얀 종이 위에 찍힌 검정색점 밖으로는 보이지 않을 것이다.
난... 아직 이르지만... 이렇게 생각 하고 싶다.
향기가 구수한 코드를 만들기 위해서... 누구가 봐도 한편의 스토리를 읽는 것 처럼 읽어 내려 갈 수 있는..
재미있는 책과 같은 코드를 만들기 위해 코드에 대해 지켜야 할 자그만한 에티켓이라고 생각한다.

아직은 잘 알수 없지만...
향기가 좋은 코딩책을 작성하는 그날까지.........
Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.10 13:15
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)


---------------------------------------------------------------------------------------------------
사람들은 모두 나름대로의 생각을 갖고 있기 대문에 먼가에 대해 정의하는 것은 항상 조심스럽지만, 어째든 책을 쓸 떄에는 자신의 정의를 선택해야 한다. 여기서 나의 정의는 Ralph Johnos 그룹과 선별된 동료들의 작업에
기초를 두고 있다.

먼저 말해두어야 할것은 '리펙토링' 이라는 단어가 문맥에 따라 두 가지 다른 정의를 가질 수 있다는 것이다. 이것은 짜증나는 일이겠지만, 자연어를 이용하는 실세계에서는 흔한일이다 .

첫 번째 정의는 명사형이다.

***************************************************************************************************
* 리팩토링(Refactoring)(명사) - 소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용으로 수정할수 있도록      *
* 겉으로 보이는 동작의 변화 없이 내부 구조를 변경하는 것.                                                                   *
***************************************************************************************************

 두 번째는 동사형이다.
***************************************************************************************************
* 리팩토링 하다(Refactor)(동사) - 일련의 리팩토링을 적용하여 겉으로 보이는 동장의 변화없이 소프트웨어의*
* 구조를 바꾸다                                                                                                                              *
***************************************************************************************************


따라서 리팩토링을 하느라 한 두시간을 보내면서, 그 동안 수십개의 리팩토링을 적용할 수 있다.
나는  "리팩토링이 단순히 코드를 깜끔하게 하는 것이냐?"는 질문을 받은 적이 있다. 어떻게 보면 맞을 수도
있으나 리팩토링은 코드를 깔끔하게 하기 위한 보다 효율적이고 통제된 방법으로 제공하므로 그 이상이라 생각
한다. 나는 리팩토링을 사용한 후로, 전보다 코드를 훨씬 효과적으로 정리한다는 것을 알게되었다.
이는 내가 어떻ㄴ 리팩토링을 사용해야 할지 알고, 버그를 최소화하기 위해 어떤 방법으로 사용해야 하는지를 알고, 또 가능할 때마다 테스트를 하기 때문이다.
위의 정의에서 강조해야 할 것이 몇가지 있다. 첫째 리팩토링의 목적은 소프트웨어를 보다 이해하기 쉽고, 수정하기 쉽도록 만드는 것이다. 걷으로 보이는 동작을 거의 또는 전혀 변경하지 않고도 , 소프트웨어에서 많은 것을 고칠수 있다. 단지 소프트웨어를 더 쉽게 이해할수 있다록 바꾸는 것이 리팩토링이다. 이것과 대조되는 좋은 퍼포먼스 최적화이다. 리팩토링과 마찬가지로 퍼포먼스 최적화도 보통 동작을 바꾸지는 않는다(속도는 뺴고). 단지 내부 구조를 바꿀 뿐이다. 그러나 그 목적이 다르다. 퍼포먼스 최적화는 종종 코드를 이해하기 더 어려게 만들지만, 필요한 퍼포먼스를 얻기 위해서는 그렇게 해야 한다.

 두 번째 강조하고 싶은 것은, 리팩토링은 겉으로 보이는 소프트웨어의 기능을 변경하지 않는다는 것이다. 리팩토링 후에도 소프트 웨어는 여전희 동일한 기능만을 가지고 있다. 어느 사용자도, 그것이 최종 사용자가 됐든 다른 프로그래머가 됐든 바뀐 것에 대해 알수 없다.

---------------------------------------------------------------------------------------------------

처음의 결심과 다르게 두번째 글을 적는데 몇일이 걸린것 같다. 이렇게 하여 뜻하는 바를 이룰 수 있을지.. 리팩토링을 하면 당장 눈에 보이는 어떠한 변화는 볼수가 없는것 같다. 어차피 돌아가기만 하면 되는데.. 구지 그렇게 바꿔야 하냐고 하는 개발자들이 눈에 밟힌다.
 그렇다고 내가 리팩토링에 눈이 띄어 천부적인 소질을 보이는것도 아니다. 난 단지 이제 막 첫발을 내딧고 있는 개발자다.
언제나 무언가를 처음하기에는 많은것이 요구 되는것 같다.
처음부터 잘하는 사람도 있겠지만.. 그런 사람보단 어리버리 하는 나같은 사람들이 많을것이라고 생각한다.
꾸준히 꾸준히 ... 하다 보면... 언젠가는 향기로운 냄새가 풍기는 코드를 짤 수  있겠지?



 
Posted by is윤군

댓글을 달아 주세요

BooK Plus2008.01.09 12:54
출처 : 리팩토링 ( 저자 : 마틴 파울러  / 윤성준 . 조재박 옮김)


---------------------------------------------------------------------------------------------------
리팩토링이란 무엇인가 ?

 리팩토링은 외부 동작을 바꾸지 않으면서 내부 구조를 개선하는 방법으로,
소프트웨어 시스템을 변경하는 프로세스이다. 이것은 버그가 끼어 들 가능성을 최소화하면서 코드를 정리 하는
정형화된 방법이다 . 본질적으로 우리가 리팩토링을 할 떄, 우리는 코드가 작성된 후에 코드의 디자인을 개선하는것이다.

"코드가 작성된 후에 디자인을 개선한다." 이상한 말이다. 현재 우리가 알고 있는 소프트웨어 개발에서
우리는 디자인을 한 다음 코딩을 하는 것이라고 믿고 있다. 좋은 디자인이 먼저이고, 그다음이 코딩이다.
그러나 시간이 지나면 코드는 수정될 것이고, 시스템 본래의 모습과 디자인을 따른 구조는 점점 사라질것이다. 코드는 천천히 엔지니어링에서 해킹 수준으로 떨어질 것이다.

리팩토링은 이런 관례와 반대이다. 리팩토링을 쓰면 서투른 디자인을 취해 재작업하여 잘 디자인된 코드로
만들수 있다. 각각의 단계는 아주 간단하다. 필드 하나를 다른 클래스로 옮기고, 메소드에서 코드의 한 부분을
따로 다른 메소드로 뽑아내고, 코드의 일부를 수퍼클래스나 서브클래스로 옮긴다. 그러나 이런 작은 변화가 쌓여서 근복적으로 디자인을 개선하게 된다.
보통의 소프트웨어 쇠퇴 개념과는 정확하게 반대이다.

리팩토링을 사용하면 작업의 밸런스가 바뀐다. 모든것을 미리 생각하기보다는 개발을 하면서 지속적으로 좋은
디자인을 찾는다. 시스템을 구축하면서 어떻게 디자인을 개선할지에 대해 배운다.
이런 작업은 개발이 계속되어도 프로그램의 디자인이 계속 좋은 상태로 남아있게 한다 .
---------------------------------------------------------------------------------------------------

좋은 말인것 같다...  나도 아직은 리팩토링이 가져다 주는 먼가의 이익이나 확실이 이놈을
해야 한다는 믿음은 아직 없다...
왜냐면 나는 아직... 초보 JOVO 프로그램머 이기 때문이다.
하지만...
리팩토링이 좋은거라는 느낌을 믿는다...
몇년 후에는 먼가 발전된 개발자가 되어 있었으면...
그날 까지
책과 함께 하는 포스팅을.... 계속되어야 한다....




Posted by is윤군

댓글을 달아 주세요