[macker-user] My (good) experience with Macker

[Doron R. <do...@sc...>]

I am using Macker since December 2003, with 105 updates to the Macker =
script since then (the Macker script is at =
http://www.rajwan.org/macker/macker.xml, but it is not a good example of =
how to write such scripts).

I've setup a daemon machine, which runs 24x7, and checks all check-ins =
to Perforce VCS on-line. When it finds a problem in the submission, it =
sends a popup message to the one who submitted that changelist, and a =
warning email to the rest of ~30 developers. When the problem is =
removed, a relaxation email is sent. Basically, this daemon checks =
compilation errors, module dependencies errors, and some more.

Over time, we've implemented a quite complex module relationship (see =
the image at http://www.rajwan.org/macker/modules.gif, which was =
generated by http://www.graphviz.org/). In the diagram, each box is a =
module and each line is an allowed import. Breaking things into modules =
helps providing a higher quality, well designed and easy to maintain =
software to our customers. It also enables us to have different =
installer and life cycle to our two main products (see the dashed =
boxes).

Programmers are lazy. They always try to find the shortest path to their =
daily goal, without any thought about next week's goal. A rule checking =
tool forces them to set things correctly, with core separated from GUI, =
with encapsulating concepts correctly, and so. When this tool runs =
on-line, and everyone gets a notification, it makes them try even =
harder...

I would even go further: in few cases a deep architecture changes were =
initiated by a problem detected by Macker.

Of course, module dependencies has many forms, e.g., text messages, =
related actions, reflective method invocation, and much more. Macker =
checks the most basic dependency -- imports. But, it proved to be enough =
for automatic detection of 99% of the problems. Finding that last 1% is =
tricky, and we normally fail to detect it until it breaks something.

Switching to JDK 1.5 was easy. Macker worked w/o any change, and even =
found some new errors. This is due to the fact that, in JDK 1.1 to 1.4, =
using 'SomeClassName.class' class literal is just a proxy to some =
compiler-generated static method, and in JDK 1.5 it is a true class =
reference.

Macker is a great tool already, but there are few improvements I would =
like to see. For example, I do not allow programmers to catch Errors, or =
Throwables, but I have no good method to enforce it today. I would like =
to have the ability to find all methods that are using catch for =
anything which is not an Exception or derived of it.

Thanks for providing us such a tool,
  Doron.


__________________________

Doron Rajwan
Chief Software Architect
tel.   +972-9-961-1525  ext. 215=20
fax.  +972-9-956-7958
mbl.  +972-50-951-2349
SCHEMA
Maximizing  Network  Efficiency
w w w . s c h e m a . c o m



This email and any files transmitted with it are confidential and =
intended =20
solely for the use of the individual or entity to whom they are =
addressed.=20
If you have received this email in error please notify us immediately =
and =20
delete this communication.