BackLinks of Refactoring

Search BackLinks only
Display context of search results
Case-sensitive searching

• 리팩토링 Redirect page
       #redirect Refactoring
• 1002/Journal
       추후 ["Refactoring"] & 다른 위키 페이지에 해당 지식 분양용.
        * 쌓아나가야 할 부분이 상당히 많아보이는데.. Refactoring 에서의 경험을 어설프게 가로질러본다면. ReFactoring 을 할때 나쁜 클래스들을 그 안에서 계속 고쳐나가는 것 보단, 새 클래스나 메소드들을 중간에 만든뒤, 나쁜 클래스들을 삭제하는게 더 빠른 방법이다. 좋은 습관을 만들어내는 것이 나쁜 습관을 고쳐내려고 하는것보다 최종적으로 볼땐 더 접근하기 쉽지 않을까 하는 생각을 해본다. 나쁜 점이라 생각하는것은, 의식화해서 고치는 것 보단 좋은 습관으로 대체하고 나쁜 습관을 아에 잊어버리게끔 하는것이 더 나은것 같다.
       이번에 리팩토링을 하려고 할때 Legacy Code Refactoring 이라고 상정해서 그럴까. Coverage Test를 완벽하게 작성하는 것에 대해 부담감을 느꼈다. 예전에 유용했었던 '아아. 이미 다 되어있어요.~' 를 다시 적용해볼까.
       Refactoring Catalog 정독. 왜 리팩토링 책의 절반이 리팩토링의 절차인지에 대해 혼자서 감동중.; 왜 Extract Method 를 할때 '메소드를 새로 만든다' 가 먼저인지. Extract Class 를 할때 '새 클래스를 정의한다'가 먼저인지. (절대로 '소스 일부를 잘라낸다'나 '소스 일부를 comment out 한다' 가 먼저가 아니라는 것.)
       ProjectPrometheus Refactoring 궁리하기
       Refactoring 을 하기전 Todo 리스트를 정리하는데만 1시간정도를 쓰고 실제 작업을 들어가지 못했다. 왜 오래걸렸을까 생각해보면 Refactoring 을 하기에 충분히 Coverage Test 코드가 없다 라는 점이다. 현재의 UnitTest 85개들은 제대로 돌아가지만, AcceptanceTest 의 경우 함부로 돌릴 수가 없다. 왜냐하면 현재 Release 되어있는 이전 버전에 영향을 끼치기 때문이다. 이 부분을 보면서 왜 JuNe 이 DB 에 대해 세 부분으로 관리가 필요하다고 이야기했는지 깨닫게 되었다. 즉, DB 와 관련하여 개인 UnitTest 를 위한 개발자 컴퓨터 내 로컬 DB, 그리고 Integration Test 를 위한 DB, 그리고 릴리즈 된 제품을 위한 DB 가 필요하다. ("버전업을 위해 기존에 작성한 데이터들을 날립니다" 라고 서비스 업체가 이야기 한다면 얼마나 황당한가.; 버전 패치를 위한, 통합 테스트를 위한 DB 는 따로 필요하다.)
       아직은 필요한 시스템만 Install 하는 목표에 충실하도록 노력하자. ["Refactoring"]. NoSmok:필요한만큼만 .
       혹시 FakeIt & Refactoring 으로 진행이 가능할까 생각해보면서 처음에는 FakeIt & Refactoring 만으로 진행해보았다. 근데, FakeIt 을 하고 ["Refactoring"] 을 하려 할때 너무 재정의를 많이 하는 것 같아서 대강 넘어갔는데, 그랬더니 다음 테스트로 진행하기 너무 힘들었다. 알고리즘이 어느정도 보이려고 할때, 앞에서의 FakeIt 으로 유도된 코드들을 수정하는게 아니라 아에 뜯어야 할 것 같아서 망설여졌다.
        * 다양한 경험 - 내용을 만들어내려면, 그만큼 경험이 필요하기에. 성장계단이라던가, 자신이 '배운' 내용을 '적용' 해볼 수 있는 터로서 이용한다던가, ["Refactoring"] 과 프로그래밍 개발의 관점에서 설명한다던가 등등 (이것같은 경우 내용을 알고 있어도, 사람들의 레벨에 맞춰야 하기때문에 적절하게 꺼낼 타이밍을 맞춰야 할것 같은데. 이야기가 흘러가면서 페이지 구조조정, ["Refactoring"] 으로까지의 이야기흐름전개. 어떻게 흘러온걸까.)
        * 학교에서 레포트를 쓰기 위해 (["ProgrammingLanguageClass/Report2002_2"]) 도서관에 들렸다. HowToReadIt 의 방법중 다독에 관한 방법을 떠올리면서 약간 비슷한 시도를 해봤다. (오. 방법들 자체가 Extreme~ 해보인다;) 1시간 30분 동안 Java 책 기초서 2권과 원서 1권, VB책 3권정도를 훑어읽었다. (10여권까지는 엄두가 안나서; 도서관이 3시까지밖에 안하는 관계로) 예전에 자바를 하긴 했었지만, 제대로 한 기억은 없다. 처음에는 원서와 고급서처럼 보이는 것을 읽으려니까 머리에 잘 안들어왔다. 그래서 가장 쉬워보이는 기초서 (알기쉬운 Java2, Java2 자바토피아 등 두께 얇은 한서들) 를 읽고선 읽어가니까 가속이 붙어서 읽기 쉬웠다. 3번째쯤 읽어나가니까 Event Listener 의 Delegation 의 의미를 제대로 이해한 것 같고 (예전에는 소스 따라치기만 했었다.) StatePattern으로의 진화 (진화보단 '추후적응' 이 더 맞으려나) 가 용이한 구조일 수 있겠다는 생각을 하게 되었다. (Event Listener 에서 작성했던 코드를 조금만 ["Refactoring"] 하면 바로 StatePattern 으로 적용을 시킬 수 있을 것 같다는 생각이 들었다. 아직 구현해보진 않았기 때문에 뭐라 할말은 아니지만.) 시간이 있었다면 하루종일 시도해보는건데 아쉽게도 학교에 늦게 도착해서;
• CppStudy_2002_2
       || 8.1 ||["Refactoring/ComposingMethods"]||몇개 소스 리팩토링 해보기||
        * ["Refactoring"] 책을 보고 있다면, 이번이 아마 Bad Smells 를 인식할 수 있는 좋은 기회가 될것임. ^^ --["1002"]
• DelegationPattern
       또한, 클래스 하나가 방대해질때, 적절하게 그 클래스의 책임을 다른 클래스들에게 위임해주는 것은 ["Refactoring"] 의 방법이 된다.
       example) 예전에 VonNeumannAirport 을 JuNe 과 ["1002"] 가 Pair 하던중 JuNe 이 작성했던 Refactoring 으로서의 Delegation.
       이 기능을 추가하기 위해 일단 Airport Code 를 Refactoring 하기로 했다. 이를 위해 Airport 의 기능중 Configuration 과 관련된 기능에 대해 Configuration 을 Extract 하고, 내부적으로는 Delegation 함으로서 외부적으로 보이는 기능에 대해서는 일관성을 유지한다. (Test Code 가 일종의 Guard 역할을 했었음)
       ["ResponsibilityDrivenDesign"] , ["Refactoring"], ["DelegationPattern"] 을 꾸준히 지켜주면 좋은 코드가 나올 수 있다. (["DesignPattern"] 이 유도되어짐)
• Eclipse
        * quick fix, UnitTest, [Refactoring], [CVS], 그리고 방대하고 다양한 플러그인들이 제일 마음에 든다. 툴을 사용하는 재미가 있다. - [임인택]
• Eric3
       무료 Python IDE. 제공하는 기능이 꽤 많은듯 하다. [Refactoring]을 지원하는게 가장 큰 기능중의 하나가 아닐까 생각한다.
• ExtremeProgramming
       ExtremeProgramming 은 경량개발방법론으로서, RUP 등의 방법론에 비해 그 프로세스가 간단하다. XP 에서의 몇몇 개념들은 일반적인 프로그래밍에서도 유용하게 쓰일 수 있다. 특히 TestDrivenDevelopment(TestFirstProgramming) 의 개념과 Refactoring, UnitTest는 초기 공부할때 혼자서도 실습을 해볼 수 있는 내용이다. 개인 또는 소그룹의 훈련으로도 이용할 수 있을 것이다.
       Iteration 중에는 매일 StandUpMeeting 을 통해 해당 프로그램의 전반적인 디자인과 Pair, Task 수행정도에 대한 회의를 하게 된다. 디자인에는 CRCCard 과 UML 등을 이용한다. 초기 디자인에서는 세부적인 부분까지 디자인하지 않는다. XP에서의 디자인은 유연한 부분이며, 초반의 과도한 Upfront Design 을 지양한다. 디자인은 해당 프로그래밍 과정에서 그 결론을 짓는다. XP의 Design 은 CRCCard, TestFirstProgramming 과 ["Refactoring"], 그리고 StandUpMeeting 나 PairProgramming 중 개발자들간의 대화를 통해 지속적으로 유도되어지며 디자인되어진다.
       개발시에는 PairProgramming 을 한다. 프로그래밍은 TestFirstProgramming(TestDrivenDevelopment) 으로서, UnitTest Code를 먼저 작성한 뒤 메인 코드를 작성하는 방식을 취한다. UnitTest Code -> Coding -> ["Refactoring"] 을 반복적으로 한다. 이때 Customer 는 스스로 또는 개발자와 같이 AcceptanceTest 를 작성한다. UnitTest 와 AcceptanceTest 로서 해당 모듈의 테스트를 하며, 해당 Task를 완료되고, UnitTest들을 모두 통과하면 Integration (ContinuousIntegration) 을, AcceptanceTest 를 통과하면 Release를 하게 된다. ["Refactoring"] 과 UnitTest, CodingStandard 는 CollectiveOwnership 을 가능하게 한다.
        * TestDrivenDevelopment : Programming By Intention. 프로그래머의 의도를 표현하는 테스트코드를 먼저 작성한다. 그렇게 함으로서 단순한 디자인이 유도되어진다. (with ["Refactoring"])
        * ["Refactoring"] : 코드를 향상시키기 위한 프로세스
• FundamentalDesignPattern
       DesignPatterns 의 패턴들에 비해 구현이 간단하면서도 필수적인 패턴. 전체적으로 가장 기본이 되는 소형 패턴들. 다른 패턴들과 같이 이용된다. ["Refactoring"] 을 하면서 어느정도 유도되는 것들도 있겠다. (Delegation의 경우는 사람들이 정식명칭을 모르더라도 이미 쓰고 있을 것이다. Java 에서의 InterfacePattern 도 마찬가지.)
• HowToStudyDesignPatterns
        1. ["Refactoring"] by Martin Fowler : DP 공부 이전에 봐서 문제의식 형성하기 (망치를 들면 모든 것이 못으로 보이는 오류 탈피)
       see also HowToStudyRefactoring, HowToStudyXp
