I’ve added some convenient links to some of my favorite software development and business books in my aStore (amazon affiliate link). I’ve found these books to be extremely useful in my endeavors and I hope that you also get value from them. Let me know if you like any of them or have other suggestions. If you decide to purchase anything via the links, it is much appreciated. Thank you.
Today I am continuing a series of posts in which I will be reviewing some of the books which are related to the development of quality software. They may be specific to a certain technology or a software development methodology.
Software Craftsmanship: The New Imperative
Some of the topics covered include:
The most important aspect of the book is the questioning of the popular Software Engineering approach to development and how Software Craftsmanship differs. It all boils down to valuing the people over process.
This book appeals to me so strongly because it reflects the reality of my own experience. The highest quality software (maintainable, bug free, simple design, and providing the most value to the user) I have seen developed has always been done by small teams with strong craftsmen leadership. I think Pete also does a good job of emphasizing how important it is to create the proper environment for fostering the craft of software development.
Do you have a copy of Software Craftsmanship: The New Imperative
Refactoring is the process of changing software such that it does not alter the functional behavior of the code while improving the internal structure. The first key point is that code which is already written is being improved. The second key point is that the behavior of the software is not being altered. This is not a process for fixing bugs. I’ve previously discussed motivations for refactoring in Why Refactor.
Below are 5 refactorings that I frequently use in practice:
One of the most common refactorings I use. It involves taking a section of code and putting it into a method whose name explains the purpose of the method. This has two advantages for me. First, it breaks up longer methods into shorter, clearer methods to read. Second, it is useful for applying the DRY principle when you have the same code repeatedly in a class or multiple classes. You may need to determine how to make code sections look exactly alike so that this can be done. For example, passing in nulls to the method in certain classes, but not in others. I believe this is an example of Parameterize Method
This is the process of changing a method name such that the name is more informative by clearly showing the purpose of the method. I often perform this refactoring when introducing another new method to the same class which is similarly named.
Another common refactoring for me. I use this when I want better cohesion in my classes. This leads to simpler designs and better understanding of the responsibilities.
I introduce a new data object (with getters and setters) when I have a group of parameters that are related and frequently accessed together. This then may lead to use of Move Method if there is also associated behavior with these parameters.
This is one that I wish I used more often. I think the best examples I have seen are to introduce a boolean for a complex expression in an if statement. By using a name that adds clarity, reading the if statement can be improved substantially. For super complex conditional logic expressions you can reuse this repeatedly to simplify the code. It can really make code maintenance much simpler in the future.
Agile methodologies make refactoring an enjoyable process. With the principles of test-first design and simple design, refactoring becomes a complementary exercise. It makes it easier to keep the design simple and the unit tests provide the confidence needed to make frequent changes to the code during refactoring sessions. Perform your favorite refactoring and run the tests to be sure no functional behavior was broken.
What are your favorite refactorings? For more insight into refactoring, I highly recommend Refactoring: Improving the Design of Existing Code
Was discussing this today. Refactoring is the process of modifying code without changing the external functionality of the code. Check out Refactoring: Improving the Design of Existing Code (The Addison-Wesley Object Technology Series)
For the principles exemplifying 3, 4, 7 & 8 see Uncle Bob’s Principles of OOD. All of the above (except # 2) can be thought of as reducing complexity. And it is a lot easier to be successful at #2 if you can reduce complexity.
Just wanted to point out a Google group that has gotten really active over the last few months. It is called Software Craftsmanship and as of right now is over 1000 members. I believe it was originally started by a group from 8th Light who meet monthly in the Chicago area.
The group has pages on a Software Craftsmanship Manifesto and Charter. Give it a look and let me know what you think.
If you are already a fan or have any interest, I welcome you to check out my latest site David Patton Photography. For the next few months I will be posting some of my best images each day as well as discussing equipment, techniques and other talented photographers on the site. I hope you find it entertaining and educational, so be sure to subscribe there to stay updated on the latest posts.
Recent Comments