Chemaclass - refactoring

Clean Craftsmanship

2022-07-11T00:00:00+00:00

The book is divided into three parts: the disciplines, the standards, and the ethics.

The 1st part is the most technical one. It guides you with TDD examples, showing how testing can help you to design your code.

The 2nd part is about productivity, quality, and courage.

The 3rd part is about how did we get here in terms of people who develop software, and our responsibility within our ethics about do no harm, integrity, and teamwork.

One of my favourite parts from the book:

Our software industry is wildly dynamic and changing; therefore, we must all be continuously aggressive learners.

How and when do you do this learning? If your employer provides you the time and space to do this kind of learning, then take as much advantage of it as you can. If your employer is not helpful, then you’ll have to learn on your own time.

Be prepared to spend several hours per month on it. Make sure you have the personal time set aside for it.

Yes, I know you have family obligations, bills to pay, planes to catch, and you’ve got a life. Okay, but you also have a profession. And professions need care and maintenance. I expect us all to be continuous aggressive learners.

Chapter 11. Courage - Continuous Aggressive Learning

Index #

Part I: The Disciplines #

Chapter 1. Craftsmanship #

Extreme Programming
Test-Driven Development
Refactoring
Simple Design
Collaborative Programming
Acceptance Tests

Chapter 2. Test-Driven Development #

Overview
The Basics

Chapter 3. Advanced TDD #

Getting Stuck
Arrange, Act, Assert
Test Doubles
Architecture

Chapter 4. Test Design #

Testing Databases
Testing GUIs
Test Patterns
Test-Specific Subclass
Humble Object
Test Design
Breaking the Correspondence

Chapter 5. Refactoring #

What Is Refactoring?
The Basic Toolkit
Extract Method
The Disciplines

Chapter 6. Simple Design #

YAGNI
Covered by Tests
Coverage
Design?
Maximize Expression
The Underlying Abstraction
Minimize Duplication
Minimize Size

Chapter 7. Collaborative Programming #

Chapter 8. Acceptance Tests #

The Discipline
The Continuous Build

Part II: The Standards #

Chapter 9. Productivity #

We Will Never Ship S**T
Inexpensive Adaptability
We Will Always Be Ready
Stable Productivity

Chapter 10. Quality #

Continuous Improvement
Fearless Competence
Extreme Quality
We Will Not Dump on QA
QA Will Find Nothing
Test Automation
Automated Testing and User Interfaces
Testing the User Interface

Chapter 11. Courage #

We Cover for Each Other
Honest Estimates
You Must Say NO
Continuous Aggressive Learning
Mentoring

Part III: The Ethics #

The First Programmer
Seventy-Five Years
Nerds and Saviors
Role Models and Villains
We Rule the World
Catastrophes
The Oath

Chapter 12. Harm #

First, Do No Harm
Best Work
Repeatable Proof

Chapter 13. Integrity #

Small Cycles
Relentless Improvement
Maintain High Productivity

Chapter 14. Teamwork #

Work as a Team
Estimate Honestly and Fairly
Respect
Never Stop Learning

I found this chat in YouTube where Uncle Bob talks about most of the topics form his book Clean Craftsmanship.

Listen out for:
* Quote & Intro - [00:00:00]
* Career Journey - [00:07:29]
* Clean Craftsmanship - [00:10:53]
* Programmer as a Profession - [00:15:31]
* Craftsmanship - [00:18:45]
* Disciplines - [00:22:45]
* Disciplines: Test-Driven Development - [00:28:49]
* Disciplines: Refactoring - [00:34:31]
* Code Coverage - [00:39:02]
* Standard: Never Ship S**t - [00:42:35]
* Standard: Always Be Ready - [00:47:15]
* Ethics: Do No Harm - [00:50:00]
* Ethics: Estimate Honestly - [00:53:56]
* 2 Tech Lead Wisdom - [00:57:50]

London vs Chicago

2021-11-20T00:00:00+00:00

There are two known schools in TDD: the mockist school (aka Outside-in) and the classicist school (aka Inside-out).

Why London and Chicago? #

Two companies, one from London and another from Chicago, claimed to do TDD, but they were focused on different aspects. The London company was building software from outside-in, while the Chicago company from inside-out. Let’s see them in more detail.

Outside-in: London School #

It provides a behavior-driven approach to TDD. Starting from the outside of the application and working inwards to lower layers. For example, starting from the API/Controllers down to the application or domain layers.

