4D Training & Consultancy

Software Development

Clean Code, Refactoring and Technical Debt

Written for developers maintaining code they did not write, this course turns clean-code principles into repeatable refactoring moves. Participants rename for intent, extract functions and classes, invert dependencies, remove nested conditionals, and learn to size and negotiate technical debt.

3 daysIn-house, online, or customized deliveryCorporate teams and professional groupsLevel: Foundation to Intermediate

Overview

Practical learning for workplace transfer.

Teams rarely decide to write unmaintainable code; they inherit it one urgent fix at a time until every change touches five files and every estimate carries a hidden risk premium. This course starts from that reality. Participants work on code that is already tangled, characterize it with tests before touching behaviour, and apply refactoring in small verified steps rather than rewrites. The second half moves the conversation upstream: how to measure debt in terms of change cost and defect rate, and how to present a remediation plan that a product owner will actually approve.

Prerequisites

At least one year writing software in any object-oriented or multi-paradigm language. Examples are shown in language-neutral form and adapted to the team's stack.

Objectives

  • Identify the code smells that reliably predict defects and rising change cost.
  • Rename variables, functions, and types so intent is readable without comments.
  • Extract functions, classes, and modules from long procedures without changing behaviour.
  • Replace nested conditionals with guard clauses, polymorphism, and lookup structures.
  • Invert dependencies so business logic can be tested without infrastructure.
  • Quantify technical debt and present a prioritized remediation plan to stakeholders.

Target audience

  • Developers maintaining and extending existing production code
  • Technical leads responsible for code quality standards
  • Code reviewers who need shared criteria beyond personal preference
  • Engineers working on legacy systems with little test coverage
  • Engineering managers planning refactoring alongside feature work
  • Product owners and delivery managers deciding which debt to fund

Program outline

A clear structure for the learning journey.

Program outline

Outline points are grouped in one designed block instead of being treated as separate module cards.

Module 1: Reading Code and Naming for Intent

What makes code expensive to read: hidden state, vague names, and mixed levels

Renaming as the cheapest and safest refactoring move

Comments that compensate for unclear code versus comments that add context

Building a consistent vocabulary across a codebase and its domain

Module 2: Functions, Responsibilities, and Structure

Extracting functions from long procedures without changing behaviour

Single responsibility applied to real modules rather than textbook classes

Parameter lists, boolean flags, and the hidden coupling they create

Moving behaviour to the data it operates on

Module 3: Removing Conditionals and Managing Complexity

Guard clauses, early returns, and flattening nested branches

Replacing type switches with polymorphism or lookup tables

Null handling, optional values, and defensive code that hides bugs

Cyclomatic complexity as a signal rather than a target

Module 4: Dependencies, Boundaries, and Testability

Dependency inversion so business rules do not import infrastructure

Creating seams for testing legacy code never designed for tests

Characterization tests before changing untested behaviour

Separating pure logic from I/O, time, and configuration

Module 5: Safe Refactoring at Scale

Small verified steps versus rewrites: choosing on the basis of risk

Refactoring under version control with reviewable commits

Strangler pattern for replacing a module while it stays in production

Automated refactoring tools, linters, and their practical limits

Module 6: Measuring and Negotiating Technical Debt

Debt inventory: hotspots, churn, defect density, and change lead time

Pricing remediation in delivery terms rather than engineering preference

Deciding what to fix, what to isolate, and what to leave alone

Building a debt budget into the team's normal delivery plan

Materials provided

  • Course workbook, annotated code samples, and reference notes
  • Hands-on lab environment and starter repositories
  • Exercises, checklists, and reusable code templates
  • 4D Certificate of Completion
  • Post-course technical guidance

Training Options

Programs can be delivered in-house, online, or in a blended format depending on your team's schedule, location, and learning objectives. When an external certificate or exam is included, certification rules and fees remain under the relevant awarding body's policies, while 4D provides the training and preparation support.

Why choose 4D

4D teaches this course on a module from your own codebase, chosen with your technical lead before day one. Participants refactor code they will maintain next month, and the closing session produces a ranked debt register with change-cost estimates that delivery and product leads can use in real planning.

Speak to 4D

Plan the right training or consultancy path for your team.

Share a few details and 4D will help route your inquiry toward corporate training, consultancy, assessment, Phoenix-enabled support, or a tailored program.