検索 - みる会図書館

検索対象: Working Effectively with Legacy Code

Working Effectively with Legacy Codeから 6件ヒットしました。

Working Effectively with Legacy Code


Working Effectively with Legacy C0de Michael C. Feathers PRENTICE HALL PTR Prentice Hall Professional Technical Reference Upper Saddle River, NJ 07458 www.phptr.com

Working Effectively with Legacy Code


104 Summary How Do I ADD A FEATURE? ls it worth dOing this all Of the time ~ A few concrete overrides every once ln a while don't hurt, as long as it doesn't cause a た な た 0 レ s 〃 わ 立 ″ 〃 〃 0 〃 々 行 〃 じ ゅ violation. However, it's good tO think about hOW far classes are from normal- ized form every once 111 a WhiIe and at tlmes tO 1 れ tO 、 it When Ⅵ ℃ pre- pare tO separate out responsibilities. progl ・ 4 川 川 / 〃 g わ ア Difference lets us introduce variatlons quickly in systems. when we d(), 、 can use our tests tO pin down the new behavior and move tO 1 れ ore appropriate structures when we need tO. Tests can make the move very rapid. Summary You can use the techniques in this chapter tO add features tO any code that you can get under test. The literature on ー es ト d ″ e 〃 de ″ e / 0 々 川 夜 な has grown in recent years. ln particular, I recommend Kent Beck's bOOk ビ 5 ト Dr ル e 〃 D 司 0 々 川 夜 な わ ) ′ E ェ 4 川 々 (Addison-Wesley, 2002 ) , and Dave Astel's 5 な D 怩 〃 D ℃ / 0 々 川 ビ 〃 た A p じ 〃 朝 / Guide (Prentice Hall Professional Technical Reference, 2003 ).

Working Effectively with Legacy Code


Robert C. Martin Series The misslon of this serles is tO improve the state of the art of software craftsmanship. The b00kS in this serles are technical, pragmatic, and substantial. The authors are highly experienced craftsmen and professionals dedicated t0 writing about what actually works in practice, as opposed to what might work in theory. You will read about what the author has done, not what he thinks you should do. If the book is about programming, there will be lots of code. If the b00k is about managing, there will be lots of case studies from real projects. These are the bOOks that all serious practitioners will have on their bookshelves. These are the books that will be remembered for making a difference and for guiding professionals tO become true craftsman. Ma 〃 ag g Agile Projects SanJiv Augustine Agile Es 〃 川 酣 g 4 〃 d 4 〃 〃 g Mike Cohn Ⅳ 0 黻 g E が “ 怩 ル / 舫 も egacy Co Michael C. Feathers Agile JavaTM: C 〃 g CO ル ″ わ s な D 怩 〃 D ビ 怩 / 0 々 襯 e 厩 Jeff Langr AgiIe P れ c ゆ / ぉ , Patterns, 4 れ d ~ け た お C# Robert C. Martin and Micah Martin Agile SO 〃 曜 4 D ビ 怩 / 0 々 襯 ビ 〃 た P 行 〃 じ ゅ / ぉ , Pa な ビ 川 s , 4 〃 d ~ け た お Robert C. Martin UML お or JavaTM Prog 川 川 5 Robert C. Martin お De 怩 / 0 々 g So 〃 ル 4 尾 : お 川 e 曜 0 黻 ル ル g d s な Rick Mugridge and Ward Cunningham Agile So ″ ル 4 D ビ 怩 / 0 々 襯 ビ 厩 ル / 舫 SCR UM Ken Schwaber and Mike Beedle E ズ な e So ″ ル 4 尾 E 〃 g / 〃 〃 g : A Ha 〃 0 〃 A 々 々 roa 訪 DanieI H. Steinberg and Daniel Ⅳ Palmer For more informatlon, visit http://www.prenhallpofessional.com/martinserres

Working Effectively with Legacy Code


Software Engineering Get mo out Of yourlegacy systems: more performance, functionality, reliability, and manageability 区 your code easy tO change? Can you get nearly instantaneous feedback when you do change it? DO you understand it? げ the answer tO any Of these questions is no, you have legacy code, and it is draining time and money away from your development e 幵 0 . 旧 this bOOk, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material MichaeIcreated fo 「 his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds Of developers, technical managers, and testers bring theirlegacy systems under control. The topics covered include Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance Getting legacy code intO a test harness Writing tests that protect you against introducing new problems Techniques that can be used with anylanguage 0 「 platform—with examples in Java, C + + , C, and C# Accurately identifying where code changes need to be made Coping with legacy systems that aren't object-oriented HandIing applications that don't seem tO have any structure This book a 区 0 includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes. MICHAEL (. FEATHERS works fo 「 Object Mentor, 旧 (. , one of the world's top providers of mentoring, skill development, knowledge transfer, and leadership services in software development. He currently provides worldwide training and mentoring in Test-Driven DeveIopment (TDD) ′ Refactoring, 00 Design,Java, C#, C + + , and Extreme Programming (XP). Michael is the originalauthor 0f CppUnit, a C + + po は Of the JUnit testing framework, and FitCpp, a C + + po 0f the FIT integrated-testing framework. A member of ACM and IEEE ′ he has chaired CodeFest at three OOPSLA conferences. CoverImage: CharIes Babbage/ Time & Life Pictures / Getty lmages, lnc. www.prenhallprofessional.com ・ ・ P R E NTI ロ E H A L L ・ ・ P EA R S ロ N E D 凵 ロ AT ー ロ N 旧 BN -13 : 978-0-13-117705-5 旧 BN -10 : 0-13-117705-2 9 7 8 0 1 3 1 1 7 7 0 5 5 $ 54.99 US $ 68.99 CANADA 5 5 4 9 9

