Post

The definition of DRY, from "The Pragmatic Programmer" > Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. It has never been about whether you repeat lines of code. Never.

Oh, that's nice A corollary of that is when I see people on my team embedding important business logic in a long run-on if...then statement Like yeah they captured the rule, but the single authoritative place is buried in some line in a 300-line method Break that knowledge out! Unit test it!

My preferred way to build applications is to TDD one class per use case. A to-do list, for example, has a `CreateTask` class. `CompleteTask`, `RankTask` and others make perfect sense as independent classes in that context. Then I add persistence and an interface. In Ruby that often means Rails.

0 reposts3 likes

No replies yet.