|
The best way to approach any refactoring excercise really should be to make sure that you have unit tests in place (with as much code coverage as possible) and that those unit tests should all pass. This allows you to refactor and objectively verify that the refactoring hasn't broken anything. That being said, this isn't always possible depending on the situation, but as long as you are careful and targeted in the refactoring you can minimize the potential risks.
As for changing the architecture because you find better ways to do something, you have to make a decision if the risks of changing the architecture at that point in time outweigh the benefits.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Scott Dorman wrote: The best way to approach any refactoring excercise really should be to make sure that you have unit tests in place
I agree you should have unit tests, but not for the purpose of refactoring. Sure they are invaluable to the effort but unit tests should be in place for many reasons having nothing to do with refactoring and the reasons come into play long before you have anything to refactor.
led mike
|
|
|
|
|
led mike wrote: you should have unit tests, but not for the purpose of refactoring
Absolutely. Ideally, unit tests should be in place long before any thoughts of refactoring like this occur. Since that isn't always the case, the next best thing is to recommend that they be in place before the refactoring.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
Yes. It's hard to imagine someone is thinking about design and architecture and refactoring but they haven't yet thought about the fact they should have unit tests. As hard as it might be to imagine that someone, no doubt they exist. 
led mike
|
|
|
|
|
It's not so strange. There are many cases where constructing unit tests would in itself represent a huge development effort, and I for one disagree that it is a necessarily a good idea to do so when about to embark on a refactoring.
The project I work on is a point in case. It is a web application and it isn't easy to unit test, among other reasons because intrinsic asp.net objects (request, response, session state, application state, httpserverutility) are used indiscriminately anywhere, so to make a unit test for some business class you need to make mocks of these, which you can't, because they are all sealed classes. Even if you could it would be quite a bit of extra work. And if your refactoring involves removing all these objects from your business logic you don't get any long-term benefit from doing all that work - once your tests are developed your refactoring then breaks them!
And that leads me to the more general observation: Refactoring isn't (usually) just about changing implementation details; it usually involves interface changes, decoupling of objects, and construction logic changes - perhaps introducing a factory somewhere. Most of these changes are of a nature that make them very likely to break any tests. So why do all the development effort to make a bunch of tests that you will immediately go about invalidating? In my view, far better to refactor and make tests for your *new* code as you go. In the end, if you had bugs that are still there after the refactoring there is no reason to think the refactoring itself would make them harder to fix afterwards, and if your refactoring introduced bugs that is no different to if you had made the unit tests for the "before refactoring" version of the application.
So I don't get it. What would be the great benefit of developing tests to know that some code you're about to change works, when those tests cannot be reused to test the code after the changes?
|
|
|
|
|
dojohansen wrote: There are many cases where constructing unit tests would in itself represent a huge development effort
Therefore your conclusion is to not do it?   That's going to make reading the rest of your post difficult, but I will try.
dojohansen wrote: because intrinsic asp.net objects (request, response, session state, application state, httpserverutility) are used indiscriminately anywhere
Bad, bad design, period.
dojohansen wrote: so to make a unit test for some business class you need to make mocks of these
No you don't, well you do apparently but I don't because I don't tightly couple business objects to ASP.NET intrinsics that are Presentation Layer objects. See Separation of Concerns[^], Isolation and Object Oriented Design Principles and Best Practices.
dojohansen wrote: So I don't get it.
Clearly.
dojohansen wrote: What would be the great benefit of developing tests to know that some code you're about to change works, when those tests cannot be reused to test the code after the changes?
Once again it's about how you Design your Unit Tests, it's about the cases, the cases should be able to be reused on the new Unit Test code you write for the new refactoring of things. This way you have the same test coverage of the new code as you did on the old code.
Final note: Avoiding work is NOT a valid excuse for not testing. If it were, software in general would be a lot worse quality than it already is. 
led mike
|
|
|
|
|
I wrote a sincere and I would say well considered opinion about a subject relevant to some people, and certainly to the original question posted. Your reply can be summed up as you trying to tell me "you're an idiot". I am sure the person who asked the question is able to judge the reasons given for and against any recommendation and I suggest you stick to explaining why he should develop unit tests before refactoring and let readers draw their own conclusions.
Your venomous, arrogant reply was quite provocative. If it were not for the fact that your arrogance is - incredibly - superseded by your stupidity, I'd take it as a bitter pill and just try to learn from it. As it is, I'll take issue with your "argument".
We are not discussing the quality of the application code in the project I work on. It should be blindingly obvious to all of us why using, say, session state in a business object is just plain wrong. I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject, so I can only say I am unused to "debating" at this level and not quite certain how I can best help you see the light. I will try though, adding some emphasis especially for you:
It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE. If developing the tests represents a SIGNIFICANT WORKLOAD that would be UNDONE by the subsequent refactoring, it is my opinion that it is A WASTE OF TIME to do it IN THIS ORDER.
Furthermore, I claim that in the real world, MOST (this is not quite the same as all) refactoring would be of such a nature as to be very likely to break any unit tests developed. Hence, if about to refactor a project for which no unit tests exist, it MAY be a GOOD IDEA to CONSIDER whether one should refactor FIRST and THEN develop the unit tests.
If you don't have anything more intelligent to say than "avoiding work is NOT a valid excuse" when I haven't even remotely suggested anything of the kind then PLEASE, just spare us. You are neither funny or enlightning. Working hard is not sufficient in software development, you have to use your brain too. So do it.
|
|
|
|
|
dojohansen wrote: I was debating whether or not *generally* speaking it is smart to develop unit tests BEFORE or AFTER a refactoring of code. Unfortunately not one word you input related to this subject
Perhaps it's because you replied to my post that said:
led mike wrote: Yes. It's hard to imagine someone is thinking about design and architecture and refactoring but they haven't yet thought about the fact they should have unit tests. As hard as it might be to imagine that someone, no doubt they exist.
What I was discussing in that post as well as my last one to you was the importance of Unit Tests during INITIAL DEVELOPMENT. The original post used terms like "old architecture" which I took to mean in production.
dojohansen wrote: It is my OPINION that it is not ALWAYS or AUTOMATICALLY best to develop unit tests PRIOR TO REFACTORING CODE
It's my opinion that it's insane to be in production without unit tests. And no this is not some new belief based on TDD, I learned to use Unit Tests long before I ever heard the term Test Driven Development and long before any frameworks existed, AFAIK. Therefore I was never discussing the merits of developing unit tests based on a need to refactor in post production since the Unit Tests would already exist prior to production. My comments were only to the point of developing unit tests as a standard practice of software development, period.
So you can get as upset as you want with what I said, it doesn't change any of that.
led mike
|
|
|
|
|
Somebody's been really hammering you with 1 votes on this board Mike. I've corrected the balance on some of them, and will continue to do so as time allows.
|
|
|
|
|
Pete O'Hanlon wrote: Somebody'
 Yeah, probably the same guy that was giving you the 2's. He explained that was an accident though. Apparently he didn't like my response to his argumentative reply in this thread about the importance of Unit Tests. Like I give a crap what he thinks.