PROS #

Behavioral Focused: this requires a lot of test doubles because you will test a lot of abstractions that don’t exist yet as you are creating a high level of logic first. You aren’t going to write dead-code but it will be easy to create tests highly coupled to the logic and therefore making refactoring a difficult task.
Command-Query separation: is a discipline for managing side effects. Either you perform an action (command) or you ask for a value (query).

CONS #

Fragile Tests: it tends to create tests that break easily because they are usually too coupled to the production code.
Difficult Refactoring: for the same reason as “Fragile Tests”, having tests coupled to production code make continuous refactoring very difficult and time-consuming.

Inside-out: Chicago School #

It’s an informal, exploratory, state-based approach of TDD. Starting from the inside of the application (usually the domain) and working out towards the APIs.

PROS #

Strong Safety Net: it tends to produce tests that are decoupled from the implementation. Enabling you to adopt a more experimental style of changing software without fear of breaking it. This is desired for continuous refactoring.
High Cohesion: as tests become more general, the production code becomes more specific. This promotes high cohesion, and with high cohesion comes loose coupling. Something that promotes high code quality: extensibility, maintainability, and testability.
Minimizes Test Doubles: building from the inside out requires fewer test doubles since you are building on top of the previously written tests. This helps to develop less fragile tests.

CONS #

YAGNI: it’s often over-engineering solutions, with code that is not really needed (or even used!) in the end.

London and Chicago work better together #

It’s not about choosing one over the other. It’s about understanding your context and driving optimization towards those qualities that need to be optimized. London and Chicago each have their pros and cons. The best approach to TDD is an integrated adoption of these two schools.

References #

Test-Driven (Development)

2021-08-01T00:00:00+00:00

The complexity here is not about writing tests itself, but the habits that we have to change to create software that is easy to be tested.

The root of the problem #

Without (a solid) experience in testing, developers can have a hard time while trying to apply testing in general as part of their daily job. It’s not simply because of the topic’s complexity, but because they are used to writing code that is hard to test.

Writing tests for already working software (mainly when it was done without considering testing at all) translates as something boring, next to useless, usually accompanied by a lack of motivation, blaming the wrong subject in this context: “the tests itself are reducing my speed”.

In a domain context, if a piece of software logic is hard to be tested, the problem is not the test, but the code which wasn’t well written.

There are already hundreds of tutorials, books, and documentation about testing, but I can share my experience and how I do apply this great (and mandatory) philosophy in my daily work.

Test-Driven is based on this simple rule #

Instead of: design code -> develop code -> write tests.

It’s about: write failing automated test -> run failing test -> develop code to make test pass -> run test -> repeat.

The idea of driving your code by testing can be understood depending on the abstraction level of what you’re writing at the moment. You don’t want to create a wrong coupling between the tests and the code being tested. You want to test the behavior of your logic.

TDD is based on a loop of baby steps that helps you find patterns and guide your software design every little iteration with constant refactorings. It’s the best choice if you want to ensure the expected behavior of all possible paths of your logic.

The beauty of this is that you don’t need to know the full algorithm from the very beginning. Instead, you are discovering how your logic should be by expressing the desired implementation, step by step, on automated tests.

Considering writing tests for your software at the same time you’re writing it, will irremediably force you to write better software. Because you want to write software which has to be easy to be tested, and therefore it will end up with higher quality.

I already wrote another post about the relation between software quality and testing: The Art of Testing: where design meets quality.

Improve your Test-Driven skills #

The best way to learn Test-Driven is doing software katas. Try them alone and with others. Both are equally important.

Alone: to challenge your inner self without any distraction but yourself.
With others: pair-programming is essential in our job. Katas are the best tools to train our communication skills and learn together from each other.

What’s a Code Kata? #

Software developers don’t practice enough. Most of our learning takes place on the job, which means that most of our mistakes get made there as well.

Other creative professions practice: musicians play technical pieces, poets constantly rewrite works. In karate, most of a student’s time is spent learning and refining basic moves. These are katas.

What is the goal of a kata? What should we have at the end? #

Katas exist to help developers get the same benefits as practicing in any other profession. There are simple, artificial exercises that let you experiment and learn without the pressure of a production environment.

There are no right or wrong answers in any software kata: the benefit comes from the process, not from the result.

Tips #

