How to avoid becoming a formerly-employed rails developer standing in line at the OOP kitchen¶ ↑

This is a project whose goal is to illustrate how you might refactor a typical (in my experience) Rails app into something more manageable.

It’s an appendix to a presentation I plan to give, and to which I’ll link when I have a link available. (To slides and/or recording)

The outline of the project is supposed to follow something like this:

1. Extract and anonymize the typically bad parts from an app I’m currently working on

2. Put them in this project as working examples.

3. Create a new branch for each major type of “fix” to the code.

4. Issue a pull request back into the master branch so all the changes are visible in one location.

Any ideas you have on how to improve this, or other techniques you’d like to see can be added. If you want to add them yourself:

1. Fork the repository

2. Add the crap code. Issue pull request so we merge it here.

3. Create a branch to fix it and fix it.

4. Issue pull request and we’ll merge it in.

If you’d rather have me demonstrate a technique, get in touch with me at (insert contact info here) and tell me your idea.

I’ll keep a list of the major fixes here, so you can refer to them easily.

Tentative workflow will be:

1. Original bad code is in its own branch: bad_shape. Develop the example of what needs to be fixed on that branch.

2. Create an issue that points out the bad code

3. Develop a fix for it in a new branch. Try to remember to prepend #123 (the issue number to commit messages).

4. Do a pull request so the fix is highlighted, then merge it back into master.

5. Except at the beginning, the master branch should be a good example for people to look at.

I’m taking suggestions on how to improve the workflow. It feels clunky. If you don’t know how to get in touch with me, try the contact form on my blog.