led mike
|
|
|
|
|
Ahhh. Yup - I was reading this thread through with interest, especially because it highlights the differences in opinion in whether or not UT is important. It's a shame that people miss the point that good up front UT is a great way to force yourself to think more about the architecture of the system, and to look at putting good practices into place.
|
|
|
|
|
Pete O'Hanlon wrote: It's a shame that people miss the point
Sure, it's one in long list of points people miss in this field regarding good practices. witnessed here every single day. "here" having multiple usages:
1) Code Project
2) My peers and *gulp* managers or where I work
3) Me myself and I
Well maybe I don't miss them as much as I don't know them. I remember when I started out in University we worked with Unix and DOS. This was pre Windows and PCs were starting to move out so DOS became the hot bed. My internship, which became a job (long story or not), was DOS POS, yes Point of Sale and Piece of Shite. Anyway back then my vision of the future was I would be one of these guys that new almost everything about PC development. Then came (for me) OO, Windows and the Internet, etc., and I soon realized I would ever only scratch the surface or not, depends on your point of view. Most days it feels like not.
Anyway people that don't have a clue and don't even try, those that ignore people like Cunningham, Fowler, Beck, Booch and well there are just so many, as though they think they know better than they do I find annoying, at best, at worst they seem disgraceful. For my part I just hope I can even understand their points, the idea that I could judge them is not something I would even consider.
led mike
|
|
|
|
|
led mike wrote: I soon realized I would ever only scratch the surface
Yup - the more I learn, the more it becomes apparent that there's more to learn. For me, the forums are a great place to learn from people I respect. Even if I don't often ask questions on the forums, it's amazing how much I've picked up from the better answers.
|
|
|
|
|
Pete O'Hanlon wrote: Even if I don't often ask questions on the forums, it's amazing how much I've picked up from the better answers.
Exactly, that's the reason I am in them really. Replying is only a secondary consideration.
led mike
|
|
|
|
|
Well it wasn't YOUR thread. Just because you go off on a tangent doesn't mean everyone has to. I tried to write a post relevant to the thread, which was about existing code and refactoring. While it may be "insane" to get into production without unit tests, nevermind that 99.9% of all systems ever developed in the history of the universe has done exactly this, this is irrelevant.
You don't get any points for deliberately misunderstanding.
|
|
|
|
|
dojohansen wrote: Well it wasn't YOUR thread. Just because you go off on a tangent doesn't mean everyone has to.
YOu replied to me you f***ing moron. If you didn't want to talk to me or my point then you could have replied to someone else. What f***ing idiot.
dojohansen wrote: You don't get any points for deliberately misunderstanding.
I have not deliberately misunderstood anything. Sure there is a lot of legacy code that has no unit tests, should you create them? There is no cook book answer to that. Each project is different and therefore must be considered based on it's own unique criteria, period.
That said, what's legacy code? In this context, what it means to me is anything I was not an original developer of because I had no control over the creation of unit tests or the design of it, therefore to me it's legacy. If I am developing new code, which includes new modules, classes, libraries whatever for use in legacy systems, I will develop unit tests, period, that's what I have done for the 18 years I have been working in this field and I am not about to stop now just because you come along thinking you know something substantial. You don't, anymore than I do. I didn't develop or discover the concept of unit tests, I was taught to use them by people far more skilled in this field then you or I will ever be.
led mike
|
|
|
|
|
led mike wrote: YOu replied to me you f***ing moron.
We're seeing more and more of your true colors I guess.
But you see, I was NOT replying just to you. I was replying to anyone involved in or just reading the thread, but since my starting point was a desire to take issue with dogmatic recommandations, not to mention your arrogant "how can there POSSIBLY be ANYONE out there who don't do things your way" attitude I chose to reply to your post.
led mike wrote: ... and I am not about to stop now just because you come along thinking you know something substantial. You don't, anymore than I do.
I'll let those who read decide for themselves. In any case that isn't the issue. And you continue to debate AS IF I have uttered anything even remotely suggesting that one should not use unit tests.
I assumed you were DELIBERATELY misunderstanding but I am beginning to doubt if you can control it. Have a nice weekend.
|
|
|
|
|
dojohansen wrote: AS IF I have uttered anything even remotely suggesting that one should not use unit tests.
I assumed you were DELIBERATELY misunderstanding but I am beginning to doubt if you can control it.
No, but I did lose the thread as it has been a long one so, yes, I was wrong, you are correct, you never suggested that, my mistake. We were basically talking about two different things in regards to unit tests and it seems we might actually have similar views on both of them. Therefore it is at least partly my fault, if not completely, that we ended up in a confrontation rather than a discussion.
dojohansen wrote: Have a nice weekend.
thanks, same to you.
led mike
|
|
|
|
|
Where can I find some online guidance regarding the creating the ultimate user experience, with regards to exception handling? Jeff Atwood's catch-all solution[^] is very attractive, but I'd like to read up on the finer points, in a design aspect, of handling those unpleasant little situations where the user gets told something bad.
|
|
|
|
|
My [self-serving] opinion is: just tell the users that a problem occurred but that tech support (or whoever) has already been notified. Then when you get the notification, call the user.
there is no point in telling the user that "someclass encountered a null blah blah exception in method whatever(arg,arg,arg,arg) at line 42075 of module someclass.cs": in general they have no context to understand what it means, they cannot do anything about it, and frankly it scares quite a few of them.
telling them instead "oops, my bad" and then following up in a timely fashion [i.e. before they forget what they were doing] is far better - it makes you look like you're on top of things, and it gives the user a warm fuzzy about the application and your commitment to supporting it
again, this is just my [self-serving] opinion. 
|
|
|
|
|
I'm looking for good books or online sources that describe techniques for using object composition. Specifically, I'm interested in the idea that you can have objects within objects, several layers deep and how this can be a beneficial approach to managing application complexity.
I'm already familiar with most of the books out there on OOP, e.g. Design Patterns, Refactoring, etc., so if you can recommend something that deals with this subject that's off the well-beaten path, I'd appreciate it.
|
|
|
|
|
I am not aware of any books. I don't know if this subject is on c2.com but there are certainly some that might qualify as off the well-beaten path.
led mike
|
|
|
|
|
I'm designing a group of tables where each table offers both natural keys, e.g. invoice number, or surrogate keys, e.g. InvoiceId or InvoiceGuid. The PK for each table is a domain independent integer identity column, and each table has an optional natural key field. <pre>
[Example Table] recordId int identity,
exampleId nvarchar(20)
</pre>
Where the 'example' prefix is specific to the Example table, and an invoice table will have an invoiceId natural key field. It strikes me that we are in an inheritance centric solution space, but that will have to wait for the Entity Framework. Are there any established patterns for going about maintaining both types of keys?
Last modified: 123hrs 24mins after originally posted --
|
|
|
|
|
Are you asking a question?
Mike Lasseter
|
|
|
|
|
If you want to generate the invoice number as a natural key in code, I might suggest a singleton that would be responsible for generating it (possibly date + sequence based), however, you need to consider other factors that would get messy by storing the "Invoice Number" as a single column.
For instance, if the system started generating invoices today (080705-001) and shuts down unexpectedly, say at 10am, when it starts back up, it would have to reparse the invoice numbers (like '080705-%' to get the last sequence number...obviously, this would be far from ideal. Also, by storing the invoice number in the database, you are now "stuck" with the formating decision you made at design time. If you start generating more that 1000 invoices today, you will have duplicate invoice numbers (another bad situation). Many systems push back the ultimate problem by adding customer id to the invoice number...
Anyway, if you store the invoice date separate from the sequence number, you can retrieve the last sequence number quicker, you are not stuck with a format problem, and you can move the format issue to your business layer if you do have issues.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
