BooK Plus2011.11.23 13:59
기억은 겨울에 내뿜는 담배연기처럼 사라져갔다.
 오기사, 여행을 스케치하다 中.
Posted by is윤군
BooK Plus2010.07.24 22:53
출처 : 한빛미디어 홈풰이쥐! (http://www.hanb.co.kr/)

목차 : 
#1 - 주인장 잡설... 
#2 - 저자분과 윤군...
#3 - TDD 와 공중부양의 관계..
#4 - 예의상 책 이야기 한마디...


#1

책 관련 포스팅은 정말 정말이지 간만에 해보는 것 같다.
내가 책 포스팅을 안하는 이유는 귀찮아서가 첫번째 이유고. 난 블로그에 다가 그냥 잡다한 글만 적는 블로거이라서 먼가 정리되고 아기자기 하고 말들을 꾸며 적을 수도 없고 해서 잘 안적는다. 왠지 책관련 이야기는 잘 적어야 할 것 같은 느낌이 들기 때문에... (사설로 먼가 내용을 적어야 할 것 같은 기분이 들어서.. 몇자 끄적여 봤다..)

사실 책 내용 보단.. 책과 관련된 이야기를 하고 싶어서 포스팅을 시작함을 밝히는 바이다.
책내용이 좋은가 나쁜가를 검색하다가 이 글을 읽게 된다면 당장 페이지를 떠나가는게 현명할 듯.. ;; 


#2

자랑은 아니지만 해당 책의 저자분과는 약간(?) 어쩌면 좀더(?) 친분이 있는 관계이다. 물론 그 친분은 책의 주제인 TDD가 맺어준 인연이기도 하다. "팔은 안으로 굽는다"라는 말은 절대 틀린 말이 아니라고 난 생각하다. 그 뒤는 상상에 맡기겠;;;

저자분과 친분이 있다고 자랑하려고 하는건 아니다. 다만 저자분과의 친분이 있어 그동안 만나서 이야기 나누고 TDD 관련 수련법을 배우고, 가끔 저자분에게 조련 당하기도 하고, 같이 TDD 관련 일도 해보고, 책을 쓰시면서 베타리딩을 할 수 있는 기회까지 받으면서
아.. 이 아저씨가 하는 이야기는 정말 진국이구나.!!!
라는 믿음이 있음을 말하고 싶을 뿐이다. 그런 저자분이 일년여동안(기억이 가물가물하긴하다.ㅋ) 정말 열심히 쓴 책인데 이건 뭐 안 봐도 알 수 있는 비디오가 있듣이.. 안 봐도 책 알 수 있는 책 이라는 것이다.(말도 안되는 이야기 이지만... ;;)
사실 정말 열심히 책을 쓰는 모습은 보지는 못했지만.. 처음 나온 원고가 베타리딩을 거치고 출판되기 직전까지 정말 고생하는 모습은 옆에서 많이 봤다. 불쌍할 정도로.. 
무튼 저자분는 이런 아저씨 이다. 믿음이 가는 아저씨!!(물론 사적인 대화는 믿거나 말거나 하는 대화를 많이 한다. 개그 욕심이 좀 많이 있으셔서... )

#3

한국에 나온 TDD 관련 책중에 최고봉은 저자분의 친구인(언제나 친구인 것 처럼 말씀하셔서...) 켄트백 아저씨가 쓴 TDDBE 책이라고 생각한다. 나도 봤고 너도 봤을 꺼고. TDD에 관심이 있는 사람이라면 한번쯤 봤을 책이다. 책 내용은 정말이지 먼가 잘 적혀 있는 것 같다. 챕터 챕터 별로 점점 TDD로 해결 해가는 흐름.. 그리고 중간 중간 들어 있는 켄트백 아저씨의 개그.. 

좋다 좋아.. 그런데 정말이지 이 책을 읽고 ~ 자 TDD를 시작해보자.. 라고 덤벼들면. 나 같은 저랩 개발자는 어떻게 해야 할지 주춤 하게 된다. 물론 책만 보고 TDD를 할 수 있는 그런 책이 있다면 아마 성경책보다 많이 팔릴 최고의 베스트 셀러가 될지도...;; 
TDD는 오락 책에서 나오는 헤이야치 십단콤보 보고 직접 오락실에서 쉽게 십단콤보를 사용 할 수 있는 쉬운 녀석이 아니고 허형님의 공중부양 처럼 꾸준한 수련을 통해서 얻을 수 있는 머 그런 녀석인 것이라고 생각한다. 적어도 나는...!

그럼 책같은 건 왜 보냐? 라고 할 수 있는데.. 수련도 수련법을 알아야 할 수 있지 않는가.. 설마 허형님이 아무런 레퍼런스 없이 그 어렵다는 공중부양을 성공시켰을까ㅡㅡ; 


#4

내가 생각하는 이 책은 이렇다고 생각한다. (사실 힘들게 나온 책이라는 걸 아는 상황에서 좋은 말만 적고 싶다... )
  • 완전 아무것도 모르는 사람이 무작정 이 책 하나로 TDD를 정복하겠다고 덤벼들면 약간은 말리고 싶다. 말리는 이유는 TDD a-Z 까지 .. 이런 식의 책이 아니라서... 책의 구성을 보면..... :-)
  • TDD는 대충 뭐 하는 녀석인지 알겠는데.. 먼가 어렵게 느껴지는 분..!! 강추!! - 실제 나도 TDD 프로젝트를 하면서 베타리딩 할 때 받은 원고에서 실제 많은 도움을 받았음. 프로젝트 구조 부터..시작해서.. 덩덩덩~
  • 책 뒤에 나오는 실습예제는 꼭 한번쯤은 해보았으면 함. - 특히 자동판매기 잔돈 계산 모듈 요건.. 저자분에게 조련 한번 시켜달라고 이메일 한번 보내보는 것도 나쁘지 않아고 생각됨.!
  • 번외 이야기이지만 TDD 말고도 다른 부가적인 녀석들을 많이 알 수 있게됨. (궁금하시면 책 사보셔요~~)
  • 마지막으로.. 전문가 인터뷰에 윤군 인터뷰가 없어서.. 무척 아쉽.! (너구리님과 꼬마사자님은 반성하세욥.ㅋ)


