Two crucial techniques or, two “prevent-the-worst practices”: design review and code review

Two crucial techniques or, two “prevent-the-worst practices”: design review and code review

1. Use short-and-often design reviews. Related with that, always carry over all content in one document through out the whole life cycle: Spec--design--developer test plan--developer user manual. We can freeze a version of the document as the “spec”, “design”, etc. However, carry over all content to the next stage.

a. This does not mean “developers do it all”. QA will have another test plan (likely based on the “developer test plan”), and support people and users will have their own SOP or “real” user manuals. However, carrying over all content in one document is the only cost-effective way to ensure that the spec is always sync-ed with the reality, which is really the make-or-break thing for a project/product.

b. The document must be checked-in with source code, and always sync-ed with source code.

c. Short-and-often design review is crucial for good teamwork and good communications. “Design” is the key: if there is no design, then, there is no testing plan and no spec-modeling.

d. A few more words about “spec-modeling”: users can never “give” spec so that developers can just “gather” them -- it is never that easy. Spec process is a modeling process, and a modeling process must be driven by “design”.


2. Use short-and-often code review. Related with that, always use coding standards, even for throwing-away code in vb3, vb6, and vb.net.

a. Code review must be short, but also often. It is more about teamwork (understanding each other’s code and enabling each other) than whipping people to standards.

b. However, if there are no standards, then, there is no code review. So, we need standards, even for legacy code in vb3, vb6, and vb.net. Also, whenever possible, and under the general rule that “do not mess up existing consistency or regularity”, we should use C# style in old code.

Why data binding is important

Why data binding is important

Some OO purists believe domain model should not consider data binding, because data binding is an UI issue.

I do not agree. However, before I start my argument, I want to point out that I share the mentality to throw away VB6’s “click programming” – if you read my blog, you know I do not like VB6 and anything (and anybody!) related with it -- if you cannot reinvent yourself away from VB6, then, you deserve it for whatever -- I still use VB6 sometime when I do "maintenance development", so, I am not a snob.

First a few words about the big picture: I believe “anemic domain model” is a very good compromise for modern distributed computing. “Classic” OO must adapt to modern distributed computing, otherwise, it degrades into “antique” OO.

OK, now my argument for data binding: it helps us to follow strictly the number one rule in “distributed computing”: “entities” must have no dependency on services and Daos.

Of course, the help is not “automatic”. It is done by making the consequences worse: because databinding is mostly not controlled, as a result, if you put some service/dao in code that invoked by databinding, then, you will feel it immediately and will never do it again. As a result, very soon, the root of modern OO will establish in your brain!

I will post more blogs about it later.

You can also see it as to tear apart CSLA’s databinding/validation functionality, so that you can use it by your self, not as a “framework” – I have been very “nice” to this part of CSLA until now – I have been treat it as an integrated whole; however, it turns out that it can be tore apart into smaller pieces that are even easier, more common sense, and more flexible, so that we can use them ubiquitously.