• HowToStudyRefactoring
       ["Refactoring"]을 혹은 동명의 책을 공부하는 법
       OOP를 하든 안하든 프로그래밍이란 업을 하는 사람이라면 이 책은 자신의 공력을 서너 단계 레벨업시켜 줄 수 있다. 자질구레한 기술을 익히는 것이 아니고 기감과 내공을 증강하는 것이다. 혹자는 DesignPatterns 이전에 ["Refactoring"]을 봐야 한다고도 한다. 이 말이 어느 정도 일리가 있는 것이, 효과적인 학습은 문제 의식이 선행되어야 하기 때문이다. DesignPatterns는 거시적 차원에서 해결안들을 모아놓은 것이다. ["Refactoring"]을 보고 나쁜 냄새(Bad Smell)를 맡을 수 있는 후각을 발달시켜야 한다. ["Refactoring"]의 목록을 모두 외우는 것은 큰 의미가 없다. 그것보다 냄새나는 코드를 느낄 수 있는 감수성을 키우는 것이 더 중요하다. 본인은 일주일에 한 가지씩 나쁜 냄새를 정해놓고 그 기간 동안에는 자신이 접하는 모든 코드에서 그 냄새만이라도 확실히 맡도록 집중하는 방법을 권한다. 일명 ["일취집중후각법"]. 패턴 개념을 만든 건축가 크리스토퍼 알렉산더나 GoF의 랄프 존슨은 좋은 디자인이란 나쁜 것이 없는 상태라고 한다. 무색 무미 무취의 無爲적 自然 코드가 되는 그날을 위해 오늘도 우리는 리팩토링이라는 有爲를 익힌다. -- 김창준, ''마이크로소프트웨어 2001년 11월호''
        * Pair Refactoring : 함께 리팩토링한다. 혼자 하는 것 보다 훨씬 빨리 훨씬 더 많은 것을 배울 수 있다. 특히, 각자 작성했던 코드를 함께 리팩토링하고, 제삼자의 코드를 또 함께 리팩토링해 보라. 사람이 많다면 다른 페어가 리팩토링한 것과 서로 비교하고 토론해보라.
• HowToStudyXp
        * ["Refactoring"] (by Martin Fowler) : 리팩토링에 대한 최고의 책
        * http://groups.yahoo.com/group/refactoring
• Java
        ||["IntelliJ"]|| ["Refactoring"] 기능과 깔끔한 UI 가 돋보인다.||
• MineFinder
        * 추후 DP 로 확장된다면 StrategyPattern 과 StatePattern 등이 이용될 것 같지만. 이는 추후 ["Refactoring"] 해 나가면서 생각해볼 사항. 프로그램이 좀 더 커지고 ["Refactoring"] 이 이루어진다면 DLL 부분으로 빠져나올 수 있을듯. ('빠져나와야 할 상황이 생길듯' 이 더 정확하지만. -_-a)
        * Main Design, Algorithm 1차 완성. 어느정도 Refactoring의 추구.
        * CppUnit - 이번 플밍때 윈도우 메세지 관련 처리에 대해서는 코드를 작성못했다. (이 부분에 대해서는 전통적인 Manual Test방법을 쓸 수 밖에. GUI Testing 관련 글을 더 읽어봐야 겠다. 아직 더 지식이 필요하다.) 단, 나중에 비트맵 분석부분 & Refactoring 시에 TFP 를 할 수 있게 되었다.
• OnceAndOnlyOnce
       OAOO. 필요한 부분에 대해서는 중복없이 오직 한번만 나타나야 한다는 원칙. ["Refactoring"] 의 원칙.
• ProjectPrometheus/Journey
        * Side Effect 는 Refactoring 의 적이라는 생각이 오늘처럼 든 적이 없었다. -_-; Extract Method 같은 일을 하는 경우 더더욱.! --["1002"]
        * Server Refactoring
       서버쪽 클래스들에 대해서 Refactoring 을 시도 데이터클래스이면서 그 용도가 조금씩 달랐던 클래스들을 하나로 묶었다. (일단 모여해쳐 시도용으로) 그러면서 안쓰는 클래스들을 조금씩 지워나갔다. 패키지들중 Test 패키지와 메인 소스 패키지, 임시 코드 패키지들에 대해서 화일들을 옮기고 정리했다. 아직 완벽하게 정리된것 같진 않지만, 개인적으로는 이전에 비해 만족스러웠다. (이제 Target은 Resin 쪽과 임시소스들 디렉토리.)
        * Code Review 로서 Refactoring 이 이용된다고 했다시피, Refactoring을 해 나가면서 전체 프로그램의 그림이 좀 더 이해가 갔다. 한동안 해당 프로그램에 대해서 플밍 리듬을 놓쳤을때 Refactoring 을 시도하는것도 좋은 전략이라 생각.
        * Task 를 작성할때 Refactoring 을 명시적으로 써 놔야 하겠다. Acceptance Test 처럼. 써놓지 않으니까 잊어먹고 자주 안해준 것 같다. 그리고 생각보다 시간이 걸리는 만큼. (이건 Refactoring 을 플밍 중에 자주 해주지 않아서인것 같다. 2시간정도 걸렸으니)
        * 자칫 RDD 에서의 그 세부클래스들에 대해서 너무 많이 생각하면 BUFD(Big Up-Front Design) 이 되리라 생각한다. 차라리 Class 가 2개였을때 코딩 들어가고, 20-30분 정도 코딩뒤 ["Refactoring"] 을 의식적으로 하여 Big Class 에 대해 Extract Class 를 추구하는게 더 빠르지 않았을까.
• ProjectZephyrus/ClientJourney
        * 일이 거의 막마지에 다다른다. 12시 이후 본격적 작업. 이틀간의 스케줄에서 둘이 참여를 하지 않았으므로, 작업은 주로 코드 설명이 주가 될 수 밖에 없었다. Pair로 ["Refactoring"] 해나가며 설명하기에 내가 너무 많이 코드를 고쳤나. -_-; (나도 할말있는것이, 가장 중요사항중 하나인 패킷 핸들러 처리부분할때 다들빠지냐는것이다. -_-; 제일 얻을 것도 많은 부분일건데 쩝. 개인적으로 만들면서 흐뭇(^^;) 했던 부분이고;)
        * TDD 가 아니였다는 점은 추후 모듈간 Interface 를 결정할때 골치가 아파진다. 중간코드에 적용하기 뭐해서 궁여지책으로 Main 함수를 hard coding 한뒤 ["Refactoring"] 을 하는 스타일로 하긴 하지만, TDD 만큼 Interface가 깔끔하게 나오질 않는다고 생각. 차라리 조금씩이라도 UnitTest 코드를 붙이는게 나을것 같긴 하다. 하지만, 마감이 2일인 관계로. -_- 스펙 완료뒤 고려하던지, 아니면 처음부터 TDD를 염두해두고 하던지. 중요한건 모듈자체보다 모듈을 이용하는 Client 의 관점이다.
