Refactoring RubyWarrior and Planning Social

Last month we wrote a bunch of questionable RubyWarrior code. It got the job done but usually consisted of nested if/else chains and did not communicate its intent. Maybe it even had a bunch of comments to provide a view of what is going on. It was the kind of code you'd to hate to be asked to maintain without knowledge of the author or any context.

How do you figure out what that kind of code does?

How do you ensure maintenance changes retain the other unrelated behaviors?

How do you clean it up so someone else will smile when asked to maintain it?

The answer is to use tests to support refactoring the code, splitting responsibilities out to objects that have a single responsibility, and letting the code and tests (not comments) speak for itself and show its intent.

We'll talk a bit about testing and refactoring, and work towards a cleaner RubyWarrior implementation.

Feel free to bring your own RubyWarrior implementation. We'll pick one to work through. If anyone has another piece of code that is causing problems, feel free to bring that and we might be able to discuss it as well.

---
Also, to start out the meeting I'd like to have a quick informal planning discussion about what we all would like to get out of RubyMKE in near future. I'd like to get an idea of where everyone is and what we can do to help each person level up. So, try to think about what is painful or not understood in your current Ruby life. Then we can put together some meetups more closely targeted at filling the immediate needs of the group.