From page 310. Hyperaware Editing
If it isn’t out by the time this book is released, I suspect that someone will soon develop an IDE that allows you to specify a set of tests that will run at every keystroke. It would be an incredible way of closing the feedback loop.
It has to happen. It just seems inevitable. There are already IDEs that check syntax on each keystroke and change the color of code when there are errors. Edit-triggered testing is the next step.
Tests foster hyperaware editing. Pair programming does also. Does hyperaware-editing sound exhausting? Well, too much of anything is exhausting. The key thing is that it isn’t frustrating. Hyperaware editing is a flow state, a state in which you can just shut out the world and work sensitively with the code. It can actually be very refreshing. Personally, I get far more tired when I’m not getting any feedback. At that point, I get scared that I’m breaking the code without knowing it. I’m struggling to maintain all of this state in my head, remembering what I’ve changed and what I haven’t, and thinking about how I’ll be able to convince myself later that I’ve really done what I set out to do.
Page 311
Judgment is a key programming skill, and we can get into trouble when we try to act like super-smart programmers.
The truth is, there are many different kinds of “smart.” Holding on to a lot of state mentally can be useful, but it doesn’t really make us better at decision making.
The Singleton Design Pattern
The Singleton Design Pattern is a pattern that many people use to make sure that there can only be one instance of a particular class in a program. There are three properties that most singletons share:
1. The constructors of a singleton class are usually made private.
2. A static member of the class holds the only instance of the class that will ever be created in the program.
3. A static method is used to provide access to the instance. Usually this method is named instance.
Although singletons do prevent people from making more than one instance of a class in production code, they also prevent people from making more than one instance of a class in a test harness.
The Case of the “Helpful” Language Feature
Language designers often try to make our lives easier, but they have a tough job. They have to balance ease of programming against security concerns and safety. Some features initially look like a clear “win” balancing all of these concerns well, but when we attempt to test code that uses them, we discover the cruel reality.
Page 142 I CAN’T RUN THIS METHOD IN A TEST HARNESS
We’d like to make some changes to this piece of code and maybe refactor it a little, but writing tests is going to be difficult. We’d like to create an HttpFileCollection object and populate it with HttpPostedFile objects, but that is Subverting Access Protection In many OO languages newer than C++, we can use reflection and special permissions to access private variables at runtime. Although that can be handy, it is a bit of a cheat, really. It is very helpful when we want to break dependencies, but I don’t like to keep tests that access private variables around in projects. That sort of subterfuge really prevents a team from noticing just how bad the code is getting. It might sound kind of sadistic, but the pain that we feel working in a legacy code base can be an incredible impetus to change. We can take the sneaky way out, but unless we deal with the root causes, overly responsible classes and tangled dependencies, we are just delaying the bill. When everyone discovers just how bad the code has gotten, the costs to make it better will have gotten too ridiculous.
From the Library of Brian Watterson
The Case of the
“Helpful”
Language
Feature
impossible. First of all, the HttpPostedFile class doesn’t have a public
constructor. Second, the class is sealed. In C#, this means that we can’t create an
instance of an HttpPostedFile, and we can’t subclass it. HttpPostedFile is part of
the .NET library. At runtime, some other class creates instances of this class,
but we don’t have access to it. A quick look at the HttpFileCollection class
shows us that it has the same problems: no public constructors and no way to
created derived classes.
Why did Bill Gates do this to us? After all, we’ve kept our licenses up-to-date
and everything. I don’t think he hates us. But if he does, well, maybe Scott
McNealy does, too, because it’s not just an issue with Microsoft’s languages.
Sun has a parallel syntax for preventing subclassing. They use the keyword
final in Java to mark classes that are particularly sensitive when it comes to
security. If just anyone could create a subclass of HttpPostedFile or even a class
such as String, they could write some malicious code and pass it around in code
that uses those classes. It’s a very real danger, but sealed and final are pretty
drastic tools; they leave us in a bind here.
Comments
Post a Comment