• PythonLanguage
        * TestFirstProgramming, UnitTest(PyUnit 참고), ["Refactoring"] 등의 방법론을 같이 접목시키면 더욱 큰 효과를 발휘할 수 있다.
• REFACTORING
       http://www.refactoring.com/catalog/index.html - Refactoring 에 대해 계속 정리되고 있다.
       == Refactoring 이란 무엇인가? ==
        * 기존의 "디자인 후 코딩' 법칙과 반대된다. (TestFirstProgramming 에서 UnitTest - ["Refactoring"] 이 맞물려 돌아간다)
        * Refactoring 을 하기 위해서는 UnitTest code가 필수적이다. 일단 처음 Refactoring에 대한 간단한 원리를 이해하고 싶다면 UnitTest 코드 없이 해도 좋지만, UnitTest code를 작성함으로서 Refactoring 에 대한 효과를 높일 수 있다. (Refactoring 중 본래의 외부기능을 건드리는 실수를 막을 수 있다.)
       == Refactoring 을 함으로써 얻는 이득 ==
       == Refactoring은 언제 하는가? ==
        * 다시 또 뭔가 비슷한 일을 한다. - Refactoring을 할 때이다. Refactoring 하라.
       Three Strike 법칙은 외우기 쉬워서 처음 Refactoring 을 하는 사람들에겐 적당하다. 하지만, 저 법칙은 주로 중복이 일어날 때의 경우이고, Rename Method/Field/Variable 같은 Refactoring 은 지속적으로 해주는 것이 좋다.
       그리고 다음과 같은경우 Refactoring을 함으로써 이득을 얻을 수 있다.
        * Bad Smell 이 날때. - ["Refactoring/BadSmellsInCode"]
       == Refactoring 공부하기 ==
       Refactoring 책을 읽는 사람들을 위해. Preface 의 'Who Should Read This Book?' 을 보면 책을 읽는 방법이 소개 된다.
        * Refactoring이 무엇인지 알고 싶다면 Chapter 1의 예제를 읽어나간다.
        * 왜 Refactoring을 해야 하는지 알고 싶다면 Chapter 1,2를 읽어라.
        * 어떤 부분을 Refactoring 해야 하는지 찾기 원한다면 Chapter 3를 읽어라.
        * 실제로 Refactoring을 하기 원한다면 Chapter 1,2,3,4를 정독하고 RefactoringCatalog 를 대강 훑어본다. RefactoringCatalog는 일종의 reference로 참고하면 된다. Guest Chapter (저자 이외의 다른 사람들이 참여한 부분)도 읽어본다. (특히 Chapter 15)
       그리고 Refactoring 을 이해하는데 ExtremeProgramming 을 이해하면 도움이 될 것이다.
       == Refactoring 관련 토론 ==
       ["RefactoringDiscussion"]
       == Refactoring 과 Test Code ==
• RandomWalk/임인택
       === 소스 2 : 1에 [STL]을 사용하고 약간의 [Refactoring] ===
        - 별로 OO 적이지 못한것 같다...(Roach 와 Board 객체가 [양방향참조]를 한다). DesignPatterns 를 참고하면서 보았어야 하는데.. 나중에 [Refactoring] 해야 함..
• Refactoring/BadSmellsInCode
       Refactoring이 동작하는 매커니즘을 아는 것 만큼 중요한 것은, 언제 Refactoring을 적용할까 하는 것이다.
       내가 이 문제로 Kent Beck 을 방문했을 때 그는 "언제" 를 설명하기 위해서 "Smell" 이라는 표현을 사용했다. 우리는 많은 코드들을 보았고, 그것들을 보면서 Refactoring이 적용가능한 어떤 구조를 발견했다.
       여기에서 우리는 Refactoring이 적용가능한 아주 정확한 척도를 제공하려고는 하지 않을 것이다. 경험상, 어떠한 측정도구들도 숙련된 인간의 직관의 경쟁상대가 될 수는 없었다. 우리가 하려는 것은 Refactoring에 의해 해결될 수 있는 문제들이 있는 몇몇 부분을 지적하려는 것이다.
       어떠한 Refactoring을 해야 할 지 확신할 수 없을때 이 부분을 읽어라. 정확하게 똑같은 Smell을 발견할 순 없더라도 Refactoring에 대한 올바른 방향을 가리켜 줄 지침이 될 것이다.
       전에 JuNe 형이 최한기의 신기통을 언급하면서 Metaphor 로서 'Smell' 이 잘 맞아떨어짐을 이야기하던게 생각. '냄새란 일단 그 자체로 악취를 풍길 뿐만 아니라, 밖으로 점차적으로 퍼지고, 사람에게 배어들 수 있으며, 사람에게 배어들고 나면 그 사람이 냄새에 대해 인식을 하지 못한다.'. Smell 에 민감한 사람들은 작은 Refactoring 도 잘 해낼 수 있다. -- ["1002"]
       ["Refactoring"]
• Refactoring/BigRefactorings
       = Chapter 12 Big Refactorings =
       ["Refactoring"]
