Prioritized list of refactorings

Below are our prioritized list of refactorings. Our initial plan is to tackle these in this order, but we may need to revise that plan as we move into the refactorings.

You probably want to remove all my italicized "instructional" text as you work through the proposal.

Make sure to commit frequently as you work. At a minimum you should commit after completing each refactoring so you can document that accomplishment in your commit message. For more complex refactorings you'll probably want/need to commit multiple times as you go.

Refactoring 0

Issue/bad smell being addressed

Add some tests!

This will address the issue of the project not having enough tests!

Planned refactoring

We'll all pull an all nighter this weekend and write a bunch of tests, and take a break at 4 in the morning to play Dungeons & Dragons.

Technical difficulty

The technical difficulty of this is I (Adrian) have never seen this code before, and expect it to be difficult to understand. However, writing tests will help me learn. Also, hopefully it wont require any outside stuff (i.e. a non local server) to run said tests.

Impact on the code

It will definately not suck, and it paves the way for more refacterin'

---

Refactoring 1

Issue/bad smell being addressed

Controllers contain large, complex methods.

Planned refactoring

Take a look at the functionality provided by the controllers, identify shared logic or modules that can be broken out into separate methods. Also consider creating a shared class/library if the refactoring warrants it.

Technical difficulty

This is difficult in that it deals with the most in-depth code the project contains. Everyone is a bit rusty on their groovy as well. Refactoring 0 will take care of the once lengthy task of testing this code. In addition, the refactoring already done as suggested by Sonar last year may be difficult to interpret as it frankly said to do some rather odd things in the name of code quality.

Impact on the code

The code will be more modular, easier to read, and adhere more closely to DRY principles.

---

Refactoring 2

Issue/bad smell being addressed

References to buttons in existing test are fishy and could be better. Max M. and Lynkyn added values and tags to different buttons in a desperate attempt to make them work.

Planned refactoring

Look for fishy tags

and replaced them with less fishy tags.

Technical difficulty

Should be easy as pie really. Lynkyn was pretty code illiterate during software d, its better now mostly.

Impact on the code

This will declutter our buttons and make the tests more readable.

---

Outcomes

For each refactoring you did, summarize the outcome. How difficult did the refactoring turn out to be? What was its overall impact? Are there new doors that this refactoring opened?