Code Quality and Design PrinciplesCode; Reflect; Learn

Michael Kramer, Appeon MVPLean-software@outlook.com

Today’s Agenda

▪ Lectures with interaction▪ Q&As before breaks

▪ Short, focused

▪ 5-min breathers now & then

▪ Tech tips included

Time Content

9:00 – 10:30 IntroductionCode Metrics

10:30 – 11:00 Kaffeepause

11:00 – 12:30 Code QualityClean, Dry, & Solid Code

12:30 – 13:30 Mittagspause

13:30 – 14:30 Design PrinciplesSOLID Principles

14:30 – 15:00 Kaffeepause

15:00 – 16:00 SOLID Principles for realPackage Principles

Introduction

Terminology and History

Michael Kramer

Now

▪ Appeon PowerBuilder MVP

▪ Independent Software Craftsman▪ Developer, Architect, Tech Lead

▪ Instructor, Speaker

▪ Full Life-Cycle

▪ Lean-Agile Perspective

Background

▪ M. Sc. Eng.▪ Computer Science, Operations Research,

Management

▪ Software industry career 1983 –▪ Full life-cycle

▪ PowerBuilder since 1993▪ Certified PB Developer 1995 –

▪ Certified PB Instructor 1995 –

▪ Agile methods since 2001

Warm-Up Exercise

Product

▪ Where do you put obsolete code?

▪ Standard headers?

▪ Return values or TRY-CATCH?

▪ Embedded cursors or datastore?

▪ No. of GOTO?

▪ DYNAMIC in checked-in code?

Development Process

▪ How often do you deploy to PROD?

▪ “Sprint” length?

▪ How often do you change your process?

▪ Is all code and config source controlled?

▪ New developer – when will he/she deploy to PROD?

Warm-Up Continued

Busy without Progress?

Current Pains?

▪ Bug fixing

▪ Extend functionality

▪ Change existing functionality

▪ App-to-app integrations

History

1960’s – 1970’s

▪ Computer industry growing

▪ Younger programmers

▪ Computer Science becomes an academic field

▪ Manage development *and* maintenance

▪ Good Programming Practices to reduce costs

Terminology

▪ Waterfall management approach

▪ Q: How do we measure?A: Software Metrics

▪ Larry Constantine lead thinker

▪ Coupling = Degree of interdependence

▪ Cohesion = Degree of elements belonging together

Terminology

▪ Metric – a comparable way to describe software▪ Sometimes directly measurable. Automated statistics

▪ Other times softer qualities like “habitability”

▪ Often called code qualities

▪ Smell – surface indication of a deeper problem▪ Comments describing a function having weird name

▪ Duplicate code

▪ Comments out-of-sync with actual code

▪ Design Principle – Guidelines to avoid bad design

▪ Design Patterns▪ 1979 Christopher Alexander The Timeless Way of Building

▪ 1994 Gang of Four (Gamma et al) Design Patterns: Elements of Reusable OO Software

Metrics in PowerBuilder• No. of DW objects• % public/private methods• Time to full build• % code left in comments

Code Smells in PB• TRY-CATCH á la F1-Help• DDLB w/DB cursor• Lots of global functions

Bad Design

▪ What you have when you don’t have good design

▪ Rigidity Hard to extend or even fix due to interdependencies

▪ Fragility Unexpected misbehavior even when you are careful

▪ Immobility Hard to reuse functionality in other apps

▪ Flight risk Developers tend to leave project or even the company

▪ Technical Debt – Measure known code design issues

Code Metrics - Examples

▪ Lines of code

▪ Number of classes, packages, DataWindow objects, files, tables, …

▪ Inheritance depth

▪ Cyclomatic complexity

▪ Number of interfaces to other systems

▪ Number of private/protected/public functions, variables

▪ Number of parameters, fraction of parameters being REF/OUT

▪ “Maintainability Index”

▪ Class coupling

Software Quality

Software Quality and Code Metrics

Coupling – Multiple Dimensions/Types

▪ Loose vs. tight coupling

▪ Intentional vs. accidental

Types of coupling in OOP