• Refactoring/BuildingTestCode
       이정도에서 이야기는 충분하다 본다. 비록 내가 self-testing code를 작성하는 것이 모두에게 이익이 된다고 생각하더라도, 그것은 이 책의 핵심이 아니다. 이 책은 Refactoring에 관한 것이다. Refactoring은 test를 요구한다. 만일 Refactoring 하기 원한다면, test code를 작성해야 한다.
       ["Refactoring"]
• Refactoring/ComposingMethods
        * You have a temp that is assigned to once twith a simple expression, and the temp is getting in the way of other refactorings. [[BR]] ''Replace all references to that temp with the expression.''
       ["Refactoring"]
• Refactoring/DealingWithGeneralization
       ["Refactoring"]
• Refactoring/MakingMethodCallsSimpler
       ["Refactoring"]
• Refactoring/MovingFeaturesBetweenObjects
       ["Refactoring"]
       ["Refactoring"]
• Refactoring/OrganizingData
       ["Refactoring"]
       ["Refactoring"]
• Refactoring/RefactoringReuse,andReality
       = Chapter 13 Refactoring Reuse, and Reality =
       === Refactoring to Achive Near-term Benefits ===
       === Reducing the Overhead of Refactoring ===
       === Refactoring Safely ===
       == Resources and References for Refactoring ==
       ["Refactoring"]
• Refactoring/RefactoringTools
       = Chapter 14 Refactoring Tools =
       == Refactoring with a Tool ==
       == Technical Criteria for a Refactoring Tool ==
       == Practical Criteria for a Refactoring Tool ==
       ["Refactoring"]
• Refactoring/SimplifyingConditionalExpressions
       ["Refactoring"]
• RefactoringCatalog
       ["Refactoring/ComposingMethods"]
       ["Refactoring/MovingFeaturesBetweenObjects"]
       ["Refactoring/OrganizingData"]
       ["Refactoring/SimplifyingConditionalExpressions "]
       ["Refactoring/MakingMethodCallsSimpler"]
       ["Refactoring/DealingWithGeneralization"]
       == Chapter 12 Big Refactorings ==
       ["Refactoring/BigRefactorings"]
       ["Refactoring"]
• RefactoringDiscussion
       Refactoring 과 관련된 토론, 질문/답변의 장으로 활용한다.
       refactoring 의 전제 조건은, '''Refactoring 전 후의 결과가 같아야 한다.''' 라는 것이다.
       Martin Folwer의 Refactoring p326(한서), 10장의 Parameterize Method 를 살펴보면 다음과 같은 내용이 나온다.
       '''"MatrinFowler의 추종자들은 lastUsage()가 0 이상인 값에 대해 동작하는것일테니 (코드를 보고 추정하면 그렇다) 당연한거 아니냐?"''' 라고 이의를 제기할지는 모르지만, 이건 Refactoring 에서 한결같이 추구했던 "의도를 명확하게"라는 부분을 Refactoring이라는 도구에 끼워맞추다보니 의도를 불명확하게 한 결과를 낳은것 같다. (["망치의오류"])
       로직이 달라졌을 경우에 대한 검증에 대해서는, Refactoring 전에 Test Code 를 만들것이고, 로직에 따른 수용 여부는 테스트 코드쪽에서 결론이 지어져야 될 것이라는 생각이 듭니다. (아마 의도에 벗어난 코드로 바뀌어져버렸다면 Test Code 에서 검증되겠죠.) 코드 자체만 보고 바로 잘못된 코드라고 단정짓기 보단 전체 프로그램 내에서 의도에 따르는 코드일지를 생각해야 될 것 같다는 생각.
        * 예제 코드로 적절했느냐 - 좀 더 쉽게 의도에 맞게 Refactoring 되어진 것이 이 예제 바로 전인 Raise 이긴 하지만. 그리 좋은 예는 아닌듯 하다. usageInRange 로 빼내기 위해 약간 일부러 일반화 공식을 만들었다고 해야 할까요. 그 덕에 코드 자체만으로 뜻을 이해하기가 좀 모호해졌다는 부분에는 동감.
        * ["Refactoring"]의 Motivation - Pattern 이건 Refactoring 이건 'Motivation' 부분이 있죠. 즉, 무엇을 의도하여 이러이러하게 코드를 작성했는가입니다. Parameterize Method 의 의도는 'couple of methods that do similar things but vary depending on a few values'에 대한 처리이죠. 즉, 비슷한 일을 하는 메소드들이긴 한데 일부 값들에 영향받는 코드들에 대해서는, 그 영향받게 하는 값들을 parameter 로 넣어주게끔 하고, 같은 일을 하는 부분에 대해선 묶음으로서 중복을 줄이고, 추후 중복이 될 부분들이 적어지도록 하자는 것이겠죠. -- 석천
       > { Refactoring(by Martin Fowler)의 잘못된 refactoring }
• ReplaceTempWithQuery
       ["Refactoring"]
• STL
        DeleteMe) 인수가 가진 모든 STL 페이지 ["Refactoring"] (예제가 그 자체로만으로 돌아가나 컴파일. 이모티콘과 잡담 모두 빼서, Document Mode로 만들기, 쉬운말, 쉬운 예제로 고치기) 결과 ["인수"]의 모든 STL 페이지 사라짐(피바람);;
• SeminarHowToProgramIt
        * ["Refactoring"] -- 후각 개발법
       ||["Refactoring"] ||3 ||
       하지만 동적 자료형 언어를 접하는 것 자체가 큰 장점일 수가 있습니다. 특히 TDD와 Refactoring은 동적 자료형 언어에서 빛을 발하고, 대다수의 DP는 언어 수준에서 지원이 되거나 아주 간단합니다. 20분 정도면 Python을 간략하게 훑을 수는 있습니다.