Once you have resolved a kata, try it again in a few weeks or months.
Try to explore new solutions. Be creative in the process and do not rush.
When doing them in groups, they are not a competition to see who will accomplish more of the exercise.
The focus should be on the process, never on the result.
The true valuable outcome of any kata is the learnings that you (and your team) will get after talking about it and sharing your experiences.

You can find a lot of katas on the Internet. For example:

TDD is more as a workflow than a design #

“TDD is a design tool.” That’s what Sandro has said for years. But not anymore. After working with different teams and in different organisations, and also carefully inspecting how he works, Sandro changed his mind about the role of TDD in software design.

TDD in a nutshell; it’s about the rhythm.

Specify what you want.
Make it work.
Make it better.

Kent Beck #

1. Change the code as usual
2. Write a test that only passes after the change
3. Revert to before 1
4. Type the test again (copy/paste is cheating & invalidates the warranty of the exercise)
5. Make it compile by changing the code
6. See it fail
7. Change the code to make it pass
— [Kent Beck](/readings/extreme-programming-explained/) 🌻 (@KentBeck) July 30, 2021

Images original by Emmanuel Valverde Ramos.

Never Use array_merge in a Loop

2020-11-10T00:00:00+00:00

Using array_merge inside a loop is a performance killer. The spread operator will help you to improve this by flatting the array.

Flattening a one-level array #

I have seen people using the array_merge function in a loop like:

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = [];
foreach($lists as $list) {
 $merged = array_merge($merged, $list);
}
// $merged === [1, 2, 3, 4, 5, 6];

This is a very bad practice because it’s a (memory) performance killer! Instead, you should use the spread operator (in PHP since 5.6!):

<?php
$lists = [
 [1, 2],
 [3, 4],
 [5, 6],
];
$merged = array_merge(...$lists);
// === [1, 2, 3, 4, 5, 6];

Unpacking an assoc-array #

What if you had an assoc-array instead like this one?

<?php
$lists = [
 'key-1' => [1, 2],
 'key-2' => [3, 4],
 'key-3' => [5, 6],
];

In that case, you will need to unpack its values:

<?php
$merged = array_merge(...array_values($lists));
// === [1, 2, 3, 4, 5, 6];

In Functional Programming, this is known as flatting a list. No loops & no more performance problem.

Flatting a multilevel array #

What if you wanted to flat a multilevel array like this one?

<?php
$lists = [[1], 2, [[3, 4], 5], [[[]]], [[[6]]], 7, 8, []];

Or like this one, even with key-values?

<?php
$lists = [
 'key-1' => [
 1,
 [2],
 'key-2' => [
 3,
 [
 'key-3' => [4, 5],
 ],
 ],
 ],
 6,
 'key-4' => [7, 8],
];

In these cases, you might want to use the internal standard library:

<?php
$merged = iterator_to_array(
 new RecursiveIteratorIterator(
 new RecursiveArrayIterator($lists)
 ),
 $use_keys = false
);
// $merged === [1, 2, 3, 4, 5, 6, 7, 8];

Which flattening approach to reach for #

Usually, being aware of how to flat a “2 level” array might be sufficient:

<?php
$flattenList = array_merge(...array_values($lists));

Otherwise, the internal standard library will help you deal with it.

References #

Testing Effectively Legacy Code

2020-08-17T00:00:00+00:00

These tests are also known as Characterization tests.

A characterization test describes the actual behavior of an existing piece of software, and therefore protects existing behavior of legacy code against unintended changes via automated testing. This term was coined by Michael Feathers.

They enable and provide a safety net for extending and refactoring code that does not have adequate tests. A test can be written that asserts that the output of the legacy code matches the observed result for the given inputs.

How to start? #

These are my learnings one year after reading Working Effectively with Legacy Code and applying it to the different projects I’ve been working on since then.

1. What do you want to test? #

Find out the assertions. Create a test file for your class, and a testing method for the function that you want to test. Hint:

If you have the following method applySomeLogic(): ReturnType,
the test you could write is test_apply_some_logic(): void.

final class MyBusinessLogic
{
 private DependencyInterface dependencyInterface;
 private ConcreteDependency concrete;

 public function __construct(
 DependencyInterface dependencyInterface,
 ConcreteDependency concrete
 ) {
 this.dependencyInterface = dependencyInterface;
 this.concrete = concrete;
 }