▪ Identity coupling (type) create n_gis_openstreetmap

▪ Representational coupling lnv_gis.of_DisplayNode( … )

▪ Inheritance coupling … inherits from …

▪ Subclass coupling if dw_data.DataObject = “d_...” then

Code Smells

▪ Long methods

▪ Overriding inherited behavior instead of extending it

▪ Data clumps (same set of parameters for different methods)

▪ Duplicate code

▪ Primitive obsession (“string id” instead of “n_ProductId id”)

▪ Generic identifiers, non-descriptive names, or non-standard abbreviations

▪ Messy indentation

▪ No encapsulation

Software Quality

High quality software:

▪ Makes me want to come to work to extend and improve

▪ Makes me want to match the quality already present

▪ Guides to the place where a bug is hiding

▪ Is obvious and explicit about what is does

▪ Contains no dead code

▪ Leverages the tools at hand like version control

▪ Needs very few comments

Development Practices

Development Practices and Coding Techniques

Practices and Techniques

▪ Encapsulation

▪ Inheritance

▪ Composition

▪ Code to an INTERFACE

▪ Refactoring

▪ Programming by Intention

▪ Use design patterns where applicable

▪ Feature Toggles

▪ Configuration as Code

▪ Version Control Everything

▪ Build Automation

Encapsulation

▪ Information Hiding▪ PRIVATE

▪ PROTECTED

▪ PUBLIC Default

▪ PrivateWrite, ProtectedRead, …

▪ Behavior Hiding▪ PRIVATE

▪ PROTECTED

▪ PUBLIC Default

▪ Always PUBLIC▪ Events

▪ Controls on window/userobject

▪ Menu items

▪ Objects within DW object

▪ Always PRIVATE▪ Shared variables

▪ Structures within class

▪ PRIVATE – Still accessible across controls within same compilation unit▪ Window, Menu, UserObject

Inheritance

▪ Single inheritance

▪ Inheritance:▪ Windows

▪ UserObjects

▪ Menus

▪ Some system classes do not support inheritance

▪ Inheritance Internals▪ Uses Virtual Lookup Tables (~no cost)

▪ PB3: Max 10 levels

▪ Now: No practical limit

▪ Always EXTEND▪ You may override

▪ Override = code smell

▪ Inherit OLEObject▪ No compiler check of method calls!

Composition

▪ Assemble behavior from multiple classes

▪ Distribute responsibility among multiple classes

▪ Delegate processing across multiple objects

PFC

▪ Example of composition over inheritance

▪ Several layers of inheritance

▪ Develop 1995

Code to an Interface

▪ Removes dependency between implementations

▪ Requires an INTERFACE construct in the language

▪ Simulate INTERFACE in PowerBuilder using NVO hierarchy

Simulate an Interface in PowerBuilder

▪ Create NVO class to act as INTERFACE▪ Define only PUBLIC API

▪ May contain default implementations

▪ Inherit from INTERFACE NVO to provide specific implementations

▪ Use “factory” method to instantiate specific implementation

▪ All use of NVO set:▪ ONLY access the base INTERFACE NVO and its API

▪ NEVER access subcomponents (ex. DW columns) NEVER NEVER NEVER

Feature Toggle

▪ Switches code in and out

▪ Temporary in nature

▪ Enables distinguish between DEPLOY and RELEASE

Design Patterns

Introduction

Design Pattern

Design Pattern

A software design pattern is

a general, reusable solution to Reusable solution

a commonly occurring problem within Known problem

a given context. Context matters!

Design Patterns

Façade Adapter

Simplify access through higher-level API Converts interface to another interface

Design Patterns

Singleton Proxy

One and only one instance Surrogate/placeholder for another object

Design Patterns

Strategy Builder/Factory

Set of alternatives to choose between Decides which subclass to instantiate

PowerBuilder Training

Design Principles

Intro and Overview

Design Principles

▪ Guidelines to obtain higher quality code, less cost, more value, faster

▪ Set of recommended principles evolved over time – EX: SOLID▪ 16-Mar-1995 Jim Flemming The Ten Commandments of OO Programming

Suggested list #1 – 10

