Wednesday, May 18, 2011

A Baker's Dozen More Rules, and Not Just for Beginning Programmers

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.
  1. 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.
  2. Make judicious but appropriate use of interfaces.
  3. Don't overuse inheritance; it leads to brittle hierarchies. Always prefer composition.
  4. Layer software appropriately. Recognize that even when using an object-oriented language, some artifacts, like service layers & strategies, are procedural in nature.
  5. Understand the difference between persistent domain objects and data transfer objects, and combine the two only when you understand the tradeoffs.
  6. Avoid anemic domain models.
  7. Understand source control, branching & merging.
  8. Understand aspect-oriented programming, and how it complements object-oriented programming via modularization of cross-cutting concerns.
  9. Always pay attention to advances in new or existing programming languages, techniques, and ideas.
  10. Understand dependency injection, inversion of control and how it makes your code less coupled.
  11. Always keep your business logic independent of the environment in which it will run.

    These last two apply to life, not just programming:

  12. Know the difference between a rule and a guideline.
  13. When faced with a choice, the one that it is more emotionally difficult for you to choose is often the right one.

4 comments:

David Roh said...

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

Eddy Vluggen said...

"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.

Eddy Vluggen said...

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.

Matthew Adams said...

@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