Engineering Patterns & Principles

In my years of working in software development one thing has always stayed constant, namely that stakeholder time pressure and constraints has always lead to the release of poor quality code and resulted in code that looked more like a ball of mud than a intricate integration of well designed units of code.

Now, I will not be solving the Stakeholder or the weak development managers issue in this blog except to say that the agile framework has given us tools to manage this problem so do a bit of research find the solution which is at your fingertips. What I will be speaking about is trying to demystify agile engineering and how it can be used within a well managed agile project to ensure the code being delivered is at the highest possible standard.

I was and still am a creature called a Developer , I am also a Designer and therefore I have a foot in both worlds and can hopefully bring across some useful information that both camps will find relevant and helpful.

As a developer I want to dive straight into coding to get to the point as quick as possible where I can show a working piece of code(LOOK WHAT I HAVE CREATED). As a designer I want to spend time in thoughtful analysis to design a solution that can flex as the solution grows and changes overtime. To bridge the gap between the two worlds we have design principles and practices which are known solution to problems as well as coding standards and best practice which are guidelines and helpers for our developers.

Lets unpack these concepts.

Coding Standards

A coding standards document's purpose is to make sure that all code is designed, written and laid out the same to make it easier for a developer to switch from one persons work to another without the needed change of mindset to try understand someone else's style.

• These are specific to the development team
• They align with enterprise standards
• They are created and maintained by the development team
• They ensures code is readable and understandable by the rest of the team
• They ensure code follows an agreed structure and format
• They are enforced by peer programming and code review

High Level Coding Standard Structure:

Naming Conventions

Indentation

Layout

Exception Handling

Logging

Commenting

Exposure

Keep it short and to the point or else developers will not bother to follow the standards (K.I.S.S)

Best Practices

Coding best practices are a set of informal rules that the software development community has learned over time which can help improve the quality of software.

• Similar to patterns but are not generic rather domain and technology specific
• These are community and development team gold standard solutions or recommendations for solving domain specific problems
• These are proven ways to solve problems that ensures quality and performance
• Used as quick starts for newb's
• Normally recorded in a team manifest per project
• Expanded and refined through the project lifetime

Design Principles

These are principles that have been proven, if followed and applied iteratively and incrementally in an evolutionary manner, through continues code refactoring. They will eventually lead to quality code that is changeable and extendable without introducing risk. The end result of this evolutionary process is Design Patterns which I will discuss later.

The most well know design principle uses the acronym "SOLID":

S = Single Responsibility: One class should have one and only one reason to change

O = Open Closed Principle: Software components should be open for extension but closed for modification

L = Liskov’s Substitution Principle: Derived types must be completely substitutable for their base classes

I = Interface Segregation Principle: Clients should not be forced to implement unnecessary methods they will not use

D = Dependency Inversion Principle: Depends on abstraction not on concretions

Nice read to dig a bit deeper into the principles: SOLID

Design Patterns

NB PLEASE READ THIS NEXT STATEMENT VERY CAREFULLY

if

(

(You would like to shortcut the above process) &&

(You would like to jump straight to the end result) &&

(You understand why you need the pattern) &&

(You understand when to use the pattern)

)

{

Use a pattern where the value out ways the inherent complexity;

}

else

{

Do yourself and everyone else on your team a favor and just follow SOLID;

}

Now that the warning is out of the way lets understand design patterns:

• A design pattern is a proven, reusable solution structure to a problem
• They provides a structure that is tailored to meet the specific requirements of the given problem
• They where developed by looking at the common characteristics of solutions to related problems
• Popularized by the Gang of Four’s 23 design patterns (GoF Patterns)

Types of Design Patterns

Creational - creation of objects

• Abstract Factory - https://sourcemaking.com/design_patterns/abstract_factory
• Factory - https://sourcemaking.com/design_patterns/factory_method
• Prototype - https://sourcemaking.com/design_patterns/prototype
• Singleton - https://sourcemaking.com/design_patterns/singleton

Structural - organizing classes and objects into larger structures

• Adapter - https://sourcemaking.com/design_patterns/adapter
• Composite - https://sourcemaking.com/design_patterns/composite
• Decorator - https://sourcemaking.com/design_patterns/decorator
• Facade - https://sourcemaking.com/design_patterns/facade
• Proxy - - https://sourcemaking.com/design_patterns/proxy
• Repository c# - https://msdn.microsoft.com/en-us/library/ff649690.aspx

Behavioral - algorithms and assignment of responsibilities between objects

• Chain of Responsibility - https://sourcemaking.com/design_patterns/chain_of_responsibility
• Command - https://sourcemaking.com/design_patterns/command
• Iterator - https://sourcemaking.com/design_patterns/iterator
• Mediator - https://sourcemaking.com/design_patterns/mediator
• Memento - https://sourcemaking.com/design_patterns/memento
• Observer - https://sourcemaking.com/design_patterns/observer
• State - https://sourcemaking.com/design_patterns/state
• Strategy - https://sourcemaking.com/design_patterns/strategy
• Template Method - https://sourcemaking.com/design_patterns/template_method
• Visitor - https://sourcemaking.com/design_patterns/visitor

There are allot more patterns out there in the cosmos, the ones I have highlighted above are the most commonly used.

As good as these engineering practices are, if they are not enforced through peer programming and code review they will just remain words on a page. My next blog will look at how Source Control can be use to help enforce these practices to ensure the code being merged into the working branch is clean and of a high quality standard.