![]() Note that "broke" may include code that is unmaintainable, but working correctly, that depends on the system and its use. ![]() When it is broke, you need to be very careful when you fix it - as you make it better, that you don't accidentally change something else. You need to work with the mind set " if it ain't broke, don't fix it". It's 1000 lines because the original 100-line routine did not do the job. Hidden in those 1000 lines is 100 bug fixes, each one an undocumented user requirement or an obscure edge case. It would only (yet another four letter word) take a couple of days to re-factor it into a few 100 line routines and a few more 20 lines helpers, right? WRONG. For instance, that routine that's 1000 lines (I have a few that are over 5000), it is overly complex and is a piece of spaghetti. So the answer to your question is there is much much more. Have you got 40 man years, well, have you.? Let's now pick a number - you have new computers and new tools, and you are so much more clever than the guys who wrote this piece of $%^^ in the first place - let's say you are worth 10 of them. How much time is invested in that million-line, 20-year-old legacy system? Let's say, 20 developers for 20 years times 2000 hours / annum (they worked pretty hard). How long do you think it takes to write a unit test, to test one hour worth of development effort? For discussion sake, let's say another hour. The key word here is just - it's a four-letter word that does not belong in any programmer's vocabulary, let alone one who is working on legacy systems. It's just software, so it's just a matter of writing a few unit tests, so you can go and just refactor it, and make it so much better. I work on a code base of millions of lines of code, some dating back to the 1980's. In other words, to avoid making "obvious" refactorings which have a risk of breaking the code without you noticing - because you don't yet have the unit tests to detect that. This knowledge allows you to notice the seeds of testability in the nastiest heap of code, and find the minimal, least disruptive, safest changes to get there. because the call makes changes in another object or subsystem, whose state is not possible to query directly from within the test method). Building seams into your code enables separating the piece of code under test, but it also enables you to sense the behaviour of the code under test even when it is difficult or impossible to do directly (e.g. A seam is a place in the code where you can change the behaviour of your program without modifying the code itself. To me, the most important concept brought in by Feathers is seams. Other times, we might even need to replace a dependency class/jar with a fake one in the test environment. So sometimes we have to resort to subclassing the class under test in order to override some method which would normally e.g. Introducing interfaces, mocks and Dependency Injection is clean and nice as a goal, just not necessarily safe to do at this point. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |