Over the past two weeks I have spent much of my time concentrating on learning about big-picture aspects of programming and thinking about how I can apply those principles to my Tic Tac Toe game. I have completed reading Robert Martin’s Clean Code and have compiled a list of some of the most important concepts I have gleaned thus far:

Objects and Data
- Objects expose behavior and hide data
- Data structures expose data but have no significant behavior
i.e. a class with public variables and no functions is a Data Transfer Object (DTO)

Error Handling
- If error handling obscures logic, it is wrong
- Include informative error messages and pass them along with exceptions
- Instead of returning nil, throw an exception or return a SPECIAL CASE object

Boundaries
- To integrate 3rd party code, write (learning) tests to better understand the code
- Rely minimally on 3rd party particulars for code interaction

Three Laws of TDD
- No writing production code until failing unit test is written
- No writing more of a unit test than is sufficient to fail
- No writing more of production code than is sufficient to pass current failing test

Classes
- Keep classes small (let the class name drive the class size)
- Single Responsibility Principle (a class or module should have one and only one reason to change)
- Throwing many responsibilities into one class is akin to tossing many tools into a toolbox
- Should have a small number of instance variables
- Dependency Inversion Principle (classes should rely on abstraction, not on concrete details)

Cohesion
- Principle of using as many instance variables by as many methods within a class
- When classes lose cohesion, split them into smaller classes
- Open Closed Principle: Classes should be open for extension but closed for modification
i.e. to incorporate new features, ideally the system should be extended rather than modifying existing code.

Systems
- It is a myth that we can get systems “right the first time”
- Separating concerns properly allows for organic growth
- Postpone (design?) decisions until the last possible moment, allowing for the most informed decision
- Use the simplest thing that will possibly work

Emergence
- The majority of the costs for a software project is in long-term maintenance
- Simple Design (a la Kent Beck) should run all tests, contain no duplication, express the intent of the programmer, and minimize number of classes and methods

Concurrency
- Decoupling what happens from when
- Uses: a) gather data from multiple websites simultaneously, b) serving multiple users concurrently, c) process many large data sets
- Examples include producer-consumer, readers-writers, and dining philosophers

Successive Refinement
- Like writing an essay, writing ever-improving multiple drafts is key to writing clean code
- As in the rules about classes, “Much of good software design is simply about partitioning -- creating appropriate places to put different kinds of code. The separation of concerns makes the code much simpler to understand.” p. 250

In addition to this reading I have also been working diligently on the Ruby Koans, with only 10 more (of 284) to completion.

As far as the Tic Tac Toe goes, I have fleshed out my design for the program and will include it in a subsequent next post.