• SeminarHowToProgramItAfterwords
        * [창섭]:PairProgramming 자체가 인상적이었습니다. 음악을 아마추어로 하는 저로써는 음악외에도 이렇게 멋지게 콤비를 결성할 수 있다는 것에 놀라울 따름입니다. ^^;; 그리고 변수명을 고치는 것 자체가 Refactoring 에 들어가고 매우 중요하다는 사실도 감명이었습니다. ^^;
        * ["1002"] : 어제 Test Code : Product Code 간 중복 (return 0 !) 을 OAOO로 풀어서 Refactoring 을 해야 할 상황으로 규정짓는다는 말이 뒤통수를 한대 때리는 기분이였습니다;;
        * ["Refactoring"] 책에서는 ''Refactor As You Do Code Review'' 에 Code Review 를 위한 Refactoring을 이야기 하는데, Refactoring 을 위해서는 기본적으로 Test Code 가 필요하다고 할때 여기에 Test Code를 붙일테니까 상통하는 면이 있긴 하겠군요.
• SoftwareEngineeringClass
       하지만 역할별, 작업별로 만드는 계획서와 보고서에 쏟는 시간이 너무 많다는 생각은 저 뿐만이 아닐 것입니다. 심사시에는 계획서에서 언급하지 않은 활동을 실행했다고 딴지를 걸 정도로, 계획서대로 실행된 내용을 변경없이 실행하는 것이 프로젝트의 반복가능성을 평가하는 기준인것 같습니다. 설계와 구현 사이에서 계획대로 실행 안되는 부분을 극단적으로 느꼈는데, 예를 들어 클래스 다이어그램과 시퀀스 다이어그램이 [Refactoring]과 같은 코드 재구성 작업을 할 때마다 바뀌어야 했습니다. 다이어그램이 코드로 매칭되지 않기 때문에 코드를 바꿈은 물론 다이어그램을 바꾸는 이중의 수고를 겪어야 했습니다. :( --[Leonardong]
• StepwiseRefinement
       사실, TestDrivenDevelopment나 ["Refactoring"]의 상당 부분도 어찌보면 StepwiseRefinement의 연장선에 있다.
• TFP예제/WikiPageGather
        * '생각할 수 있는 가장 단순한 것부터 생각하라.' 디자인은 TFP 와 Refactoring의 과정만으로 어느정도 보장이 된다. TFP을 추구하는 이상 기능와 의도에 의한 모듈화가 기본적으로 이루어진다. (여태껏의 경험 -- 그래봤자 3번째지만 -- 에 의하면, TFP를 하면서 LongMethod 냄새가 난 적이 없었다. (LongMethod와 Bad Smell 에 대해서는 BadSmellsInCode를 참조하라.) 만일 중복코드 등의 문제가 발생하더라도 기존의 막무가내식 방식에 비해 그 빈도가 적다. 만일 Bad Smell 이 난다면 ["Refactoring"] 을 하면 된다. (참고로 밑의 소스는 ["Refactoring"]의 과정은 거치지 않았다.)
• TddRecursiveDescentParsing
       대강 다음과 같은 식으로 접근했고요. 테스트코드 2-3줄쓰고 파서 메인코드 작성하고 하는 식으로 접근했습니다. (["Refactoring"] 을 하다보면 FactoryMethodPattern 과 CompositePattern 이 적용될 수 있을 것 같은데, 아직은 일단.)
• TestDrivenDevelopmentByExample
       개인적으로 TDD 중 빠른 테스트 통과를 위해 가짜 상수로 쌓아나갈때 어떻게 '중복' 이라 하여 ["Refactoring"] 할까 고민했었는데, 이전의 SeminarHowToProgramIt 에서의 예제 이후 이 문서에서의 예제가 깔끔하게 풀어주네요. 인제 한번 들여다 본 중이긴 하지만, 저자가 저자인 만큼 (KentBeck).~
• TestFirstProgramming
       ExtremeProgramming에서는 UnitTest -> Coding -> ["Refactoring"] 이 맞물려 돌아간다. TestFirstProgramming 과 ["Refactoring"] 으로 단순한 디자인이 유도되어진다.
       요새는 ["TestDrivenDevelopment"] 라고 한다. 단순히 Test 를 먼저 작성하는게 아닌, Test 주도 개발인 것이다. TestDrivenDevelopment 는 제 2의 Refactoring 과도 같다고 생각. --["1002"]
       === Test Code Refactoring ===
       프로그램이 길어지다보면 Test Code 또한 같이 길어지게 된다. 어느정도 Test Code 가 길어질 경우에는 새 기능에 대한 테스트코드를 작성하려고 할 때마다 중복이 일어난다. 이 경우에는 Test Code 를 ["Refactoring"] 해야 하는데, 이 경우 자칫하면 테스트 코드의 의도를 흐트려뜨릴 수 있다. 테스트 코드 자체가 하나의 다큐먼트가 되므로, 해당 테스트코드의 의도는 분명하게 남도록 ["Refactoring"] 을 해야 한다.
        * wiki:Wiki:RefactoringTestCode
• TriDiagonal/1002
        * 느낀점 - LU 분해를 일반화시키는 부분에 대해서는 연습장에서 계산을 시키고 대입을 해보고 패턴을 찾아낸 뒤 일반화시켰다. 만일 이 부분을 코드를 짜면서 ["TestFirstProgramming"] * ["Refactoring"] 의 방법으로 풀었더라면 어떠했을까. (두 개의 과정이 비슷하다고 여겨진다. 코드가 줄어들고 OAOO 의 원칙을 지킬 수 있을테니까.) -- 석천
• VonNeumannAirport
        * 중간에 창준이형이 "너희는 C++ 로 프로그래밍을 하면서 STL를 안사용하네?" 라고 했을때, 그냥 막연하게 Java 에서의 Collection Class 정도로만 STL을 생각하고, 사용을 잘 안했다. 그러다가 중반부로 들어서면서 Vector를 이용하게 되었는데, 처음 한두번 이용한 Vector 가 후반으로 가면서 전체의 디자인을 뒤집었다; (물론 거기에는 디미터 법칙을 지키지 않은 소스도 한몫했지만 -_-;) 그걸 떠나서라도 Vector를 써 나가면서 백터 비교 assert 문 등도 만들어 놓고 하는 식으로 점차 이용하다보니 상당히 편리했다. 그러다가 ["Refactoring"] Time 때 서로 다른 자료형 (앞에서 array 로 썼던 것들) 에 대해 vector 로 통일을 하다 보니 시간이 비교적 꽤 지연이 되었다.
        * ["Refactoring"] Bad Smell 을 제대로 맡지 못함 - 간과하기 쉽지만 중요한 것중 하나로 naming이 있다. 주석을 다는 중간에 느낀점이 있다면, naming 에 대해서 소홀히 했다란 느낌이 들었다. 그리고 주석을 달아가면서 이미 구식이 되어버린 예전의 테스트들 (로직이 많이 바뀌면서 테스트들이 많이 깨져나갔다) 를 보면 디미터 법칙이라던가 일관된 자료형의 사용 (InformationHiding) 의 문제가 있었음을 느낀다.
• WikiProjectHistory
       || ["Refactoring"] || ["neocoin"], ["1002"] || 책요약 "Refactoring"의 요약 || 유보 ||
• XpQuestion
       - '필요하면 하라'. XP 가 기본적으로 프로젝트 팀을 위한 것이기에 혼자서 XP 의 Practice 들을 보면 적용하기 어려운 것들이 있다. 하지만, XP 의 Practice 의 일부의 것들에 대해서는 혼자서 행하여도 그 장점을 취할 수 있는 것들이 있다. (TestDrivenDevelopment, ["Refactoring"], ContinuousIntegration,SimpleDesign, SustainablePace, CrcCard Session 등. 그리고 혼자서 프로그래밍을 한다 하더라도 약간 큰 프로그래밍을 한다면 Planning 이 필요하다. 학생이다 하더라도 시간관리, 일거리 관리는 익혀야 할 덕목이다.) 장점을 취할 수 있는 것들은 장점을 취하고, 지금 하기에 리스크가 큰 것들은 나중에 해도 된다.
       각 Practice 를 공부를 하다보면, 저것들이 이루어지기 위해서 공부해야 할 것들이 더 있음을 알게 된다. (의식적으로 알아낼 수 있어야 한다고 생각한다.) Refactoring 을 잘하기 위해선 OOP 와 해당 언어들을 더 깊이있게 이해할 필요가 있으며 (언어에 대해 깊은 이해가 있으면 똑같은 일에 대해서도 코드를 더 명확하고 간결하게 작성할 수 있다.) CrcCard 를 하다보면 역시 OOP 와 ResponsibilityDrivenDesign 에 대해 공부하게 될 것이다. Planning 을 하다보면 시간관리책이나 일거리 관리책들을 보게 될 것이다. Pair 를 하다보면 다른 사람들에게 자신의 생각을 명확하게 표현하는 방법도 '공부'해야 할 것이다. 이는 결국 사람이 하는 일이기에. 같이 병행할 수 있고, 더 중요한 것을 개인적으로 순위를 정해서 공부할 수 있겠다.
• XpWeek/20041221
       아침에 TDD하면서 [Refactoring]이 만만치 않다는 생각을 했다. 생각보다 PlanningGame이 오래 걸려 지루한 느낌과 지친다는 느낌을 받았다. 고객의 입장일 때 내가 뭘 원하는지 명확하지 않았다. 그래도 내일은 왠지 잘 될 것만 같다.
       TDD 경험하면서 test class의 Refactoring을 어떻게 해야 될지 모르겠다. test 코드라 굳이 할 필요성을 못 느꼈고 테스트만 하면 된다는 생각이 들었기 때문이다. 인원이 적어서 고객과 개발자의 역할을 번갈아가면서 했는데 개발하기 쉬운 방향으로 생각을 이끌어나가는 것 같았다. 입장을 명확히 한 후 생각을 정리하고 표현해야겠다. 회의가 길어지면서 나타난 의욕상실이 아쉬웠다.
• XpWeek/ToDo
        테스팅 -> 코딩 -> [Refactoring]
• Yggdrasil/가속된씨플플
        * [Refactoring]은 중간중간에 계속 해주는 것이 도움이 되었습니다. 계속 다르게 진행하면 소스를 통합하기가 매우 힘들어 지죠. NoSmok:문서구조조정 마찬가지 같습니다. [위키요정]에서 말하는 정원일과 비슷하지 않을까요? 쓸말이 없다면, 지금 페이지들을 지우는 것도 좋은 방법입니다. 어차피 차후에 '내가 했다.'라는 것은 자신만이 알면 되지요. --NeoCoin
       지금 하는 작업들도 그렇게 될수 있겠지요. 마치 긴 프로그래밍 소스가 [Refactoring]을 통해서 짧아 지는것 처럼 말이지요.
• neocoin/Log
        * ["Refactoring"] : Reference 부분 1차 초안 완료
• 가독성
       전에 여러 회사의 팀들 분들과 이야기를 하면 사람들마다 얼마나 취향차들이 다른가에 대해서 느끼는데, 한편으로는 그냥 개인의 취향차로만 보기에는 그 분들의 작업 환경에 따라 차이가 있는 듯 합니다. 일례로, ["Refactoring"] 개념이 개발자들에게 퍼진 이후 메소드는 가능한 한 짧고 간결하며 한가지 기능만을 하는게 가독성과 모듈디자인상 좋다고 이야기합니다. 근데, 리눅스나 VI 에서 작업하시는 분들은 '너무 메소드 길이가 짧아도 안좋다.' 라던지 '리눅스의 xx 코드 본 적 있냐? 한페이지에 주욱 나오는게 정말 읽기가 좋다.' 'OO 디자인이 좋다고 하는데, 코드 분석하려면 이 화일 저 화일 돌아다니고 메소드들을 이리저리 돌아다녀야 하고 별로 안좋은거 같다' 라고 말씀하시는 분들도 있습니다.
• 데블스캠프2005/RUR-PLE/Harvest/Refactoring
       = [데블스캠프2005/RUR-PLE]/Harvest/[Refactoring] =
• 데블스캠프2005/주제
       [Refactoring], [TestDrivenDevelopment], [STL], [ObjectOrientedProgramming],
• 문서구조조정
       새로 페이지를 만들어주거나, 기존의 스레드 토론에서의 의견, 주장 등의 글들을 요약 & 정리 해줌으로서 해당 주제를 중심으로 페이지의 내용이 그 주제를 제대로 담도록 해준다. 이는 프로그램 기법에서 일종의 ["Refactoring"] 과 비슷한 원리이다.
• 반복문자열/임다찬
       [Refactoring]가운데는 임시 변수를 없애는 내용이 나옵니다. 임시 변수는 언제 있으면 좋을까요?
• 방울뱀스터디
        * [ExtremeProgramming]의 몇가지를 실천할 것입니다. [PairProgramming], [Refactoring]...
• 비행기게임
        암튼. 초반의 열정이 후반의 끈기로 이어지려면, 해당 일에 대한 좋은 방법들을 중간에 계속 궁리하고, 적용해봐야겠지. 개인적인 조언이라면, 초반에 너무 그래픽 등에 많이 신경쓰지 않는것이 낫다고 생각함. 일단은 전반적인 틀과 게임 엔진을 만든다는 기분으로 하고, 그 엔진이 자신이 원하는 아이디어를 수용할 수 있는가에 더 촛점을 맞추는게 낫지 않을까 함. 단, 생각은 전반적인 부분을 보되, 구현을 쉽게 하기 위해서는 구체적 예제 데이터를 가지고 작업하는것이 효율적이겠지. 그리고 그 예제 데이터를 기반으로 일종의 SpikeSolution식으로 구현을 한뒤, 그 구현된 프로그램을 보고 다시 코드를 작성하던지 또는 ["Refactoring"] 해서 일반화시키던지.(새로 짜도 얼마 시간 안걸림. 예상컨대, 아마 중반에 소스 한번 뒤집어주고 싶은 욕구가 날껄? 흐흐) --["1002"]
• 상협/감상
       || [Refactoring] || 마틴파울러 || 1 || 굿 || 괜찮은 책이다. 아직 내가 이해와 적용을 제대로 못해서 아쉽다 ||
• 위키설명회
        * Rename, [문서구조조정]을 통해서 [Refactoring]을 경험하고, 이것이 프로그래밍의 영역에서 어떠한 관점을 가지고 있는지 이야기 해 본다.
• 일취집중후각법
       ["Refactoring"]의 도를 얻기 위한 수련법의 하나. see also HowToStudyRefactoring
• 제로페이지의문제점
       세미나가 [데블스캠프]외에 신입생 위주로 하는게 있어요? 설마 스터디를 이야기 하는거라면, 자신이 만들어 나가는건데요. :) 여태 제가 신입생 대상 스터디를 해본적이 없어서 공감이 안가는 이야기 같네요. 스스로 만드세요. SeeAlso 개인 제외 같이 한것들 --ExploringWorld ProjectZephyrus ProjectPrometheus [MFCStudy_2001] [KDPProject] [Refactoring] --NeoCoin
• 타도코코아CppStudy/0724
        * [Refactoring]
        * OWIKI:Refactoring
• 프로그램내에서의주석
        아..["Refactoring"] 하라는 거군요.. 사실 설계 자체에서도 빠진 상태라 전체 구조 이해하는데 가장 크게 애를 먹었습니다. 아무튼 진짜 이해한 후에 코드를 수정해 놓는 것도 좋은 방법인건 분명하다고 생각합니다. ^^; --창섭
        하지만, "확실히 설명할때 {{{~cpp JavaDoc}}}뽑아서 그거가지고 설명하는게 편하긴 편하더라."라고 한말 풀어쓰는 건데, 만약 디자인 이해 후에 코드의 이해라면 {{{~cpp JavaDoc}}} 없고 소스만으로 이해는 너무 어렵다.(최소한 나에게는 그랬다.) 일단 코드 분석시 {{{~cpp JavaDoc}}}이 나올 정도라면, "긴장 완화"의 효과로 먹고 들어 간다. 그리고 우리가 코드를 읽는 시점은 jdk를 쓸때 {{{~cpp JavaDoc}}}을 보지 소스를 보지는 않는 것처럼, 해당 메소드가 library처럼 느껴지지 않을까? 그것이 메소드의 이름이나 필드의 이름만으로 완벽한 표현은 불가능하다고 생각한다. 완벽히 표현했다면 너무나 심한 세분화가 아닐까? 전에 정말 난해한 소스를 분석한 적이 있다. 그때도 가끔 보이는 실낱같은 주석들이 너무나 도움이 된것이 기억난다. 우리가 제출한 Report를 대학원 생들이 분석할때 역시 마찬가지 일것이다. 이건 궁극의 Refactoring문제가 아니다. 프로그래밍 언어가 그 셰익스피어 언어와 같았으면 하기도 하는 생각을 해본다. 생각의 언어를 프로그래밍 언어 대입할수만 있다면야.. --["상민"]
• 후각발달특별세미나
       Upload:0503_RefactoringSeminar.hwp - 발표 자료.
       Upload:0503_RefactoringSeminarSrc.zip - 예제 파일들.
       [Refactoring]
       [Refactoring/BadSmellsInCode]

Found 64 matching pages out of 7540 total pages

You can also click here to search title.