Working Effectively with Legacy Code


INTRODUCE INSTANCE DELEGATOR lntroduce lnstance Delegator People use stat1C methods on classes for many reasons. One 0f the most common reasons is tO implement the S g / 0 〃 Design Pa な れ ( 372 ). Another common reason tO use Stat1C methods iS tO create utility classes. Utility classes are pretty easy to find in many designs. They are classes that don't have any instance variables or instance methods. lnstead, they consist of a set Of static methods and constants. People create utility classes for many reasons. 、 lost of the time, they are cre- ated when it is hard tO find a common abstraction for a set of methods. The Math class in the Java JDK is an example of this. lt has static methods for trigo- nometric functions (COS, sin, tan) and many Others. When languages designers build their languages from objects 、 、 a Ⅱ the way down, ' ' they make sure that numerlc primitives know hOW dO these things. For instance, you should be able to call the method si n ( ) on the object 1 or any other numeric object and get the right result. At the time Of this writing, Java does not support math methods on primitlve types, SO the utility class iS a fair solution, but it iS alSO a special case. ln nearly all cases, you can use plain 01d classes with instance data and methods tO dO your work. If you have static methods in your project, chances are good that you won't run 1ntO any trouble with them unless they contain something that iS difficult tO depend on in a test. (The technical term for this is 5 地 〃 c c 〃 れ g ). ln these cases, you might wish that you could use an 0 を ビ c ー 5 4 ( 4 の tO substitute in some Other behavior when the static methods are called. What dO you do in this case? One thing that can dO iS start tO introduce delegating instance methods on the class. ・ When you do this, you have to find a way to replace the static calls with method calls on an object. Here is an example: public class BankingServices publ i ( stati c voi d updateAccountBaIance(i nt userID , Money amount) { Here we ve got a class that contains nothing but static methods. l've shown only one here, but you get the idea.We can add an instance method to the class like this and have it delegate to the static method: public class BankingServices 369 lntroduce lnstance DeIegator

Working Effectively with Legacy Code


FOREWORD Foreword .. then it began.. ln his introduction tO this bOOk, Michael Feathers uses that phrase to describe the start Of his passion for software. .. then it began.. DO you know that feeling? Can you point to a single moment in your life and .. then it began... " ?Was there a single event that changed the course Of say: your life and eventually led you t0 pick up this b00k and start reading this fore- 、 vord? I was ln sixth grade when it happened tO me. I was interested in SC1ence and space and all things technical. My mother found a plastic computer in a catalog and ordered it for me. lt was called Digi-Comp れ Forty years later that little plastic computer holds a place 0f honor on my bookshelf. lt was the catalyst that sparked my enduring passion for software. lt gave me my first inkling of how joyful it is t0 write programs that solve problems for people. lt was Just three plastic S-R flip-flops and six plastic and-gates, but it was enough— ・ it served. Then... for me... it began.. But the joy I felt soon became tempered by the realization that software sys- tems almost always degrade intO a mess. What starts as a clean crystalline design in the minds Of the programmers rots, over time, like a piece Of bad meat. The nice little system we built last year turns intO a horrible morass Of tangled functlons and variables next year. Why does this happen? 嶬 市 y do systems rot? 市 y can't they stay clean? Somet1mes Ⅵ ℃ blame our customers. Sometimes we accuse them Of changing the requirements. We comfort ourselves with the belief that if the customers had just been happy with what they said they needed, the design would have been fine. lt's the customer's fault for changing the requirements on us. 嶬 Ⅱ , here's a news flash: R 9 〃 ビ 川 e 〃 な c わ 4 〃 g 巳 Designs that cannot tolerate changing requirements are poor designs t0 begin with. lt is the goal 0f every competent software developer tO create designs that tolerate change. This seems to be an intractably hard problem to solve. SO hard, in fact, that nearly every system ever produced suffers from SIOW, debilitating rot. The rot is SO pervasive that C01 れ e up with a special name for rotten programs. We call them: Legacy Code. XIII