Posted by is윤군
BooK Plus2009.04.14 22:50

봄싹 스터디에서 진행하는 프로스프링2.5 베타리딩을 했습니다!
봄싹 대장 기선이 형 덕분에 재미있는 경험을 하게되었죠 >>ㅑ~!

1월 23일 부터 4월 13일 까지 두달 보름정도 진행을 했었는데...
900 페이지가 넘는 엄청난 양의 책이 었죠;;;
총 22장으로 이루어지고 스프링 2.5 의 전반과 후반부에 orm / remote / web service / mvc / 패턴 / 튜팅 / 기타 등등..
많은 정보들을 다루는 도서였습니다..

전 리딩중에 맡은 건 ! 코드 검증 이었습니다!
모 사이트에 책에 대한 리뷰에 예제 코드 소스가 X판이라는 이야기가 들린터라서 ..
검증에 나섰죠;;

딱 끝나고 나니 그런 말이 왜 나왔는지 느낌이 오더라구요~;;
http://www.apress.com/ 해당 출판사 사이트에 가시면 프로 스프링2.5 원서에 같이 배포된 소스 코드를 받을 수 있는데..
프로젝트들이  Intellij의 IDE기반으로 되어있다. 개인적으로는 좀 생소으나 IDE가 문제 될건 없었는데.... 일단 해당 프로젝트에서 사용되는 lib들이 하나도 없다!
그래서 손수 다 찾아서 해야만 하고... 코드들에 오류들이 있었다...
컴파일 조차 안되는 코드들도 존재 했고.. 제대로 실행되지 않는 코드들도 존재 했다..
그리고 결정적으로 책에서 나온 코드들과 다소 다른 코드들도 존재 하고..
여러명이서 작업을 했는지... 쳅터별로 프로젝트 구조들도 달랐고... 통일이 되지 않았다..
물론 책내용이 중요하지만... 독자들을 위해서 소스코드에 좀만더 신경써주었으면 어땠을 까 하는 생각이 들었다..

