Practicing OOP, Scrum, and Test-Driven Development in a Quick Project

Programming conventions and best practices are continually changing. When programming features for your company’s project, you may be tempted to implement the newest process in the feature you’re working with. Unfortunately, I have often found that with deadlines, or just the amount of refactoring that would be required to implement a new way of doing something makes it nearly impossible to achieve a new development process properly.

I’m always looking for new (easy) projects I can work on that would involve implementing as many practices and processes that I’ve read about as possible. It allows me to find out what does or doesn’t work, and how I can use it in a more functional area with my work. At the moment, those processes are:

It’s challenging to find a type of project that could use as many or all of the above processes that wouldn’t consume all of my free time and could be done in a relatively short period. A few days ago, I thought up not one project, but an entire genre of projects that could vary in difficulty. Card games!

Computer game of Solitaire

Card games can vary in complication from a simple random-chance game like War, to something as complicated as Texas Hold ’em Poker. Because of the different aspects in gameplay, Object-Oriented Programming is an absolute must, with classes like Player, Deck, & Game. With the game logic that comes into any one of these card games, test-driven development can be implemented by setting up scenarios and testing for specific outcomes based on particular plays. Finally, many card games vary in rules, so features can always be added. That fulfills both git branching & release models, as well as using Scrum for things like a Minimum Viable Product, “Done” Definitions, (in some cases) User Stories, “effort”/story points, and even standup meetings and sprints.

I plan to work over the next work on the simple card game War, which is based on random chance, making it easy to create a computer player. I’ll do it in Kotlin, a Java framework which compiles for the JVM, and Swing for the GUI. For the Scrum process, I will be using Trello. The process will look something like this, and I’ll be posting for each step done:

  1. Establish Scrum User Stories (individual features) with story points and “done” definitions
  2. Define the minimum viable product based off of Scrum User Stories
  3. Create the Git repository & branch
  4. Create tests for the first user stories in the MVP
  5. Develop features to fulfill the criteria and to make them pass
  6. Ensure features & tests meet their user story “Done” definitions
  7. Create a Git release, tag & compile it as the first “alpha” release
  8. Continue with the remaining user stories