Programming Principles

After catching up on more of the insightful Neal Ford's evolutionary architecture and emergent design series, it got me thinking about the principles that an intermediate to advanced level programmer should be aware of. These thoughts have led this attempt to compose a (WIP) list of the terminology and generic patterns a competent developer should be able to explain:

Composed Method / Single Level of Abstraction Principle (SLAP) / Refactoring

• An understanding of the need to divide your programs into methods that perform one identifiable task resulting in programs with many small methods each a few lines long and responsible for one and only one thing. Operations in a method should be kept at the same level of abstraction. For example avoiding the introduction of methods which deal with both low-level technical details e.g. database infrastructure and high-level domain logic. As a rule of thumb any Java method longer than about 10 lines of code is a candidate for refactoring because it probably does more than one thing.

Single Responsibility Principle / Separation of Concerns (SoC) / Encapsulation / Information Hiding / Principle of Least Privilege / Law of Demeter (LoD)

• Classes and methods should have a single responsibility or reason for change, as you move up the design layers responsibilities become increasingly abstract. In Java concerns should overlap in functionality as little as possible through use of MVC or AOP. Also each layer should only be able to access the other layers necessary to fulfill its responsibilities.

Don't Repeat Yourself (DRY) / Copy-and-Paste Programming / Once And Only Once (OAOO)

• Code should not be duplicated with each and every declaration of behavior appearing OAOO as it increases the difficulty of change, decreases clarity and leads to opportunities for inconsistency.

Coupling / Composition vs. Inheritance / Inversion of Control (IoC)

• Avoiding tight coupling through the use of composition rather than introducing dependencies via inheritance which you will need to decouple later and usage of IoC to decouple execution from implementation. An explanation of expected understanding of dependencies is available here.

Design Patterns

• It is unrealistic to expect someone to hold detailed knowledge of all Design Patterns (I hope!) whether they be the original GoF, J2EE, Enterprise or SOA patterns. However, an understanding of the architectural concepts behind design patterns and the ability to explain a handful of examples such as Singleton, Lazy Initialisation, Factory, Decorator etc. is desirable.

Big Requirements/Design Up Front (BRUF/BDUF) / Analysis Paralysis / You Aren't Gonna Need It (YAGNI) / Technical Debt

• The trade-off of attempting to complete and perfect a design before the implementation has begun through up front planning against remaining adaptable to changing requirements.