▪ 16-Mar-1995 Robert Martin My candidates would be … #1 – 11Some SOLID (wrong order), several others

▪ Later revised and reordered, renamed SOLID

▪ Go hand-in-hand with set of package principles

▪ Many other principles▪ Some grouped – EX: GRASP

▪ Some individual

Sets of Principles

▪ SOLID OOD principles▪ Collected by Robert Martin

▪ Different origin – EX: Open/Closed by Bertrand Meyer

▪ SOLID package principles▪ Collected by Robert Martin

▪ Complement SOLID OOD principles

▪ GRASP principles▪ Published by Craig Larman

Design Principles

▪ Persistence Ignorance

▪ Inversion of Control▪ Follows “Hollywood principle”

▪ Stable Dependencies

▪ Don’t Call Us, We Call You▪ Aka. “Hollywood principle”

▪ Explicit Dependencies

▪ Separation of Concerns

▪ Tell, Don’t Ask

▪ Encapsulate

▪ DRY – Don’t Repeat Yourself▪ Includes “Once an Only Once”

(no duplicate behavior anywhere)

▪ YAGNI –You Ain’t Gonna Need It

▪ KISS – Keep It Simple, Stupid

▪ GRASP principles – Later

▪ SOLID OOD principles – Later

▪ SOLID package principles – Later

Design Principles

So many, many, many, …

Boy Scout Rule

▪ Always leave the camp ground a little cleaner than you found it.

▪ Always leave the code base a little cleaner than you found it.

GRASP Principles

General Responsibility Assignment Software Patterns

▪ Guidelines for assigning responsibility to classes and objects

▪ GRASP is a mental toolset, learning aid to help design of OO software

▪ List of design patterns to favor

▪ Controller

▪ Creator

▪ Indirection

▪ Information Expert

▪ High Cohesion

▪ Low Coupling

▪ Polymorphism

▪ Protected Variations

▪ Pure Fabrication

Tech Trick by Mick – Every PB TargetPBT Files for a PB target

1. Library List identical to what we deploy

2. Library List prefixed by a _work_\_work_.pblUsing work library or not is simply changing current targetEases safe experiments

Objects/Classes in my “app” PBL

• Application object itself

• Project to deploy EXE

• Additional app specific projectsNOTE: Web service proxy project in different PBL because proxy is often used across multiple apps and I always refrain from duplicate code (projects included)

• Potentially additional variants of application object if I needed for experiments or debugging purposes.

I follow behavioral patterns from which I benefit.

• At LEAST two PBT files for each PB target.

• Only app object and its projects in the “app” PBL.

• I create one-click tasks for common dev/test tasks:• Get latest “all”

• Full build “all”

• Generate installers for testers

• Restore DB to “origo”

• Upgrade DB from “origo”

Design Principles

The SOLID Principles

Imageshttps://blogs.msdn.microsoft.com/cdndevs/2009/07/15/the-solid-principles-explained-with-motivational-posters/

Single Responsibility Principle

A class should have one, and only one, reason to change.

Open/Closed Principle

You should be able to extend a classes behavior, without modifying it.

Liskov’s Substitution Principle

Derived classes must be substitutable for their base classes.

Interface Segregation Principle

Make fine-grained interfaces that are client specific.

Dependency Inversion Principle

Depend on abstractions, not on concretions.

Design Principles

The “Solid” Package Principles

Package Cohesion Principles

▪ The Release Reuse Equivalency Principle▪ The granule of reuse is the granule of release.

▪ The Common Closure Principle▪ Classes that change together are packaged together

▪ The Common Reuse Principle▪ Classes that are used together are packaged together

Package Coupling Principles

▪ The Acyclic Dependencies Principle▪ The dependency graph of packages has no cycles.

▪ The Stable Dependencies Principle▪ Depend in the direction of stability.

▪ The Stable Abstractions Principle▪ Abstractness increases stability.

Code Quality and Design PrinciplesCode; Reflect; Learn

Michael Kramer, Appeon MVPLean-software@outlook.com

https://www.PowerPeople.de/PowerBuilder_Schulungen