The architecture you think you have is often different than what you actually have. It’s time to take charge of your architecture and learn how you can discover deviations by writing tests using JUnit, JDepend, and Ant to discover problems proactively instead of long after the fact.
Take Charge of Your Architecture
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…I’ll have to try this. I just somtimes wonder whether things like that shouldn’t be integral part of a programming language rather than additional software.
It can be! It’s a 20-minute exercise to come up with some macros that let you define unit tests in Lisp code. Moreover, since the compiler fully evaluates top-level calls at compile-time, you can do stuff like:
; trees.lisp
(defun make-tree () … ) ; make a tree
(defun add-to-tree (something tree) …) ; add stuff to a tree
; more implementation
; this is a simple macro to write!
(define-unit-test some-test
(add-to-tree 5 (make-tree)))
; need more complete test!
(run-tests) ; run the tests at compile-time
This way, every time you compile the file, the compiler will execute (run-tests), and you’ll get a compile-time error if your change broke any of the unit tests.
Edited 2007-07-13 13:07
OK, but is this theserverside.com or osnews.com?
Some editorial enforcement to keep on-topic, Thom?
Erm, but it was posted by Eugenia Loli-Queru.
“Erm, but it was posted by Eugenia Loli-Queru.”
And…?
And if you knew the history of the site, you’d know why that is significant in relation to your comment.
There seems to be quite a bit of disdain at times for both Eugenia and Thom. It’s sad to see people attacking them for submitting articles to the site, regardless if you agree with them or not. I dare say that the discussions following news posts are what makes OSnews great, and not necessarily always the news itself.
If you have a problem with Thom or Eugenia, perhaps you should be more proactive in improving things rather than just complaining for the sake of complaining.
This was so boring my laptop suspended itself in sympathy. The only reason I am commenting is that it happens to be dangerous rubbish too.
From the article:
Now you can use your build process to proactively discover design violations to your intended architecture.
Really. And what are you going to discover? That package structures are correct? What does that help? It is of so little real benefit that the false sense of security this gives you makes this a dangerous and pointless exercise.
What do you really know after your dependency analysis has passed? You know that this class in this directory does not depend on a class in another directory that you deemed undesirable. There is so many other, more dangerous ways of creating undesirable coupling and dependencies that you are forced to manually check the code for compliance anyway.
Adherence to architecture is challenge that requires vigilance and constant education, not an ant script paraded as a panacea for architects that are afraid to touch the code that they have created there architecture for.
It guards and can redflag against changes made by junior developers. Also there are other products like SonarJ [http://www.hello2morrow.com/en/sonarj/sonarj.php] that will give you more in depth metrics.
Edited 2007-07-13 16:14
The purpose of the site is to expose new thinking in CompSci. You are aware that you can skip a topic?
Skip a topic, yes. Skip a chance to complain about something, hell no!
Hehe, unit test frameworks are over engineered.
It work we had a “unit test” framework. I got tired of the framework and even more tired of other broken tests causing the tests I was working on not to build.
I ended up replacing it by making all unit tests standalone using a function pointer class, streams and shell scripts to run each of the individual unit tests.
Now this structure doesn’t work well with people running visual studio. It seems to not be possible to build a project that lets you build 50+ executables in one directory. We use “jam” anyways (cross platform).
I’d be curious as to how you came to the conclusion that Visual Studio doesn’t make it possible to build 50+ executables in one directory, because I’ve done it. I’m not saying Visual Studio makes managing that many projects and files the easiest at times from a visual management standpoint, but it can certainly do that. I preferred Borland’s C++ IDE myself, but… well, if you’re developing in C/C++ on Windows (that’s what it sounds like you’re doing), most people expect MFC these days, and all that goes with it.
I’ll step out on a limb and guess that it wasn’t building things in the order you would have liked, and thus wasn’t linking without telling it to build more than once. There’s a dialog box for specifying build order that allows you to tell it which order to build in; VS doesn’t automatically detect the build/link order for all libraries and executables that depend on others in the same solution. It’d be nice if it did, though in large projects (50+ executables would be a good example) it’d probably eat a lot more time in the build process to determine that
Nope, linux developer with cross platform target. And I admit i could be wrong about what I said, it’s easy to be lazy and let someone else tell you how to do it 😉
We had a windows guy work with us. He ended up writing some scripts to generate project files from the jam files to build all the unit tests.
Honestly I find visual studio frustrating. A mess of gui design, endless hunting for stuff. And the problem of not being able to mix/match differently compiled libraries on the microsoft platforms (for c/c++ this is a problem at least).
The irritating nature of the available tools makes writing unit tests that much more attractive for debugging.
Well, debugging end products is irritating mostly because of the need to go through a click fest to get to the problem.
Edited 2007-07-13 16:44 UTC
Ok, I see. At least the Dev Studio project/solution files are fairly easy to parse by mere humans and generate, since they’re XML or some mutation like it.
Yes, Visual Studio does some horrible things GUI-wise, and more relevant to this discussion, it does one distinctly horrible thing to any file it creates via one of the wizards:
It adds a dependency to the CWinApp-derived class via #include “CWinAppDerived.h” to everything.
This is the absolute worst thing Microsoft could have done to encourage snarled code: make everything depend on the absolutely highest-level class in the system, even when it doesn’t need to (which only main() and that CWinApp-derived class should ever depend on) which leads people merrily down the road to creating snarled balls of yarn for structure, as they think “Hey, I’m already including this, why don’t I just put everything into this class and call into it?” which effectively becomes a new mutation of a global variable, with the difference that the global variable/object also depends on everything else. It also makes it impossible to reuse any class in a different application that doesn’t have that same class name, that still has that #include there, without at least removing it manually. Beginners (and those that aren’t beginners, too) see it as being perfectly fine, and add to the balls of yarn in production as a result.
If they ran the stuff mentioned in this article on most MFC-based projects, it’d scream bloody murder!
There is a way to disable this misfeature of Visual Studio from affecting you, but you need to manually edit the pattern files Visual Studio uses.
Reuse is so overrated. I seldom end up reusing an old class in another application. I’d rather keep it simple and streamline code for a specific application.