8 Core Programming Techniques v7
List of updated items:
0. Changed "Basic" to "Core": this is more about "C" than "B" ;-)
1. Changed the heading “Higher Level Architecture Reading and Lower Level Skills” to “Higher Level Architecture and Process Reading and Lower Level Skills”, and added “RUP and TDD/XP”.
2. Added content for the “no framework approach”, to reflect the reality better in this document/blog – this document/blog was very much “framework-oriented”, perhaps too much.
==============================8 Core Programming Techniques
Key Background Knowledge:
1. Higher Level Architecture and Process 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 “core” 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.tsshttp://msdn.microsoft.com/practices/topics/arch/default.aspx?pull=/library/en-us/dnbda/html/distapp.aspAs for “Process”, please google “software process RUP or UP” and “TDD”.
--------------------------
Note that the above mentioning of “architecture” and “Process” does not mean we need an explicit architecture and an explicit “process” before we can develop software. Further, theorizing from the reality, very often we can see the “no framework approach”:
--------------------------
The rule of the approach is simple: no third party tools, no third party framework. Further, no in-house “official” big framework, no in-house “official” big “utilities”; small utilities or code-reuse is encouraged. Code generation is forbidden also. Note that this includes tools like Nunit. Note the “framework” is especially forbidden, because by its very nature, “frameworks” are include-all; they are very powerful, therefore, very harmful.
Let’s be crystal clear: it does not matter whether it is binary, commercial, free, or open source. For example, no third party controls, even those once that we can buy the source.
This does not mean we cannot use third party software, for example, we use Source Safe, and add-ins for visual studio, as long as they do not affect the code.
--------------------------
“No framework approach” is preferable, usually for the following reasons:
(1) Fast to develop, no upfront learning curve
(2) Easy to upgrade, easy to maintain, by anybody, at anytime
(3) Developers learn a lot in such environment – I know, this is surprising, but it is true. This is also the core spirit of XP/TDD. Also, this does not mean we do not study frameworks. We do; then, we tear them apart, or wrap them, and only use the best one karat out of tons of stuff.
(4) For maintenance development, you have no choice but using this approach.
--------------------------
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 Core 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).
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
----A.K.A. Separation between database access and business logic (“Three goals for architecture design”)
----A.K.A. Reliable and flexible SECURITY-AUDITING(it is code-based, i.e. not database system based)("three common features for any systems or applications")
----For “no framework approach”:
-------- Logging: we need to wrap log4net anyway. Actually, this is a general “sister approach”: let’s wrap it. We can use the thin wrapper in the beginning. If later we really need it, we can “violate” the rule and introduce log4net later;
-------- Data access: the earlier version of the application block is just a few files. So, this is certainly easy to do;
----------------------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.
---- A.K.A. Separation between cross-cut concerns and business logic.(“Three goals for architecture design”)
---- A.K.A. Reliable and flexible SECURITY-AUTHORIZATION ("three common features for any systems or applications")
---- For “no framework approach”:
-------- Use code regularity and snippet, instead of command/code generation/emit, for all façade level cross-cut concerns (logging, security, transaction, remoting);
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.
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" (and without collections)
(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 core 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.
---- A.K.A. Separation between UI and business logic (“Three goals for architecture design”)
---- A.K.A. REGRESSION TESTING (scripted testing, automated testing).("three common features for any systems or applications")
----For “no framework approach”:
--------Unit testing: we can use the same idea, but just use a few in-house methods (AssertEqual etc).
-------- Databinding/validation-formatting: no collection for custom classes, use dataset instead (however, if not collection, then, custom class can be used when needed).
