8 Basic Programming Techniques v6

8 Basic Programming Techniques v6

List of updated items (quick notes: -- Why I am so pedantic or “academic”? I am writing a big book ;-) – this blog is my high level notes -- I need to keep it clear, always!)

1. Added content of “Three goals for architecture design” to each of the three sections
2. Added content of “three common features for any systems or applications” to each of the three sesctions.
3. Changed the heading “High Level Architecture Reading” to “Higher Level Architecture Reading and Lower Level Skills”, and added “(OO) design patterns, generics, AO design patterns” to it.



==============================8 Basic Programming Techniques

Key Background Knowledge:

1. Higher Level Architecture Reading and Lower Level Coding Skills

Those 8 techniques are described in a top-down style – I assume there is only one (basic) “architecture”, and you know THE architecture. I know it is unusual that we need to talk about THE “architecture” before we talk about the “basic” techniques. Actually, that is NOT that “unusual” -- without knowing those architecture diagrams, a programmer is working in the dark. Again, note that there are many diagrams, but they all convey the same basic architecture.

Reference diagrams from Sun (“Core J2EE patterns”) , Ejb community (“EJB Design Patterns”), and MS-MSDN best practice (“application architecture”):

http://java.sun.com/blueprints/corej2eepatterns/

http://www.theserverside.com/tt/books/wiley/EJBDesignPatterns/index.tss)

http://msdn.microsoft.com/practices/topics/arch/default.aspx?pull=/library/en-us/dnbda/html/distapp.asp


In addition to the above, we also need low level coding skills, i.e., “(OO) design patterns, generics, AO design patterns”.


2. General Reading

Computing changes fast; therefore, experience alone is not enough. Learning through hand-on experiences is not enough. Attending conferences, user groups, and training classes is necessary. However, the most important means is through reading (including listening/watching videos, of course).

Because reading is so important, and because it is so intensive and lasts so long for computing career, it is actually not as simple as it sounds – there are many things need to be continuously pay attention to: how to make notes, how fast is the reading, how close the reading with the daily work, how close the reading with some hand-on experiments, how to find materials, structured or non-structured (e.g. blogs ;-), how to buy those materials, etc.

-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
---------8 Basic Programming Techniques per se
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------


----------------------backend techniques
----------------------The only thing I can argue about grouping logging with databases, is that for a long time, I always put them together. Perhaps it is because the most important logging is database access logging; perhaps it is because logging is somehow similar to database anyway. Note that the second logging in the middle-end is different from the first logging in the backend. The second one is focusing on the “aspect” aspect of it (the “client-side” of the logging); the first one is on the logging itself (i.e., the “server-side” of the logging).
----Separation between database access and business logic (“Three goals for architecture design”)
----Reliable and flexible SECURITY-AUDITING(it is code-based, i.e. not database system based)("three common features for any systems or applications")

1. Use log4net, in a simplistic style (avoid fancy stuff)
2. Use MS Ent Lib’s data access block
2’. Use Nhibernate, instead of Ent Lib, when we are in “advanced” situations

----------------------middle-end techniques
3-4-5-6. Use the DynamicProxy in castle framework to centralize remoting(3), transaction handling(4), security(5), and logging(6), at the façade level.
----Separation between cross-cut concerns and business logic.(“Three goals for architecture design”)
----Reliable and flexible SECURITY-AUTHORIZATION ("three common features for any systems or applications")

Note 1: This is aop and we need to use emit to do it. Note that this removes a lot of needs for coding-time code generation via tools like codesmith. Another side of it is the snippet in IDE. Note that there are other timing choices for code-generation, like asp.net. Coding time code generation is a very powerful tool for programmers. However, it should not be used as a "fix" for architecture design problems – generated repeating code is still duplicated code. In short, declarative programming is the way to go; and it requires code-generation; we need a whole range of timing choices do that, from language build-in to runtime manipulation.

Note 2: In order to do that, Use programmatic IoC (i.e., centralize all “Factories”); but for most projects, do not use XML style IoC (that is too heavy)

--- to avoid client casting, use factoryMethod
--- use abstrctFactory for switching easily
--- put class name, method name, variable name in the factoryMethod


----------------------front-end techniques
----------------------You may ask: why you put unit testing in the front-end group? Reason: I could put it in the middle-end. However, for a long time in my mind, it has always been in the front-end group, perhaps for two reasons: (a) it is an alternative of the UI code; (b) its very existence depends on the diligence of keeping UI code thin and clean -- remember, I do not believe in unit testing UI code -- that is the next generation stuff; not nowadays everyday practice.
----Separation between UI and business logic (“Three goals for architecture design”)
----REGRESSION TESTING (scripted testing, automated testing).("three common features for any systems or applications")


7. The above security and logging can be at property level (i.e. "entity" level, instead of "facade" level or "data access logic" level);
7'. Use the custom class business rule validation technique in CSLA; but via AOP (see above about AOP, but at property level).
7''. Use the “custom class databinding” technique in CSLA; but via AOP (see above about AOP, but at property level).
--- class-to-form using custom event
--- form-to-class (onchange; no exception in set; use rule)

--- tip: listview/read-only-grid read-only: this is good for user anyway;
so, no need of typed collection (note: sorting etc are control's business)
--- tip: update's return object: only get the seq and update the property
do not try to replace the whole object
--- tip: use read-only properties to "borrow" fields for m-m-like
--- tip: inheritance or parent -- pass reader, tx, parent etc.


--- "CSLA with dynamic proxy/aop":
(a) not limiting to 4 (CRUD) methods;
(b) so, no need of special workflow objects,
(c) so, no need for special “criteria” and “exists” classes.

(d) At property level, cleaner property/get/set,
because no CanRead/WriteProperty, PropertyHasChanged calls.

(there is more background info in this blog:
http://www.blogger.com/comment.g?blogID=26752431&postID=115078085354288833
)


--- leverage the full power of the “custom class” in the age/context of “SOA”:
Javascript subset C# to Javascript translator. The good news is that I believe I found it in Ajax framework community.



8. Use Nunit, but only on façade methods.

8'. 3-in-1 document writing for Spec, Test script (Fit or Fit-like), and User Manual: Unit testing is the pivot in all development activities. However, that is easy to say than do. To get that done in a smooth and controlled manner, we need to take a larger perspective, hence this item. For details, please read my related blogs.

---- Note this does not mean this 3-in-1 document writing takes away the pivotal position of unit testing. Unit testing is still the king – from a developer’s biased/tunneled perspective anyway :-)

---- Also note that by this small step, we are combining XP (TDD) with RUP/UP/ISO 9000/SOX. Because the key idea of the latter is “document driven”; and “3-in-1 document writing” is “document driven”. I really believe that in the electronic world, when we routinely take notes in Word (OK, or “StarOffice”? – actually I take notes using VIM, so, do not flame me for being M$ centric) and emails, there is no justification to use those story cards or ORC cards or pieces of napkin anymore – although they sound romantic. In other words, we can expand this further: taking electronic notes is one of the eight basic programming techniques. I know it sounds craze; however, and take some observation yourself:

In meetings, how many people are taking notes using a paper notebook? I guess it will still take a while for us to use a notebook computer, a tabletPC, or, a smaller PDA, or, just use the “old” technique that use a piece of paper and then later put the notes into a computer. The latter practice requires discipline; but it works. Regardless, if you really think about it, contrary to what XP/TDD tells us, those paper notes are not and cannot be simply thrown away; as a result, those paper notebooks are at least one of the sources of unagility.