Now that all of the pieces are implemented, I decided to change it up a little and get rid of a few yellow items in one fell swoop. I thought it would also be a good time to
Here’s what I accomplish in this clip:
- Move Knight into it’s own class.
- Separated test and production into their own assemblies.
- Got rid of the DefaultBoardSize constant that had been defined in many test classes by consolidating it into one place.
- Went back to earlier test classes and implemented “MovesFromXX” pattern that I had settled on.
Here are some lessons to take away:
- If Ctrl-M, O stops working (or any normal VS shortcut), it might be because some other process has claimed part or all of the sequence and is preempting Studio. Kill processes or reboot.
- If you have some mundane but necessary tasks (e.g. moving a bunch of classes into a new namespace), this can be a good way to “warm up” when you haven’t looked at a code base in a while. Generally speaking, look for tasks that can ease you back into the code base while being productive.
- Even duplication that is seemingly mundane should be avoided. The DRY principle states that systems should have a single point of definition for all pieces of knowledge, and that includes things like database schemas, config files, and yes, even your unit test classes. You need to maintain your unit tests, and duplication creates maintenance pain.
- Pay attention to your test method names as you’re making changes. These are documentation as to how your code should behave, so if you change the behavior, make sure to change the names to reflect those changes.
- “Lean on the compiler” to help you with your refactorings. If you’re getting rid of a bunch of references to a variable, delete the definition of the variable and the compiler will then force you to get rid of all references. If you do it in the opposite order, you might miss references and waste time. As a more general rule, you should always favor failing early and doing things in such a way that mistakes will result in non-compiling.
- When you do large refactorings, it might not hurt to run all of the unit tests explicitly in the test runner instead of relying on the dots in NCrunch (or any continuous testing tool that you’re using).