With all the discussions of software craftsmanship and SOLID principles lately, I’d like to list the guidelines (not absolute rules!) I find most useful. These are listed in order of importance, highest to lowest.
Key Principles and Practices of Software Development
- Never stop learning. Strive for continuous improvement everywhere. Be passionate about your profession.
- Source control. Unless you like writing novels in the sand. Check in frequently (but compile and test first). Learn to use branching effectively.
- DRY (Don’t Repeat Yourself). Remove duplication every chance you get.
- OOP. Encapsulate. Resist the lure of procedural code. Favor composition over inheritance. Also be aware of alternatives, such as functional programming.
- TDD (Test-driven development/design). Automated unit testing of classes in isolation is the most useful practice I have learned in the last ten years. Many other practices build on this. Test-first is a major aid to designing usable APIs (you’re eating your own dog food). TDD requires training and practice, but it is a skill worth acquiring.
- Refactoring. Keep improving code quality. Requires tests to do properly. Make one small change at a time, then test. Best done with automated tools. Leave the “campground” cleaner than you found it.
- Single Responsibility Principle (SRP). “…a class or module should have one, and only one, reason to change.” – Robert C. Martin, Clean Code. If you end up with small, focused methods and classes that are easy to understand, you’re probably doing it right.
- Favor simplicity. The goal is not to show how clever you are.
- Know your domain. Gather clear, testable requirements before you start coding. Get frequent feedback from customers, domain experts, and other developers. Do not “go dark.”
- DI / IoC (Dependency Injection / Inversion of Control). Decouple your classes and make dependencies explicit to support SRP and testability. Interfaces are your friends.
- Automate routine tasks. Continuous Integration (CI) is a great example of this. Computers excel at performing repetitive tasks; developers don’t.
Frequent Anti-patterns of Software Development
- Technical Debt. You will not clean it up tomorrow. Do it right, now. Your future self will thank you. “You can make very short-term gains (days or weeks) by deliberately sacrificing quality, but the cost – human, business, and technical – is enormous.” – Kent Beck, Extreme Programming Explained
- Premature Optimization. Favor maintainable code over fast code. If you must optimize, profile first to find the bottlenecks.
- Copy and paste coding. Instead, DRY and refactor to remove duplication.
- Deploying code that’s not in source control. If everything you need to build and debug the current production version isn’t checked in, you have a sword hanging over your head.
- Not Invented Here. Avoid reinventing wheels. Rolling your own security/encryption code is particularly unwise. Also consider the source; copying and pasting untested code from the Internet carries risks. Finally, insure the solution is a good fit.
- Zealotry. Few methodologies work for every team on every project. Consider other viewpoints. Be open to change. Even methodologies evolve.
- Large classes and long methods. See Martin Fowler’s book Refactoring.
- Singleton Pattern, static classes, and other forms of global data and/or tight coupling.
- Not understanding exceptions. Error codes and null return values can lead to unstable code. “A good rule of thumb is that if a method does not do what its name suggests, it should be considered a method-level failure, resulting in an exception.” – Jason Clark, Cwalina & Abrams’ Framework Design Guidelines
- Unit tests that are really integration tests. Not that there’s anything wrong with integration tests, but you need to understand the difference.
- Excessive comments. If your code expresses intent, comments are often superfluous. And why comment out sections of code that’s under source control? Just delete it!
- Using the wrong tool for the job, such as parsing HTML or XML with Regular Expressions. Also, dismissing a tool (such as Regular Expressions) entirely because some developers misuse it.
Remember that the right answer is often “it depends.” Almost everything is a trade-off. Use your own judgment. Think!
Thanks to everyone who reviewed my initial draft, and to Robert ("Uncle Bob") Martin for inspiration.
Comments are welcome.