Modern Development: Uncle Bob

Showing posts with label Uncle Bob. Show all posts

Tuesday, August 23, 2011

The SOLID Principles :: BlackWasp Software Development

The SOLID Principles
This is the first article in a series of six that describe the SOLID principles of object-oriented design and programming. The SOLID principles provide five guidelines that, when followed, can dramatically enhance the maintainability of software.

Single Responsibility Principle
The second article in the SOLID Principles series describes the Single Responsibility Principle (SRP). The SRP states that each class or similar unit of code should have one responsibility only and, therefore, only one reason to change.

Open / Closed Principle
The third article in the SOLID Principles series describes the Open / Closed Principle (OCP). The OCP states that all classes and similar units of source code should be open for extension but closed for modification.

Liskov Substitution Principle
The fourth article in the SOLID Principles series describes the Liskov Substitution Principle (LSP). The LSP specifies that functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.

Interface Segregation Principle
The fifth article in the SOLID Principles series describes the Interface Segregation Principle (ISP). The ISP specifies that clients should not be forced to depend upon interfaces that they do not use. Instead, those interfaces should be minimised.

Dependency Inversion Principle
The sixth and final article in the SOLID Principles series describes the Dependency Inversion Principle (DIP). The DIP states that high level modules should not depend upon low level modules and that abstractions should not depend upon details.

Wednesday, April 6, 2011

Clean Code - A Handbook of Agile Software Craftsmanship

Clean Code - Slashdot
I attended Bob Martin's keynote speech and design patterns workshop at the 2010 Better Software / Agile conference in Las Vegas. His views on professionalism, software craftsmanship and clean code have definitely given me a new outlook on what it means to be a professional software developer. After reading Cory Foy's review on Slashdot I recently purchased this book and am looking forward to working through it.

As developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. Sometimes it's just one-off scripts we never have to see again. Sometimes we stare at something that, for the life of us, we can't understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). But there is a time when you find code that is a joy to use, to read and to understand. Clean Code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. But does it really help?

I had the pleasure of attending Bob Martin (Uncle Bob)'s sessions at several agile software conferences over the past several years. In them, Bob has a unique way of showing us the value of clean code. This book is no different. There is a warning in the introduction that this is going to be hard work — this isn't a "feel good" kind of book, but one where we slog through crappy code to understand how to make it better. The authors also point out that this is their view of what clean code is all about — and fully acknowledge that readers may "violently disagree" with some of the concepts.

Tuesday, April 5, 2011

Uncle Bob - The Transformation Priority Premise

The Transformation Priority Premise - Uncle Bob's Blog

This blog poses a rather radical premise. It suggests that Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing it’s behavior. Transformations are simple operations that change the behavior of code. Transformations can be used as the sole means for passing the currently failing test in the red/green/refactor cycle. Transformations have a priority, or a preferred ordering, which if maintained, by the ordering of the tests, will prevent impasses, or long outages in the red/green/refactor cycle.
“As the tests get more specific, the code gets more generic.”
Recently this mantra has taken on a new meaning for me.

Uncle Bob - The Clean Coder: Software Craftsmanship: What it's all about?

The Clean Coder: Software Craftsmanship: What it's all about?

Why is there a software craftsmanship movement? What motivated it? What drives it now? One thing; and one thing only.

We are tired of writing crap.

That's it. The fat lady sang. Good nite Gracy. Over and out.
We're tired of writing crap. We are tired of embarrassing ourselves and our employers by delivering lousy software. We have had enough of telling our customers to reboot at midnight. We don't want bug lists that are a thousand pages long. We don't want code that grows more tangled and corrupt with every passing day. We're tired of doing a bad job. We want to start doing a good job.
That's ... what ... this ... is ... about. Nothing else.

Uncle Bob - The Clean Coder: Bringing Balance to the Force

The Clean Coder: Bringing Balance to the Force

I read Martin Fowler's contribution to the craftsmanship thread with interest. He spoke of the so-called "crevasse" between developers and customers. He reiterated Dan North's fear that the craftsmanship movement could widen this crevasse.
We are programmers. We need to talk about programming from time to time. We need time and space to focus on our primary discipline: programming. That discussion, and that focus, is a very positive thing. It means we care about what we do. But have we gone too far? Are we too technical? Is the Software Craftsmanship movement a movement only about techical practice and details? Have we forgotten the customer?