 public function applySomeLogic(Input input): ReturnType
 {
 // black box responsible to create a ReturnType
 // based on the given Input
 return returnType;
 }
}

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 // I want to assert that "applying some logic"
 // from MyBusinessLogic with the given Input
 // I will receive a concrete ReturnType with a 
 // certain value as its property. Something like:
 
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

2. Instantiate the concrete/final class that you want to test. #

Do not mock your concrete classes. Especially your business domain. Mock only interfaces. Otherwise, you can be hiding bugs unintentionally (with green/passing tests!). Treat your business domain classes as final.

Either mock the interface or instantiate an anonymous class if you want to create a Stub:

Stubs provide answers to calls made during the test, usually not responding to anything outside what’s programmed in for the test.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(/* ... */)
 );
 // OR
 myBusinessLogic = new MyBusinessLogic(
 new FakeDependency(),
 new ConcreteDependency(/* ... */)
 );
 // ...
 }
}

Where FakeDependency is a concrete implementation of DependencyInterface with already “fake data/implementation” that it’s useful only for testing purposes.

3. Call the method from that class providing the desired input. #

The output will be determined by the initial state of the business logic class that we want to test PLUS the input arguments that we are using.

input = new Input(/* ... */);
returnType = myBusinessLogic.applySomeLogic(input);

4. Assert the output with the expected value. #

From step-1 you need to know what you want. Apply the assertion(s) now.

final class MyBusinessLogicTest extends TestCase
{
 public function test_apply_some_logic(): void
 {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface::class),
 new ConcreteDependency(/* ... */)
 );

 input = new Input(/* ... */);
 returnType = myBusinessLogic.applySomeLogic(input);
 assertEquals('expected', returnType.getProperty());
 }
}

5. You might want to assert different expected values. #

You can easily provide different arguments to your business logic either via the logic construction or different given arguments. To do so, use the @dataProvider annotation. The “dataProvider” method must be public and return any iterable.

final class MyBusinessLogicTest extends TestCase
{
 /** @dataProvider providerApplySomeLogic */
 public function test_apply_some_logic(
 array concreteMapping,
 string argInput,
 string expectedValue
 ): void {
 myBusinessLogic = new MyBusinessLogic(
 this.createMock(DependencyInterface.class),
 new ConcreteDependency(concreteMapping),
 /* ... */
 );

 input = new Input(argInput, /* ... */);

 actual = myBusinessLogic.applySomeLogic(input);
 assertEquals($expectedValue, actual.getProperty());
 }

 public function providerApplySomeLogic(): Generator
 {
 yield [
 'concreteMapping' => ['key' => 'value'],
 'argInput' => 'something',
 'expectedValue' => 'expected-value-A',
 ];

 yield [
 'concreteMapping' => ['key2' => 'value2'],
 'argInput' => 'something-else',
 'expectedValue' => 'expected-value-B',
 ];
 }
}

Lastly: clean what you did. #

Yes, clean the tests. They deserve to be as clean as your production code. Otherwise, they will rot as time passes by and remain dirty for your colleagues and your future self!

For example, you can apply extract method refactoring to move out the implementation details (of the creation of the different objects) and keep the same abstraction level while reading the test code.

myBusinessLogic = this.createBusinessLogic(concreteMapping);
input = this.createInput(argInput);
actual = myBusinessLogic.applySomeLogic(input);
assertEquals(expectedValue, actual.getProperty());

Of course, everything depends on the context. Does it really make sense to extract into a private method the createBusinessLogic() or even createInput()? Well, that’s up to you. It depends on the number of lines and, most importantly, the abstraction level that belongs to that context.

Just remember: keep your methods small.

Now you can refactor the production code that you covered with tests without that fear of breaking it.

All together #

Legacy Code is code without tests #

Of course, there is way more to learn about testing and working with legacy code. In fact, especially when dealing with legacy code, you will encounter situations where the code is coupled somehow that you might want to mock your concrete classes because there is no interface (yet) for it.

This book presents to you a lot of techniques about when, why, where, and how you can apply these changes.

When working with code you need feedback. Automated feedback is the best. Thus, this is the first thing you need to do: write the tests.

First, add tests, then do your changes. #

Change as little code as possible to get tests in place with the recipe: #

Identify “change points” to break your code dependencies.
Break dependencies.
Write the tests.
Make your changes.
Refactor.

Advanced Web Application Architecture

