The Software Craftsman Kitabından Aldığım Notlar - 4

3.Bölümün devamı :

REFACTORING

Refactoring the code before adding a new feature is a good idea when the impact on the code is significant.

Good practices and processes are good until we find better ones to replace them.

Don’t rush to call people unprofessional just because they don’t use certain practices. Ask them what practices they use instead and then compare the benefits their practices have over the practices you use.

As professionals, we need to understand that a software project is not about us and our egos. The I-know-what-I’m-doing-and-I-don’t-need-to-write-tests attitude is selfish and arrogant. Even if that were true, the project is not about you. It’s not about one or two great developers. We need to think about who is going to maintain the software when we leave. We need to think about how difficult it will be for the company to keep evolving that software. If the value we add to a project is conditional to our continuous involvement in the project, it’s not value. It’s a point of failure.

Well-crafted code is simple, small, testable, easy to understand, and most important, does the job. Code is the main source of bugs and pain. The less we write it, the better.

FOUR RULES OF SIMPLE DESIGN

“Four Rules of Simple Design,” as defined by Kent Beck:

1. Pass all tests

2. Clear, expressive, and consistent

3. Duplicates no behavior or configuration

4. Minimal methods, classes, and modules

Over the years, many people reworded these four rules (or elements). I personally prefer J. B. Rainsberger’s version:

1. Passes all tests

2. Minimizes duplication

3. Maximizes clarity

4. Has fewer elements

• Minimizes duplication

• Maximizes clarity

In order to achieve a simple design, I focus first on good names and nice abstractions that represent business concepts. Then I focus on removing duplications, which usually leads to a highly cohesive and loose-coupled code. When removing duplications, new structures emerge, which forces me again to maximize clarity, and then again to remove duplications. I stay in this cycle, working in very short iterations, until I’m done.

Combined with the knowledge of Domain-Driven Design and the SOLID principles, this approach is normally enough to achieve well-crafted code without polluting the code with loads of design and architectural patterns.

Generic code is a great thing, but it doesn’t come for free. The more generic the code is, the more complex it becomes.

Instead of always striving for generic code, write code that is specific to the problem you are trying to solve and make it generic just when you have a reason for that.

CRAFTSMANSHIP AND PRAGMATISM

Craftsmanship without pragmatism is not craftsmanship. A craftsman’s primary focus is customer satisfaction. Besides quality, time and cost are part of this satisfaction. Code cannot be considered well-crafted code if it doesn’t provide value.

Building Our Careers, One Job at a Time

Before I choose a job, I ask myself the following questions:

• What do I want for my career?

• What is the next step to achieve that?

• Is this job aligned with my career aspirations?

• How much value can I add to this company?

• What is the return on my investment?

• How long (roughly) will the duration of my investment be?

• How would this job help me to get to where I want to be as a professional?

• In this job, will I have autonomy, mastery, and purpose?

• Will I have a productive partnership with my employer, where both sides will be happy with the value they are getting out of the deal?

---

- Sandro Mancuso