Blog posts

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

Read More

The Natural Order of Refactoring Under the Microscope Part 1

Refactoring is an age-old problem—perhaps not the best word given the relatively short existence of software engineering as a discipline. Everyone knows refactoring should be done, but nobody seems to have the time for it.

Read More

Clean Code

The Importance of Clean Code

There are ongoing philosophical discussions on whether clean code matters and if it is worth investing time to read it. I won’t engage directly in this debate. Instead, a small example should suffice:

Read More

20/80 Rule Reloaded

The 20/80 Rule Reloaded

A short thought occurred to me.

Read More

What Name for This Method?

What Name for This Method?

public class OptionsAwareObject {  
    private Options options;  
      
    public void updateOptions(String fontName, int fontSize) {  
       options.setFontName(fontName);  
       options.setFontSize(fontSize);  
    }  
}  
   
class Options {  
    private int foregroundColor;  
    private int backgroundColor;  
    private String fontName;  
    private int fontSize;  
    // ...
}

Is updateOptions a good name for this method? Of course not! updateOptions is a general name that suggests a comprehensive update of options. Meanwhile, we are only updating font-related information. The responsibility of the method is thus the change of font-related options. A better name would be:

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More

Call for Code Samples

Call for Code Samples

I would gladly present the idea of the natural order of refactoring using an example code. Unfortunately, for obvious reasons, I cannot use our clients’ production code, and I do not have the time to prepare an example for this purpose. However, perhaps someone would be willing to allocate their piece of code, a project that doesn’t have too many (or any) restrictions on public publication.

Read More

The Natural Order of Refactoring - A Conceptual Sketch

The Natural Order of Refactoring

In software development, refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. This process, often visualized in a conceptual sketch, can help developers understand the natural flow and order in which refactoring should occur.

Read More

Young Manager/Team Leader! Get a Grip!

History tends to repeat itself, and this is a common tale among young managers and team leaders. A recurring, tragic mistake is the commitment to unrealistic deadlines.

Read More

A Few New Concepts - Architectonic Mantra, Design Retrospective, Shared Context, Natural Order of Refactoring

Recently, several named concepts have evolved in my mind, or maybe I just understood them well. Here are a few notes that I consider an alpha draft ;-)

Read More
Categories
Tags