나처럼 허접한 사람이 예제들을 돌려보기에는 많은 난관들이 있었기에 말이다..
그래서 한글 번역본에선 이러한 불편했던 점들을 최대한 해결하기 위해서..
노력을 했다.. 우선 모든 프로젝트의 구조를 통일화 시켰고.. (소스코드의 위치정도..)
컴파일이 다 잘 될 수 있도록 코드를 수정하고, 가장 시간이 많이 들었던 의존관계를 가지는 lib들을 일일이 다 찾았다.. 그리고 모든 코드들을 책내용의 아웃풋과 비교 하면서 소스 코드들을 돌려 보았고..
결국 이클립스 기반의 메이븐 프로젝트들로 새롭게 작업을 마쳤다!

물론 100%완벽하다고는 생각하지는 않는다..
그래도 100%가 되기 위해서 많은 시간을 투자하여 ~ 열심히 작업을 했다..
덕분에 나 또한 접해보지 못했던 부분들도 마니 접할 수 있게 되었고.. ;;
덕분에 900페이지가 넘는 prospring책을 다 읽었다는거?
무튼 만족만족!! 어여 빨리.. 번역된 prospring2.5 책을 하루 빨리 다시 만나보고 싶을 따름이다..ㅋㅋ

함꼐 배타리딩을 진행한 봄싹 식구들과 도와 주신 몇몇 분들에게 수고하셨다는 말을 드리고 싶다! 수고하셨네요~~~

Posted by is윤군
BooK Plus2008.11.22 23:51
- 요구 사항
  •  그것은 여러분의 시스템이 올바르게 동작하기 위해서 수행하는 특정한 하나의 일!
  •  하나의 요구 사항은 특정 상품이나 서비스가 어떤것이어야 하는지
     또는 무엇을 수행해야 하는지를 자세하게 설명하는 것. 
  • 주로 시스템 엔지니어링이나 소프트웨어 엔지니어링 분야에서 공식적으로 자주 사용.
- 고객에게 귀를 기울이라. : 고객이 말하게 하는 것이 요구 사항을 얻는 가장좋은 방법.
[유즈케이스 작성]
- 요구사항 리스트 만들기.
- 해야 할일 목록 만들기.
- 문제 대체 경로 해결.

좋은 요구사하을 얻는 가장 좋은 방법은 시스템이 무엇을 해야 하는지 이해하는 것!


2장에선
토드와 지나의 강아지 문이라 예제로 주인공이 토드와 지나의 요구사항들을
수집해나가고 있다.
해당장은 까득이나 글자 없는 책인데;; 더 글자를 찾아보기 힘들정도록..
페이지가 그림으로 가득차있고;; 흥미를 끌만하게 되어 있다..

프로젝트에서 고객의 요구사항을 받으면서 내심 짜증이 나기도 했다;; 그냥 대충 쓰면 안될까 라고 하는;;
물론 개중에 완전 진상인 고객들의 요구사항을 받으면서 들었던 생각인데;;
내심 그들에게.. 올바르지 못한 프로그램을 만들어준듯해서;; 찝찝해지는 이유는 무엇일까?

흠냥;; 앞으론;;; 공손한 태도로 고객의 요구사항에 귀를 기울여보는것도 나쁘지 않은듯하다..



 

Posted by is윤군
BooK Plus2008.11.21 23:51

위임

한 객체가 오퍼레이션(기능)을 다른 객체에게 넘겨주어 첫번째 객체를 대신해서 수행하도록 하는 행위.
객체가 어떤 일을 할 때 직접 하지 않고 다른 객체가 그 일을하도록 하는 것을 의미 하기도 함.
대표적인 위임 - > equals() 메소드.
좋은점 . 코드의 재사용성이 좋아짐. 각 객체가 자기 자신의 기능만 하면 되고,
한 객체의 기능을 여러 곳에 분산할 필요가 없다.
객체가 서로 돍립적이고 더 느슨하게 결합되어 잇는 것을 의미.
느슨하게 결합된 객체는 다른 객체들의 코드와 단단하게 결합되어 있지 않기 때문에 하나의
프로그램에서 빼내어 다른 프로그램에서 재사용하는 것이 쉽다.
정리 끝; 핵심정리..


