Maintainable Code with Java Examples

I talk about a number of concepts in this course that should make your code easier to maintain.
You might want to use some of these concepts and you might want to ignore others.

But if you know what is going on, you are not developing in the dark.

In programming, unlike photography, this is not something you should do.
The course is split into seven sections.

The first section is the introduction.

In the second section I talk about close to the code concepts, like indirections, small functions and beautify code.

In the third section I talk about larger groups of concepts and how they relate to maintainability.

I present things like SOLID programming, Object Calisthenics and language speed through the code maintainability lenses.

In the fourth section I talk about how Inheritance affects maintainability.

I explain things like why Encapsulation and Modeling will help you and why you should be careful when using inheritance and polymorphism.

In the fifth section I talk about how programming patterns relate to maintainability.

I try bring attention to pattern types and I recommend using the simple ones and staying away from the complex ones.

In the sixth section I talk about ways of writing maintainable code.

I describe and recommend things like Test Driven Development, High Level First and Continuous Refactoring.

In the seventh section I talk about concepts complementary to programming that can help you write maintainable code, like Yagni, Dry, Kiss and Fop.

Here is a more in-depth list of things you will learn about in each lecture:

Small everything - The most important principle of maintainable code is to work with small units of code: small methods and small classes.

Indirection - In this lecture I talk about indirection, a very useful principle that stands at the core of maintainable code together with Small everything. From indirection we can deduce useful principles and refactoring techniques like beautify code and extract method.

Extract method and extract class - Extract method and Extract class are the most important refactoring techniques you need to know.

Beautify Code - Make code easier to read and understand using indirection.

Naming things to express intent - Names are our tool to express almost with free speech what we are doing in our code.

Less parameters is better than more parameters - I talk about how the number of parameters is important and how you can bring that number down.

Single responsibility principle extended - I talk about the most important concept in SOLID programming, SRP and how it can be extended as a concept even to row level.

One to One principle - A lot of good programming principles seem to have one thing in common: they can be represented as one to one relationships.

Low coupling High Cohesion - I talk about how it's good to keep you classes and methods decoupled but with high cohesion.

Command and query separation - You can separate your methods in two types: commands and queries. I talk about how to make this separation and what are the benefits.

Tell don't ask - Tell your objects what to do, don't ask what their state is.

The law of Demeter - Only use objects that were available when your method started.

Coding good practices - Close to the code practices that help keep your code maintainable.

Code Smells - A code smell indicates that something is wrong in your code. Some of them repeat themselves often and have names.

If and Boolean functions - "If" and "Boolean functions" deserve special attention when talking about maintainable code.

Programming languages particular features are dubious - There is something common in programming languages. Some sort of common programming language. I think this commonality is good and should be used a lot at the expense of particular language features.

SOLID programming - In this lecture I discuss SOLID programming and which principles I think are good and important and which not so much.

Objects Calisthenics - Object calisthenics are a set of strict programming principles created by Jeff Bay, that might help your code be more maintainable.

Optimization, language speed and maintainable code - I explain why language speed is not important for most projects.

Maintainability scarcity - Time is expensive. Here I explain why and a bit how to focus refactoring on the areas of the project where it will bring the most benefit.

Maintainability architecture - I am in favor of writing code, building unit tests and refactoring over upfront architecture.

Encapsulation is a friend - Objects should keep their internals to themselves.

Abstraction (modeling) is a friend - Taking entities from the real world and abstracting them into classes makes it easier for the mind to understand what is going on in code.
Composition is a friend, inheritance is not - Classes should use other classes, not inherit them, to avoid complex entangling.

Polymorphism - it's complicated - I recommend staying away from polymorphism, due to the complexity it ads, because of it's magic nature.

Data classes are a thing and they are OK - Data objects are useful just as they are, they don't need to pretend to be classical oop objects.

Know the pattern types - There are different pattern types and I think that this is important.

Use Simple patterns - It's good to know and use simple programming patterns.

Stay away from Complex patterns - Complex and hard to understand patterns are not something you want to use.

Maintainability through tests - Tests, especially unit tests, are a core pillar for writing maintainable code.

TDD - Test Driven Development is takes time and patience but is rewarding.

High Level First - I like to write code by first writing method calls to methods that don't exist yet. This way I lay out the entire high level algorithm just with method names. After that I finish up by writing the body of the methods.

Refactoring - Refactoring is an important pillar in keeping the code maintainable.

Continuous refactoring - Always refactor when going through code.

Refactor for simplicity - A special type of refactoring that I like is to refactor the code to make less complex.

Big refactoring - Care must be taken when doing big refactoring.

Complementary concepts - Concepts that are not necessary closely related to writing code.

Yagni - You ain't gonna need it.

Focus on the present (FOt6P) - Focus on the present is a good mindset when deciding what functionality to implement.

Dry - Don't repeat yourself to avoid WET - wasting everyone's time.

Kiss - Keep it simple stupid.

The 80/20 rule - 80% of effects come from 20% of causes.

Worse is better - A worse, simpler, product might be more useful than a more complex one.