Matthew Palmer

Writing Easy to Change Code

A couple of notes on Session 112 of WWDC 2011—Writing Easy to Change Code.

Writing easy to change code is your second most important goal when making software; the first is shipping the product.

Software is always going to be changed. Make it easy to do so.

Thinking ahead of time makes changing it later much easier.

Style

Clarity is the goal. Clear code is easier to change. Local consistency is important, but this is only the basic level of style.

How to code clearly?

Clarity.

Stories

Tell a story with bug fixes; communicate increased understanding.

Laziness

Could solve with

Be thoughtful about lazy initialization.

Hygiene

Delete cruft, not code. Refactor, not rewrite.

Notifications

Bad

Good

Consider protocols or delegates instead of notifications: use notifications rarely.

Optimization

Optimize the things that are slow, the things you understand best, the things that have the clearest role. Try to optimize the slowest and oldest 3% of your code.

Only optimize after you’ve measured and understood, and never make the program slower.

Dependencies

Keep dependencies small and shallow.

Mixing

Don’t mix different things.

Expectations

Make it hard to use wrong.

Summary

  1. Clarity
  2. Bug fixes tell a story
  3. Be thoughtful in lazy initialization
  4. Refactor, don’t rewrite
  5. Use notifications appropriately
  6. Keep new code easy to change
  7. Optimize slowest and oldest code
  8. Reduce dependencies
  9. Don’t mix different things
  10. Make it hard to use wrong
Follow me on Twitter