I just saw on a blog called Panopticon Central, I saw an entry called Seven Rules for Beginning Programmers. I had to continue the list with some rules (caveat emptor #12 below) of my own.
- Write automatable unit & integration tests and run them on every build. Do not declare yourself to have a successful build until not only everything compiles but also all tests run successfully.
- Make judicious but appropriate use of interfaces.
- Don't overuse inheritance; it leads to brittle hierarchies. Always prefer composition.
- Layer software appropriately. Recognize that even when using an object-oriented language, some artifacts, like service layers & strategies, are procedural in nature.
- Understand the difference between persistent domain objects and data transfer objects, and combine the two only when you understand the tradeoffs.
- Avoid anemic domain models.
- Understand source control, branching & merging.
- Understand aspect-oriented programming, and how it complements object-oriented programming via modularization of cross-cutting concerns.
- Always pay attention to advances in new or existing programming languages, techniques, and ideas.
- Understand dependency injection, inversion of control and how it makes your code less coupled.
- Always keep your business logic independent of the environment in which it will run.
These last two apply to life, not just programming: - Know the difference between a rule and a guideline.
- When faced with a choice, the one that it is more emotionally difficult for you to choose is often the right one.
4 comments:
Interesting list - it would be helpful if you would elaborate on each of your rules (maybe with some examples) to make them a little more clear an easier to understand.
David Roh
"We prefer composition over inheriting multiple interfaces". There's nothing wrong with inheritance, but multiple inheritance gets messy quick.
It's not a "rule", but a "guideline". Calling them rules like this will only lead to managers enforcing the rules blindly.
Your statement that we shouldn't overuse inheritance is a dangerous one. We prefer composition over "multiple inheritance" (think interfaces, a lot of them makes a messy object)
Calling it a rule (#12 says that the above isn't a guideline) merely leads to managers blindly trying to enforce those rules.
@David, I will try to elaborate when I have a chance. No promises...
@Eddy, My point behind #12 was a toungue-in-cheek way of saying that nothing is a rule and everything is a guideline... :)
-matthew
Post a Comment