- Copertina flessibile: 434 pagine
- Editore: Prentice Hall; 01 edizione (30 novembre 2004)
- Collana: Robert C Martin
- Lingua: Inglese
- ISBN-10: 0131177052
- ISBN-13: 978-0131177055
- Peso di spedizione: 699 g
- Media recensioni: 4.0 su 5 stelle Visualizza tutte le recensioni (2 recensioni clienti)
- Posizione nella classifica Bestseller di Amazon: n. 14.417 in Libri in altre lingue (Visualizza i Top 100 nella categoria Libri in altre lingue)
- Visualizza indice completo
Working Effectively With Legacy Code (Inglese) Copertina flessibile – 30 nov 2004
|Nuovo a partire da||Usato da|
- Scegli tra gli oltre 8.500 punti di ritiro in Italia
- I clienti Prime beneficiano di consegne illimitate presso i punti di ritiro senza costi aggiuntivi
- Trova il tuo punto di ritiro preferito ed aggiungilo alla tua rubrica degli indirizzi
- Indica il punto di ritiro in cui vuoi ricevere il tuo ordine nella pagina di conferma d’ordine
Spesso comprati insieme
Chi ha acquistato questo articolo ha acquistato anche
Dalla quarta di copertina
Get more out of your legacy systems: more performance, functionality, reliability, and manageability
Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.
In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy 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 any language or 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
- Handling applications that don't seem to have any structure
This book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.
© Copyright Pearson Education. All rights reserved.
MICHAEL C. FEATHERS works for Object Mentor, Inc., 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 Development (TDD), Refactoring, OO Design, Java, C#, C++, and Extreme Programming (XP). Michael is the original author of CppUnit, a C++ port of the JUnit testing framework, and FitCpp, a C++ port of the FIT integrated-testing framework. A member of ACM and IEEE, he has chaired CodeFest at three OOPSLA conferences.
© Copyright Pearson Education. All rights reserved.
Non è necessario possedere un dispositivo Kindle. Scarica una delle app Kindle gratuite per iniziare a leggere i libri Kindle sul tuo smartphone, tablet e computer.
Per scaricare una app gratuita, inserisci il numero di cellulare.
Garanzia e recesso: Se vuoi restituire un prodotto entro 30 giorni dal ricevimento perché hai cambiato idea, consulta la nostra pagina d'aiuto sul Diritto di Recesso. Se hai ricevuto un prodotto difettoso o danneggiato consulta la nostra pagina d'aiuto sulla Garanzia Legale. Per informazioni specifiche sugli acquisti effettuati su Marketplace consulta… Maggiori informazioni la nostra pagina d'aiuto su Resi e rimborsi per articoli Marketplace.
Se sei un venditore per questo prodotto, desideri suggerire aggiornamenti tramite il supporto venditore?
Quali altri articoli acquistano i clienti, dopo aver visualizzato questo articolo?
Principali recensioni dei clienti
Il fatto e' che se sviluppate da 15-20 anni e ve ne siete posti di domande su come modificare il codice esistente (e usate TDD), e' probabile che diventi un po' noioso perche' e' probabile conosciate gia' tutti i pattern indicati.
Le recensioni clienti più utili su Amazon.com (beta) (Potrebbero essere presenti recensioni del programma "Early Reviewer Rewards")
Feathers covers the topics of why, and how to deal with code that is difficult to change with a variety of useful patterns. Most useful of these is the legacy code change algorithm:
1. identify the change points
2. find test points
3. break dependencies
4. write tests
5. make changes and refactor
This book will make you a better developer.
Now, the only downside of this book is that the examples covering several different languages can sometimes obscure the teaching of the narrative. Perhaps in a future edition it would be nice to see a single language (or a couple) and have extra resources available in the electronic versions or websites to cover other languages. To me, this did not represent something worth dropping this from a 5 star review. I gave my physical copy away long ago and repurchased a second copy on the kindle.
Michael Feathers does a great job of modelling his mindset, choices, and techniques through short example case studies. Nothing is presented as dogma, and many cases are followed to see the effects of different techniques to solve the same problem.
Many of the techniques to get code into a testable form are just best practice or are similar to a Design Pattern, but a key strength of this book is making getting from here to there within reach. Clients and superiors want code that works, and the testing and incremental approach that Michael advocates provides the net for safely and confidently making the transition to less tightly-coupled, more modular, understandable, and verified code from the time-tested battle-worn code many of us call home.
Even better, Michael's approach destroys the "design vs just maintenance" dichotomy, as it satisfies that little voice to start making improvements we've been putting off when we get our code in testable form.
I hope my department picks this up, and that we all start leaving the code a little better than we found it.
The only flaw in this book is: It doesn't go far enough. I've now been working for 1+yr with a 20+yr old C++ code base (that's still responsible for over $1B revenue a year, runs on over 1500 servers, handles well over 100000 requests/min in total). I read this book in the first couple of weeks and thought "yeah, ok, but things can't possibly be that bad".
Well, now I know better. They're worse.
This book can help you _a lot_ with the technical aspects of working with legacy code - but some things (esp. long-standing company processes) just can't be fixed by mortal man. So you need a good attitude (including a good sense of humor) as well. Working with good colleagues also helps. But definitely read this book and use its lessons in practice.
Some of Michael's techniques are old friends that I never thought to use in this way. Others were things I didn't realize I knew at all, and others were totally new to me. What they all had in common was that they offer a wealth of approaches to incrementally improve a tough situation, both to accomplish the immediate task and to prepare for further improvements later. This pay-as-you go alternative is both more effective and less risky than either of the extremes of doing nothing or large-scale replacement.
Another strength of the book is that Mr. Feathers provides examples in several languages, mostly Java and C++, but also Ruby and some others. This variety is very helpful for deepening our understanding of both the problems and the solutions.
Is your code a tangled mess? Are you tired of seeing telescoping methods and methods that are 100s of lines long? Want to clean up code you didn't write and get it under test but everyone's too afraid of breaking things? Does it take you forever to write unit tests? Is it painstaking and laborious? Do you write mainly integration tests because unit testing is too hard? Do you wonder how people can write lots of unit tests, let alone unit test every method? Do you want to kick your object oriented coding skills up a notch? Then this book is for you. It can teach you how to overcome all of those obstacles and so much more.
For me the first roughly 100 pages of the book were a revelation. If you don't understand how to do TDD the problem probably isn't testing, it's probably the code you're trying to test or your perceptions about what it is that you are actually supposed to be testing. Michael Feathers does a great job identifying the mistakes and traps that so many developers experience when trying write and test good code and provides recipes for overcoming them. He adds clarity to what a unit test is and what it's supposed to do and in the process takes a deep dive into what good object oriented code looks like through the eyes of TDD. The book can completely change your perception about what is and is not possible.
In addition to turning your perceptions about testing on their head, Feathers also provides good advice on how to create loosely coupled code, how to identify and eliminate dependencies in existing code as well as strategies for reorganizing poorly structured code into better objects. This book has clearly changed the way I code and the way I think about testing for the better. It's not just about testing it's also about turning procedural code into object oriented code and bringing your object oriented thinking to the next level.
I can't say enough great things about this book. It's dearer to me than any other book in my programming collection including books about object oriented code from Bloch, Beck, Fowler and others. It wasn't until I read Working Effectively with Legacy Code that things really came together for me in the object oriented world. I got the concepts individually but failed to recognize how it all comes together. What's so great about encapsulation / getters and setter? Why is it so important to have classes and methods that do just one thing? What's so important about breaking dependencies between classes? How small is a small method? How can I ever hope to achieve open/closed? How is TDD even possible? Your mileage may vary, but if you're like me this book will change your life for the better.