19
« on: March 24, 2016, 01:12:27 PM »
Finally have time to sit down and spell out this idea. This post is geared toward the dev team & experienced programmers; without wanting to sound rude or abrupt, if you don't fall in those categories it's prolly better to just look on.
----------
I won't give a long preamble. You are working with an ancient, brittle legacy code written in procedural style, and because of that it is very difficult if not impossible to quickly fix bugs & to make new changes without the fear of breaking things. You have a long list of things you'd like to get to, but all of your time is eaten up chasing down bugs and so things like the "war package", reworking tournaments, reworking the advy game, etc are pipe dreams that won't happen for years. That's not criticism, that's just fact. Legacy systems are no fun.
Volunteers are needed, but experienced programmers make a good hourly wage and have no interest in spending their nights and weekends sticking band-aids on top of band-aids on top of band-aids of an old creaky legacy system when they could be making extra money or doing their own side projects. If you don't attempt to modernize, you're never going to get more than the occasional help from young college kids who don't really have the experience the codebase requires.
You need to find a way to drag the codebase into the modern programming world without doing a major upgrade all at once that no one has the time or probably the interest in undertaking. I've been giving some thought to this and have a suggestion I think will at least help get you started down the road.
----------
First, you *must* understand that the root of all the problems in your codebase is that it is essentially procedural. You will not be able to make any improvements until you start to move away from that. Code needs to be refactored to functions and then objects. Functions are not only about not repeating code; objects are not only about hierarchy. They are to move your code to higher state that are testable & follow SOLID principles.
This is not some giant, 3 year project - you do it bit by bit, each time you need to go into the code to fix or tweak it. Even so, it is a big project at first, especially if you are not familiar with this type of programming. That's where I have an idea I think can help.
----------
You are already using composer, meaning that you have an autoloader in place, and an easy way to add more external classes & modules. Many people don't realize that composer can be used to load classes directly from any VCS (ie git, svn) without going through Packagist - you can just pull it in from your own github or bitbucket account, for example.
What this means is - developer can help you out by writing small bits of code completely separate from the main code base, in a BM-owned repo, and you can simply pull it in & use it. The dev does not need to have access to the main BM codebase - or even know that's what he's working on - to be productive. This is VERY IMPORTANT because it also means a dev can volunteer to do a small task without feeling like they are being led down a rabbit hole.
How's this possible? Because good code is "decoupled". Let me give you an example.
----------
Let's say you need to rework the dueling code, for tournaments or whatever. Your current code probably calls the database (or Doctrine, making it easier ) to get the details of the duel, calls the database to get each character, takes some values from them and pass them into a function that runs through all the code and returns a result.
What *should* happen is you call Doctrine and get the two chars that want to duel & the details and pass to a "new Duel()" class... and it magically returns the results. "Duel" class was created by Pedro the Programmer & pushed to BM's private bitbucket account. He doesn't know anything about your database or anything else in your codebase; maybe he doesn't even know this is for BM.
He defines the data he needs you to give him, asks for your business logic & what info you need returned. Duel() is a black box. All the *dev team* needs to do is rip out all the dueling logic (in this case, prolly just a big function - it's a simple example) and write something like:
// get the duel & char info
$results = (new Duel)->fight($char1, $char2);
// use the results to update the chars status, send message, etc
In other words, you pull out a big chunk of procedural code, hand it off to someone to turn into a set of *tested* OOP code, and integrate it back into the codebase.
----------
Why is this wonderful?
- you make small tasks that you can more easily get help on, and get finished quickly
- you slowly increase your code coverage
- if the existing class later needs tweaks for new idea, *any* programmer can look at it and change it quickly
- you build up a small collection of libraries that can actually be mixed & matched and turned into new games - a new dueling or advy game could be snapped into Laravel & rolled out in a weekend.
----------
As I said earlier, this is not some giant project that takes a huge commitment. It is as simple as setting up a new repo (a button click, and give a name), isolating some code and handing it over to turned into an object. It is a slow & steady improvement. I know there are still a million questions about how you would handle X, Y, Z but those can be explained in later discussions.
I am happy to answer anything, and even walk you through a simple example to show you how it would all work.
Show Posts