Notes on making the code clean

Sprint 2 will focus first on making the code clean and free from repeated statements. There are probably a lot of them.

On class inheritance:

I could probably somehow abstract all of the scanning loops the Computer, Referee, and Announcer do into a single parent class.

Though, the thought of having the Referee and the Computer inheriting the same code smacks of unfairness for the Human. And the idea of having the Computer inherit from two classes seems abhorrent. I might be able to turn the Player class into a Being class and have all actors inherit from it. If that was the case, then it wouldn't seem quite as unfair since everyone inherits from it. Or for that matter have Facilitator and Player inherit from a single root class. That would make for a nice tree structure.

Also that Referee is doing an awful lot, and her file is getting rather long with it. I should probably give her check_for_winner() method to a new Judge class to do just that one job.

On one job in two places:

And xox.py does some things that Referee does as well. I want to put all of the start_game() code together in a single entity with responsibility for that.

On storytelling:

I spent a lot of time crafting a story from the code so I could keep it in my mind, but that story may be holding me back from optimizing the code now. It's a price to pay, but I wanted a very nice handle from which to grok the code, and I was willing to make sacrifices to do it. Now it might be time to start rewriting that story.

On not seeing the forest for the trees:

I was definitely focused squarely on the cleanness of individual functions last iteration. I'll need to go through and identify any code I duplicated unwittingly. It also might be sneakily baked into functions that appear different. So that's something to look out for.

On remembering that test cases are still code:

I'll also be seeing about refactoring the test cases. There's certainly a lot of duplication happening there. Also, I think I'd like to invest some time trying to refactor the tests for unittest instead of nose. It's the batteries included testing framework, and so I really should master the use of it.

On finding my tempo:

Finally I need to consider a lesson I learned from coding arduinos with johnny-five. Annoying.js was exceptionally unclean. It had to be in order to annoy on as many levels as possible. It had many separate variables that were in no way related. It must have had eight different places in the code that needed to be tweaked if we wished to annoy in a different manner. But when we unannoyed it, every one of those variables was derived from a single tempo. It was beautiful, easy to change, and did not require open-heart surgery to use. If there is one philosophy I should fall back on, it's subject the entire system to a single tempo. So I will work on unannoying this code.