Code Craftsmanship Checklist

CODE CRAFTSMANSHIP CHECKLIST
Ryan Polk

The List
 Intended as a checklist for The items presented are intended to
give a selection of ideas for
further research. consideration in any Code Quality
training agenda.
 Not a comprehensive list.
It is understood that one training
 If your not thinking about would not be capable of covering
these subjects your not all subjects listed. The decision that
needs to be made by any
moving your development organization is what topics are of
most value to the teams.
career forward.
 What Else / How can we
do it better?

Code Craftsmanship Topics
3

 TDD / Automated Unit Tests  SOA (Service Oriented
 Continuous Delivery Architecture)
 Refactoring  Paired Programming
 Design Patterns  UML / Object Modeling
 Emergent Design
 SOLID Principles
 Misc. Code Craftsmanship
 Error Handling
 Code Smells and Heuristics
 Etc…

Continuous Delivery
4

 Principles and technical practices that enable rapid, incremental
delivery of high quality, valuable new functionality to users.

 Taking the next step beyond Continuous Integration is essential in
all development originations that produce highly integrated and
complex systems.

 Through automation of the build, deployment, and testing process,
and improved collaboration between developers, testers, and
operations, delivery teams can get changes released in a matter
of hours sometimes even minutes no matter what the size of a
project or the complexity of its code base.

Refactoring
5

 Code refactoring is the process of changing a computer program's source code without
modifying its external functional behavior in order to improve some of the nonfunctional
attributes of the software.
 Advantages include improved code readability and reduced complexity to improve the
maintainability of the source code.
 Techniques that allow for more abstraction
- Encapsulate Field – force code to access the field with getter and setter methods
- Generalize Type – create more general types to allow for more code sharing
- Replace type-checking code with State/Strategy
- Replace conditional with polymorphism
 Techniques for breaking code apart into more logical pieces
- Extract Method, to turn part of a larger method into a new method. By breaking down code in smaller
pieces, it is more easily understandable. This is also applicable to functions.
- Extract Class moves part of the code from an existing class into a new class.
 Techniques for improving names and location of code
- Move Method or Move Field – move to a more appropriate Class or source file
- Rename Method or Rename Field – changing the name into a new one that better reveals its purpose
- Pull Up – in OOP, move to a superclass
- Push Down – in OOP, move to a subclass

Design Patterns
6

 In software engineering, a design pattern is a general reusable solution to a
commonly occurring problem in software design.
 A design pattern is not a finished design that can be transformed directly into
code. It is a description or template for how to solve a problem that can be
used in many different situations.
 Object-oriented design patterns typically show relationships and interactions
between classes or objects, without specifying the final application classes or
objects that are involved.
 Design Patterns provide a common language and structure to the overall
design and architecture of software systems. This common language gives us
the ability to talk about the parts of a system as a simple conglomerate of
patterns instead of a list of random parts.
 Patterns are a basic building block of code re-use and code extensibility.

Emergent Design
7

 Is a principle of software adaption over time, espousing the principle that
software should grow better over time and not degrade as many systems do.

 This system combines many different methodologies including the other topics
listed with other solid practices in software development to create a
comprehensive system for the maintenance and support of software systems.

 Topics Covered:
- How to design software in a more natural, evolutionary, and professional way
- How to use the “open-closed” principle to mitigate risks and eliminate waste
- How and when to test your design throughout the development process
- How to translate design principles into practices that actually lead to better code
- How to determine how much design is enough

SOLID Principles
8

S - Single Responsibility Principle (SRP) the notion that an objects should have only
a single responsibility.

O - Open / Closed Principle (OCP) the notion that “software entities … should be
open for extension, but closed for modification”.

L - Liskov Substitution Principle (LSP) the notion that “objects in a program should
be replaceable with instances of their subtypes without altering the
correctness of that program”. See also design by contract.

I - Interface Segregation Principle (ISP) the notion that “many client specific
interfaces are better than one general purpose interface.”

D - Dependency Inversion Principle (DIP) the notion that one should “Depend upon
Abstractions. Do not depend upon concretions.”
Dependency injection is one method of following this principle.

Service Oriented Architecture (SOA)
9

 In computing, a service-oriented architecture (SOA) is a flexible set of design
principles used during the phases of systems development and integration.

 A deployed SOA-based architecture will provide a loosely-integrated suite of
services that can be used within multiple business domains.

 Providing Training on the Basic Principles of SOA will give all participants a
better understanding of best practices needed to create loosely coupled
systems with greater amounts of system re-use and higher flexibility.

 Currently we are proficient at implementing some of the practices of SOA but
our understanding of the principles and the orchestration of systems needs
guidance.

Paired Programming
10

Pair programming is an agile software development technique in which two
programmers work together at one work station. One types in code while the
other reviews each line of code as it is typed in. The person typing is called the
driver. The person reviewing the code is called the observer (or navigator). The
two programmers switch roles frequently.
 Some studies have found that programmers working in pairs produce shorter programs,
with better designs and fewer bugs, than programmers working alone.
 Studies have found reduction in defect rates of 15% to 50%, varying depending on
programmer experience and task complexity.

Topics to Discuss & Variants:
 Paired Programming Mechanics
 Remote pair programming
 Ping pong pair programming
 The fusing of pair and solo programming

UML / Object Modeling
11

 Unified Modeling Language (UML) is a standardized general-purpose
modeling language in the field of software engineering.

 UML includes a set of graphical notation techniques to create visual models of
software-intensive systems.

 Like Design Patters UML provides developers with a standard form of
communication that allows everyone to understand architectural patterns and
how systems work.

 By providing training on this subject we provide the structure for visual
comprehension of systems.

Miscellaneous Code Craftsmanship
12

A general section of miscellaneous code craftsmanship tutorials with distinct examples from
code in our environment. This session would be run as a best practices code review
teaching each attendee all of the following and more.
 Clean Code
 Meaningful Names
 Functions
 Comments
 Formatting
 Objects and Data Structures
 Error handling
 Boundaries
 Classes
 Systems
 Concurrency
 Code Smells and Heuristics
 About 10 others…

Code Craftsmanship Checklist

Recommended

More Related Content

What's hot (18)

Similar to Code Craftsmanship Checklist (20)

Recently uploaded (20)

Code Craftsmanship Checklist