Post #101,073
5/9/03 11:34:40 AM
|
Cringely on Refactoring
Bob explains his remarks about refactoring [link|http://www.pbs.org/cringely/pulpit/pulpit20030508.html|here].
As usual, I find myself both agreeing and disagreeing with him:
As I may have mentioned before, I'm not a professional programmer but I do try to keep up as best as I can with theory and practice to share with my students.
Any real-world good/bad/indifferent experiences to share about refactoring?
(As always, [link|http://www.joelonsoftware.com/index.html|Joel Spolsky] has a few things to say about this. He makes extensive use of refactoring for continuous improvement of his CityDesk product. )
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #101,076
5/9/03 11:44:55 AM
|
He's still skirting the real issues to make his "point".
His point, that refactoring in open source projects is done out of ego, may or may not be true. But now, to defend that assumption, he's extending his arguments to all refactoring.
He makes some good points, but basically it comes down to "refactoring done in a bad way is harmful." Film at 11. Using a hammer in the wrong way is harmful too. I agree with most of his points but not his presentation, which is slanted to make programmers seem like knee-jerk fanatics.
I'm disappointed that he made no mention of unit tests, and their usefulness in making sure that the refactoring you do doesn't break working code, which was his main argument against refactoring.
I'd be inclined to spend more time arguing with him if I thought his opinion mattered. As it is, what he thinks about refactoring isn't like to affect me in any substantive way. ;-)
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,079
5/9/03 11:57:52 AM
|
Good point
Refactoring without pre-building unit tests is pretty pointless.
Do you use both/either in the normal course of your coding?
Got any anecdotes to share?
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #101,086
5/9/03 12:25:32 PM
|
Do I use unit tests?
The latest module I'm working on, which is a complete rewrite of existing functionality (about 5000 lines of uncommented PL/SQL -- without unit tests, incidentally, and completely unmaintainable at this point because it has never been refactored :-P -- being rewritten in Java):
Lines of source code (minus comments): 2269
Lines of unit test code (minus comments): 1894
Answer your question? :-)
Nearly every line of code I write has a unit test. Exceptions, at this point, are web applications containing a lot of Javascript. These are problematic to test in an automated fashion, but we're working on it. I do have "manual" unit tests (which must be run in a browser) for some of that code, however.
Furthermore, unit testing is now an integral part of my development process. I'm not quite as hard core as the XP people would like, but a typical coding session for me involves 1) writing a method, 2) writing a unit test for that method, 3) run test, 4) fix code. Repeat 3 and 4 until the test (and all other tests) passes.
The idea is that you have to test your code anyway. Why not test in a fashion that allows you to easily re-run the tests any time you want, instead of using ad-hoc one-off scripts and visual inspection? And once you've done that, make running the unit tests (which is now very easy to do) an integral part of the process after each piece of code is written. An additional benefit is that you can now change things midstream. If the interface is the same, you can immediately test your changes against the unit tests.
Anecdote: I wrote a list-parsing class two weeks ago. A few days ago, I discovered that it didn't properly parse empty list elements (like one,two,,four - the empty element was being silently dropped), and I had neglected to test for that fact when I wrote the class. So I added a test for that condition, verified it failed, then completely reworked the internals of the parsing method. When I was done, I reran all the tests to verify that 1) the old functionality still worked and 2) I had fixed the defect. The internals of the class were completely refactored. Absolutely no harm was done, because of the unit tests.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,092
5/9/03 12:53:25 PM
|
Apparently my question sounded dumber than it actually was
I didn't mean to imply that you just ground out code without testing.
I'm always on the lookout for tips and tricks from the professionals that I can pass on to my students, particularly those in their second or third term where they have a good grasp of basic syntax and grammar but lack skill and practice in implementation.
For example, a typical newbie problem is trying to write the entire program all at once instead of phasing in functionality. I have several students right now who are in the habit of doing this and it's taking quite a few sessions of working through problems with them to get this across.
Another phrase I pass on is "Be prepared to throw all the code out and start over."
Recently a student showed me his function for swapping the values of two integer variables:
void swap_int(int& x, int& y)
{
x = y;
y = x;
return;
}
It took me several moments to realize that he wasn't kidding. Then I took him by the hand to the whiteboard with a couple of examples to illustrate why it wasn't working the way he expected.
Granted, his story is atypical. But I think it shows that good coding practice is much more than just knowing the syntax of a language. I'm trying to incorporate examples of good practice in my lessons and talking to people like you who code for a living helps a lot.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #101,093
5/9/03 1:00:45 PM
|
Lessons to be gleaned:
- Don't write the whole thing before you start testing.
- When you find a bug, add the test first, verify it fails, then fix until it no longer fails. That way you know you're actually fixing the bug, and not just adding another test that would pass anyway.
- Use a framework that gets out of the way. Testing will get easier and easier, to the point where it's actually fun. I recommend JUnit and friends; the API is very similar across a gamut of languages. We use the Java and PL/SQL frameworks here; we don't use the C++ framework only because we already had one.
- Rerun ALL the tests after EVERY change. This is where a unit test becomes a regression test. You want to make sure you didn't break other things by association.
- Testing enhances maintainability. If you can change something and immediately know if you broke something else, then you're more likely to have confidence in your changes.
I'll add more as I think of it. :-) Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,094
5/9/03 1:09:15 PM
|
Great stuff!
What about your definition of a 'unit' for testing?
In other words, what amount of code is too small to bother with having its own unit test?
How much code is too big for just one test?
I think you've already established one metric: "One method, one test".
I knew about JUnit already, but can you recommend some similar frameworks for C++? (We start our students out with C++ before moving them to other languages.)
Tom Sinclair
"Of course, just because we've heard a spine-chilling, blood-curdling
scream of the sort to make your very marrow freeze in your bones doesn't
automatically mean there's anything wrong."
-- (Terry Pratchett, Soul Music)
|
Post #101,095
5/9/03 2:04:17 PM
|
Re: Great stuff!
[link|http://www.xprogramming.com/software.htm|The mother lode of testing frameworks].
I do a lot of Java unit testing. Here's how I break it down:
1) One matching unit test per class. If the class is Foobar.java, then I have a FoobarTest.java.
2) One suite of tests per package. The suite is a Java unit test that can group other unit test classes. If the package were com.spork.stuffies, with a Foobar.java and a Moobar.java, then I'd have FoobarTest.java, MoobarTest.java, and a StuffiesSuite.java that simply incorporates the FoobarTest and MoobarTest. The tests would all go into the com.spork.stuffies.test package.
3) Within a unit test, I have a set of test methods. The breakdown varies depending on functionality; typically I will group them by function; ie. in the list test class I have a testCreate to test the constructors, testParse to test the parsing, etc. Within each of those methods I will have a series of "make this call, then test the results" blocks. I make use of unique descriptive strings passed with each assert to be able to nail down where a particular test method fails.
4) The need for setup and teardown will affect the number and kind of methods in the unit test class as well. If there is a fair amount of setup, and it has to be done fresh before a test, then that test should have it's own method. The setups and teardowns get run before each test method in the test class.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,241
5/10/03 10:16:03 PM
|
C++ unit testing - sounds painful
I mean, the typical failure mode for a C++ program is an unrecoverable core dump. I guess you can use it to test logic errors but you're only getting some of the benefits.
I have to say that the SUnit framework that we are using in Squeak these days is FAB! You run the tests and it puts up a list of failures in a window. Click a failure and the code is rerun and a debugger opens on the entry point for the test. You step in, watch what is going on, fix it as you go, and move on. Coding in the debugger is fun!
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #101,099
5/9/03 2:14:49 PM
|
More:
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,115
5/9/03 3:33:25 PM
|
Code coverage
I seem to remember tools for this as well. TCov/Gcov?
|
Post #101,103
5/9/03 2:45:32 PM
|
How does JUnit (and the like) deal with web pages?
Most of what we write is web pages served up by PHP. Does JUnit allow you to define simulated HTTP POST/GET actions? Does it have a way of running PHP functions that are not called by the web server? (Later versions of PHP work from the command line so this will be less of an issue.)
I know these questions are fairly specific to PHP, which I know you don't do much (at all?). But I have zero experience with testing tools, so don't understand how they can be used to test individual functions within a PHP script.
===
Implicitly condoning stupidity since 2001.
|
Post #101,104
5/9/03 2:50:06 PM
|
Not really specific to PHP.
JUnit is a unit testing framework for Java code.
There is a Java framework called [link|http://httpunit.sourceforge.net/|HttpUnit], however, that can do GET, POST, manage cookies, parse HTML, etc. So HttpUnit in conjunction with JUnit is pretty good for testing web pages.
And in fact, looking at that page now for the first time in a few months I see that HttpUnit now [link|http://httpunit.sourceforge.net/doc/Javascript-support.html|supports some Javascript].
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,107
5/9/03 3:05:10 PM
|
Also from that page
Didn't see that link until after I posted, but there's [link|http://phpunit.sourceforge.net/|PHPUnit]. The docs are kind of sparse. It's hard to tell what are the example class names, and which are the actual PHPUnit classes, but I suppose that will make more sense once I have it installed.
===
Implicitly condoning stupidity since 2001.
|
Post #101,110
5/9/03 3:08:18 PM
|
HttpUnit is more useful for integration testing.
I've also used portions of it to simulate a web browser in 'screen-scraping' type applications.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,184
5/10/03 12:17:17 AM
|
We use PHPUnit where I work.
If you do any kind of object programming in PHP, it will not be hard to figure out how to use it. We have one file per test class with multiple Test* methods that test things. Just be aware that you can't leave intermediate stuff hanging around between tests - it creates and destroys the test instance for each test.
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #101,146
5/9/03 5:30:28 PM
|
I'm experimenting with testing dynamic content ...
When you start using TDD seriously, your coding style changes to accomodate testing. Adding tests to an existing code base is hard. Writing tests as you go is easy. So, the way you do dynamic content on a web page may change to facilitate the abiliity to test. I've not done any PHP work (so I'm not sure how applicable this is to your situation), but I began experimenting with some dynamic content test first approach. Here's what I'm trying out ... First you separate your static page data from the dynamic part. We don't really care about testing the static part (why? ... ummm ... because it's static). We do care about making sure the dynamic content is correct however. I choose to use a template system for the static content. The dynamic part choses the template and defines a set of name/value pairs used to populate the template based upon the input to that web page. Then my unit tests just exercise the dynamic portion and make sure that the proper name/value pairs are supplied with the desired template. Example ... \n class LoginPage < Webpage\n def update(cgi)\n if valid_password(cgi['account'], cgi['password'])\n next_page = select_template('start_screen')\n next_page['account'] = cgi['account']\n else\n next_page = select_template('login_screen')\n next_page['msg'] = 'invalid login, try again'\\\n end\n return next_page\n end\n endAnd the unit test might look like ... \n class LoginPageTest\n def test_good_login\n page = LoginPage.new\n cgi = {'account' => 'jim', 'password' => 'goodpassword'}\n next_page = page.update(cgi)\n assert_equal "start_screen", next_page.template_name\n assert_equal "jim", next_page['account']\n end\n\n def test_bad_login\n page = LoginPage.new\n cgi = {'account' => 'jim', 'password' => 'boguspassword'}\n next_page = page.update(cgi)\n assert_equal "login_screen", next_page.template_name\n assert_match /invalid login/, next_page['msg']\n end\n endThat's just a sketch of what I'm trying. I've glossed over some details. Any feedback is welcome. --
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #101,125
5/9/03 4:15:07 PM
|
Can I quote this thread?
I'd like to take the tips/tricks/best practice suggestions from this thread and compile them into a handout for my students.
If you've replied already or are planning to reply to this thread, please let me know if you'd rather I not use your remarks.
I'll edit a bit to eliminate off-topic, non-technical points and if you wish, I can post the compilation for approval here.
I'm pushing to have our programming curriculum include more real-world best practice topics and this would be a great start. My program director agrees with me and now it's a matter of selling it to the other faculty and the students.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #101,126
5/9/03 4:21:19 PM
|
Even better:
Compose your compilation, and post it on [link|http://twiki.iwethey.org/twiki/bin/view/Main/|TWikIWETHEY]. :-)
But yes, you have my permission. The more people using testing, the better.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,139
5/9/03 5:10:44 PM
|
No, you can't use my comments
After all, it's not like I posted them to a publicly accessible place or anything. Oh wait ...
[image|/forums/images/warning.png|0|This is sarcasm...]
===
Implicitly condoning stupidity since 2001.
|
Post #101,165
5/9/03 8:43:43 PM
|
Thanks!
I'll see what I can put together this weekend.
Tom Sinclair
"Man, I love it when the complete absence of a plan comes together."
- [link|http://radio.weblogs.com/0104634/|Ernie the Attorney]
|
Post #101,137
5/9/03 5:09:24 PM
|
A TDD Example
tjsinclair: I'd like to take the tips/tricks/best practice suggestions from this thread and compile them into a handout for my students.
If you are interested, I have a laboriously detailed account of a pair programming session at one of our XP user group meetings. Lots of test-first design examples and some refactorings are given. Feel free to use whatever you need.
Here's the URL: [link|http://w3.one.net/~jweirich/talks/tdddemo/index.html|http://w3.one.net/~j...dddemo/index.html]
(Note: that URL should be good until mid month when my ISP upgrades me from 100 Megabytes to 5 Megabytes of web storage. Needless to say, I'm working on getting a new site, but it won't be ready for a week or two).
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #101,239
5/10/03 10:01:19 PM
|
Ooh, he left out the ^
and a line
void swap_int(int& x, int& y)
{
x ^= y;
y ^= x;
x ^= y;
}
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #101,253
5/10/03 11:37:38 PM
|
That's just evil to the core. :-)
|
Post #101,316
5/11/03 5:43:45 PM
|
It's C++, what do you expect?
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #101,413
5/12/03 8:43:53 AM
|
I would only use that if it were properly commented.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #101,435
5/12/03 10:35:20 AM
|
I'd probably never use it at all
Its a cool parlor trick I think. Thats about it.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #101,462
5/12/03 1:08:32 PM
|
Its a cool parlor trick...
...that has an annoying tendancy to show up on the [insert correct TLA here; the name of the test that you have to take to get into a Master's program] test.
(This gettin old just isn't what it's cracked up to be...)
jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
|
Post #101,466
5/12/03 1:25:21 PM
|
Not even really a C++ issue as such, is it?
You can do that evil thing he did in ANSI C with pointers. Have you seen this? \nregister n = (count + 7) / 8; /* count > 0 assumed */\n\n switch (count % 8)\n {\n case 0: do { *to = *from++;\n case 7: *to = *from++;\n case 6: *to = *from++;\n case 5: *to = *from++;\n case 4: *to = *from++;\n case 3: *to = *from++;\n case 2: *to = *from++;\n case 1: *to = *from++;\n } while (--n > 0);\n }\nNow THAT is evil! -drl
|
Post #101,565
5/12/03 8:50:05 PM
|
Its a Duff Device
and as an optimization for moving chunks of data rapidly its pretty good.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
Post #101,594
5/12/03 11:25:43 PM
|
Yep - it's assembler in C
-drl
|
Post #101,603
5/13/03 12:25:46 AM
|
Most ASM Languages have a SWAP instruction.
|
Post #101,651
5/13/03 11:18:05 AM
|
Yes, not my point
My point was that C is syntactically capable of these kinds of weird things you might use at a very low level.
-drl
|
Post #101,657
5/13/03 11:27:46 AM
|
And my point...
... (if there's really a point to be made) is that this is even lower level than assembly language (unless you count the One Instruction Machine). More like programming ASIC's. :-)
|
Post #101,654
5/13/03 11:20:14 AM
|
SWAP?
SWAP? Did you mean MOVB/MOVW?
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #101,853
5/14/03 1:45:11 PM
5/14/03 1:46:33 PM
|
That's ANSI C?!?
ANSI C compilers I've run across recently wouldn't allow you to put a case label inside of a block (i.e. inside of an open curly brace). I know ANSI C++ won't let you... jb4
"We continue to live in a world where all our know-how is locked into binary files in an unknown format. If our documents are our corporate memory, Microsoft still has us all condemned to Alzheimer's."
Simon Phipps, SUN Microsystems
Edited by jb4
May 14, 2003, 01:46:33 PM EDT
|
Post #101,854
5/14/03 1:56:36 PM
5/14/03 1:58:08 PM
|
That's ANSI C?!? ... YES
I just tried it undef GNU C++, GNU C and Solaris C++. Duff's device works fine under all of them.
(NOTE: I had to change "register n" to "register int n" for it to work in C++).
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Edited by JimWeirich
May 14, 2003, 01:58:08 PM EDT
|
Post #101,859
5/14/03 2:22:19 PM
|
Re: That's ANSI C?!?
No, it's antsy C!
Took me a while to figure out what the hell it was for the first time I saw it.
-drl
|
Post #101,108
5/9/03 3:05:12 PM
|
Re: Good point
Refactoring without pre-building unit tests is pretty pointless.
Exactly. Refactoring without unit tests is dangerous and I would agree with him in that case.
But advocates of refactoring generally also advocate unit tests. In fact, I first learned about unit tests from reading Fowler's refactoring book. I've been doing most of my coding test-first for the past 3 years and believe it to have markedly improved the quality of my code.
I've become a strong believer in unit tests, and especially letting them drive the design and implementation.
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
|
Post #101,111
5/9/03 3:10:26 PM
|
Another good point
especially letting them drive the design Unit tests also point out deficiencies in design. I've had a few instances of "jeez, this API I just designed sucks for this task" while writing the unit tests. Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #101,185
5/10/03 12:19:54 AM
|
Me too.
I've also had the happy experience of refactoring code from a child class to a base class and watching the unit tests confirm I haven't broken anything. :-)
Wade.
Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
| |
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please
| -- "Anything but Ordinary" by Avril Lavigne. |
|
Post #101,240
5/10/03 10:07:09 PM
|
FWIW, Squeak is undergoing a huge refactoring effort
Since the creation of a module loading system (kind of like cpan), many packages in Squeak have been undergoing refactoring to make then loadable/unloadable. Why? We want Squeak to be practical for PDA's.
Some guys at Berne are also refactoring the core because there are issues with doing certain language projects with the current structure (which is kind of crufty after many years of rapid development). So refactoring is sometimes necessary to progress from the state you have to the state you want to get to.
Unless you consider your code base to be a dead end. Then there is no reason to refactor. But Smalltalkers don't consider code to be a dead end ever. Smalltalk is more like sourdough (or sourmash to you bourbon fans) - you have to continue to tend the mother sponge to maintain the line.
"Packed like lemmings into shiny metal boxes.
Contestants in a suicidal race."
- Synchronicity II - The Police
|