핵심정리.

  • 깨지기 쉬운 프로그램은 조금만 잘못 조작해도 문제가 발생.
  • 캡슐화와 위임 같은 객체지향 원리를 사용하여 유연한 프로그램을 만들 수 있다.
  • 캡슐화는 프로그램을 여러 개의 노리적 부분들로 나눔
  • 위임은 특정한 일을 해결하는 책임을 다른 객체에게 주는 것.
  • 기본 기능을 구현한 후에 설계를 유연하게 가다듬는데 노력!
  • 자주 변경을 요하는 부분을 찾아서 변경되지 않는 부분과 분리.
  • 기능과 유연한 설계가 완성이 되면, 디자인 패턴을 사용해서 프로그램의 디자인을 개선, 재사용이 용이하게 만듬.


몇일에 걸쳐서 ... 몇페이지 안되는 장을 읽었다.. ;; 이해가 가지 않아서 몇번이고 다시 보면서 읽는다고
시간이 조금 걸렸다. head First 책 시리즈 특징은 글이 거의 없다는 것!
1장에선 몇몇 중요한 객체지향에 대한 개념들을 살며서 녹혀놓은 듯 하다.

나중에 알고 보면 이것이 객체 지향에서 말하는 것들이나 느낄 수 있을것 같은 그런 느낌?
인식하지 못하면서 무언가를 살며시 가르쳐준다고 해야 할까;;
뭐 나만의 헛소리 일수도 있다..ㅋ

무튼;; 시작이 반이라는 말이 있다;; 앞으로 남은 9장 쳅터도 ... 꾸준히 읽고 복습하고 살포시 느껴보자.. OO에 대해서;;; 어쩌면 그동안 찾고 싶었던 OO에 대해서 먼가... 건질 만한게 있을것 같은 좋은 느낌이다..





Posted by is윤군
BooK Plus2008.11.19 20:40
1. 객체는 자신의 이름이 나타내는 일을 해야함.
 - 객체의 정해진 이름에 따라서 그 이름에 맞는 행동만 해야함.
    비행기 객체이면 이륙하고 착륙(O), 비행기 티켓을 받는 일을 하면 (X)

2. 각 객체는 하나의 개념을 나타내어야 함
  - 오리 객체일 경우 , 꽥꽥 거리는 오리 , 노란 플라스틱 오리, 장난감오리 , 오리 같이 행동하는
     사람의 세가지 개념을 나타내는 것을 피해야 함.
      (Head First 씨리즈는 오리 예제를 좋아하는듯;  디자인 페턴에 보면 해당 오리 예제가 나오며,
       그걸 스트래티지 패턴페턴을 이용해서 풀었던 기억이;;;; )

3. 사용되지 않는 속성이 결정적 증거임.
  - 객체가 값이 없거나 NULL인 속성들을 가진 채로 사용되면,
    객체가 하나 이상의 일을 하고 있을 가능성이 있다.

    
객체 모델링을 할때 참고 하면 좋을듯;;
음...
BbsInfo 라는 객체는 무슨일을 하려나..,, 그리고 너무 포괄적인 개념인가 ?
사용되지 않는 속성은 없어보이고;;
일단 다시 한번 모델을 생각해봐야 겠음.


Posted by is윤군
BooK Plus2008.11.18 13:02
출처 : http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=1999551&CategoryNumber=002001008

- 쉬운 3단계로 위대한 소프트웨어 만들기
  1. 여러분의 소프트웨어가 고객이 원하는 기능을 하도록하세요
  2. 객체지향의 기본 원리를 적용해서 소프트웨어를 유연하게 하세요.
  3. 유지보수와 재사용이 쉬운 디자인을 위해 노력하세요.

- 문제를 해결하면서 새로운 문제를 만들지 마세요.

- 캡슐화의 장점 : 프로그램을 쪼개내어 다른 부분의 수정 없이 특정 부분을 변경할 수 있음. 일반적으로 프로그램 중에 변화 가능성이 높은 부분을 그렇지 않은 부분으로부터 분리하여 캡슐화하게 됨.


Posted by is윤군
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윤군