2020-08-16T00:00:00+00:00

This book helps you get your web applications back in shape. It contains many techniques for decoupling from infrastructure (like the framework or the database).

“The best guide that brings your coding and architecture skills a level up. All the modern PHP features combined with the elegance of a well-designed modular design.”

In Part 1 we unlock a collection of design patterns which help you establish a clean separation between core and infrastructure code. Part 2 shows how these design patterns resonate at a higher level with architectural concepts like layers, ports and adapters (a.k.a. Hexagonal architecture). The book finishes with a discussion of testing strategies and design trade-offs.

What you’ll learn #

Separating mixed code into core and infrastructure code by refactoring into patterns.
Dividing your code into layers, and making a clear distinction between an application’s ports and adapters.
Testing decoupled applications.

Buy the book: https://leanpub.com/web-application-architecture

Design patterns for modernizing legacy code bases #

The Art of Refactoring

2020-06-28T00:00:00+00:00

If you see something, in the scope of your current task, that can be easily improved, improve it. And if you have any questions about it, ask.

What is refactoring? #

Refactoring means improving your code. It can go from making a variable name more readable, extract some lines of code into a private method, or separate the responsibilities of a class into subclasses, for example.

Refactoring is the action of showing that you care about what you do as a professional. It can be a controversial topic; it is indeed one of the major controversial topics since a long time ago. But we shouldn’t stop trying our best in order to improve the quality of the system just because of that controversiality.

When and how should we refactor? #

Always. In the scope of your current task unless it is an already planned task, something like “architecture refactoring” or similar, where the scope of the task is actually to do refactoring.

Refactoring should be part of our daily job, not a separate task by default.

We do not need to ask permission to refactor. Or do we ask our managers for permission to do our best job?

In order to do proper refactoring, the intention of such refactoring needs to be clear. What is intended to achieve and how? Pair programming (or even pair thinking!) certainly helps in this topic because it syncs two brains on the same topic and that encourages team building and a better understanding of them.

Applying refactoring in a collaborative way, in a “bidirectional channel”, is fundamental when working within a team. Refactoring shouldn’t be a taboo topic, on the contrary: it will be helpful in order to unify the goals and the direction of the team code quality.

Some personal advice about the “how” #

Continuous improvement is what we’re looking for within this topic, but…

If you realize your changes are generating more noise than help, stop immediately and think again if your changes are worth it in the current system status.

Maybe it’s not the right moment for that refactoring.

Maybe you are polluting your current diff with out-scoped changes.

Or, maybe, your refactoring idea is too big to be applied in your current task. In such a case, a follow-up task (in order to apply the refactoring) would be a better idea.

If you see that refactoring is perhaps needed even before starting your current task, do the refactoring first.

We usually refactor in order to increase our productivity, making the code more readable and therefore easier to understand.

Testing #

Be aware that you should have a pretty good suite of tests covering the logic that you might have changed. Without tests, refactoring can be really risky. Usually, the easier something is to be tested, the easier it is to be replaced or removed.

You can read more about how testing is related to quality here.

Why should we do it? #

Wouldn’t you want to have a better system as time goes by?

Software isn’t like wine: it doesn’t get better as time passes by. Therefore, if you want to have a better system you must work for it.

Working Effectively with Legacy Code

2019-07-01T00:00:00+00:00

What is legacy code? #

Legacy code is simply code without tests.

Benefits of tests #

Behavior is central to understanding the benefits of testing:

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

How to get tests in place in legacy codebases #

When we change code, we should have tests in place. To put the tests in place, we often have to change code.

The suggested approach:

Identify change points.
Find test points.
Break dependencies.
Write tests.
Make changes and refactor.

Another useful term is a “seam.” A seam, in this context, is “a place where you can alter behavior in your program without editing in that place”. The analogy is to a seam in clothing, the place where two parts are stitched together. In software, these places are generally places where there are well-defined interfaces. This can be leveraged to change the implementation using techniques such as dependency injection or mocking interfaces in the case of writing tests.

The Pragmatic Programmer

2016-10-01T00:00:00+00:00

Takeaways #

Don’t Repeat Yourself.
Mindset is as important as knowledge.
Good code is easier to change than bad design.
Choose great tools and become fluent with them.

Don’t Repeat Yourself (DRY) #

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.

Mindset is as important as knowledge #

Some important aspects of this mindset include:

Taking responsibility for your work by not making excuses or passing blame when things go wrong.
Writing software that’s good enough. This means not wasting time on things that are better than they need to be to make the product successful.
Not ignoring technical debt. The authors use the analogy of broken windows:

Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead.

Clean Code

2016-05-01T00:00:00+00:00

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Summary #

Chapter 1: What Is Clean Code? #

The code can be measured with either “good” or “bad” in the code review or by how many minutes it takes you to talk about it.
A clean code should be elegant, efficient, readable, simple, without duplications, and well-written.
You should add value to the business with your code.
Clean code offers quality and understanding when we open the source file.
It is necessary that your code is clean and readable for anyone to find and easily understand. Avoid wasting others’ time.

Chapter 2: Meaningful Names #

Names of the classes, variables, and methods must be meaningful and clearly indicate what a method does or what an attribute is.
Create pronounceable names to facilitate communication.
Avoid acronyms and avoid confusing names, which may bring anyone who reads the code to the wrong conclusions.
Use names that reflect the system domain, the context, and the problems that must be solved.

Chapter 3: Functions #

Methods should be easy to read and understand.
Methods should convey its intention.
Methods should be small.
They must have up to 20 lines.
Methods should only do one thing.
You should use names with words that say what it really does.
The optimal number of parameters of a method is zero, after one and two.
Three should be avoided, but if you think it should be used, have a justification.
Boolean type as a parameter already states that it does more than one thing.
Avoid duplication.

Chapter 4: Comments #

One of the common reasons for comments is because the code is bad.
If you’re thinking about writing a comment, then the code should be refactored.
Comments do not save a bad code.
Try to explain what the code causes happening.
Comments can be useful when placed in certain places.
Don’t explain your code with comments. Use informative vars/method names.
Comments can be used to express the importance of certain points.
Do not write comments with redundant, useless, or false information.
They shouldn’t be used to indicate who changed or why, use versioning.
Don’t comment code that will not be used. Remove it instead.

Chapter 5: Formatting #

Formatting should indicate things of importance since it is a developer of communication form.
A messy code is hard to read.
The readability of the code will take effect on all the changes that will be made.
Smaller classes are easier to understand.
Set a limit of characters per line of code. For example 120.
Try to keep more next related concepts vertically to create a code stream.
Use spaces between operators, parameters, and commas.

Chapter 6: Objects and Data Structure #

Follow the Law of Demeter:
- Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.
- Each unit should only talk to its friends; don’t talk to strangers.
- Only talk to your immediate friends.
Do not make dumb objects.
Objects hide the data abstraction and expose methods that operate the data.
Data structures expose your data and do not have significant methods.

Chapter 7: Error Handling #

Error handling should be planned carefully by all programmers.
When wrong things occur, we have to get it to do the right things.
Give preference to launching an exception than treating it just to hide.
Create messages with information about the error.
Mention that it failed. Where was this failure? If possible, mention why it failed.
Look at separate business rules for errors and error handling.
Avoid returning a NULL in methods, preferably to return an empty object.
Avoid passing NULL to the methods; this can generate NullPointerExceptions.

Chapter 8: Boundary #

In third-party code, to avoid passing objects, APIs look forward in order to keep things in the same class.
Perform tests on the API’s third party.
Study the documentation and test the third API before you start using it.
Check well the features you will use.

Chapter 9: Unit Tests #

Make sure each piece of code is doing what you expect it to do.
Follow the TDDs law:
- Don’t create code before you have a failing test.
- Don’t create more tests than necessary to fail.
- You cannot write more code than enough to pass the test that is failing.
Keep your test clean.
The tests must undergo changes in the same way that the code.
The dirtier the code, the more difficult test will be to maintain.
Use the F.I.R.S.T rule for testing:
- The test is fast-running.
- The tests are independent of others.
- The test is repeatable in various environments.
- The test is self-validating.
- The test is timely.
The test is as important as the production code.

Chapter 10: Classes #

By default, classes should start with the variables:
- Static and constants public.
- Static and variable private.
- Instances and variables privates.
- Soon after comes the functions.
- The class name should represent its responsibility.
The class must have only one responsibility: one reason to change.
You should try to make a brief description of the class.
The methods should be small and one responsibility.

This interview is based on Uncle Bob’s book “Clean Code”. They cover some existing guides that can help you become a better programmer and explore how books and current trends are shaping the software landscape.