Description
Assignment policy:
1. Cite all sources of code that you hand in that are not your original work. You can putthe citation into comments in your program. For example, if you find and use code found on a web site, include a comment that says, for example:
# the following code is from https://www.quackit.com/python/tutorial/python_ hello_world.cfm.
Use the complete URL so that the marker can check the source.
3. Discuss and share ideas with other programmers as much as you like, but make surethat when you write your code that it is your own. A good rule of thumb is to wait 20 minutes after talking with somebody before writing your code. If you exchange code with another student, write code while discussing it with a fellow student, or copy code from another person’s console, then this code is not yours.
4. Collaborative coding is strictly prohibited. Your assignment submission must be strictlyyour code. Discussing anything beyond assignment requirements and ideas is a strictly forbidden form of collaboration. This includes sharing code, discussing code itself, or modelling code after another student’s algorithm. You can not use (even with citation) another student’s code.
Instructions:
Find or create a running object-oriented Java program. You must have the proper approval to use this codebase if it isn’t yours. The program you use should be poorly structured and able to be improved via refactoring. A recommendation is to pick code you have written in the past, avoiding GUI-based code. If you decide to write new code for this exercise, some project suggestions are
Accounting or inventory systems for stores or other businesses
Employee management systems
Command-line games, e.g. tic tac toe
The program must consist of 5-10 classes that are coupled together to make the program function. These classes must also incorporate some sort of inheritance structure. For example, there could be an interface that is implemented by two or more subclasses, or a class that is extended by two or more child classes.
Upload this starting project as the initial codebase for a new GitLab project at gitlab-cpsc. ucalgary.ca. You will receive instructions on how to use this system during the first week of tutorials. Next, find aspects of the project that would benefit from refactoring and perform at least five unique refactorings (i.e. no two refactorings have the same name, so you can’t just perform Rename Method five times). At least two of the refactorings must result in substantial changes to the internal design of the system.
You must also perform JUnit testing as you do the refactoring. You will likely want to add or modify tests as you refactor your code into smaller methods. The testing code must also be kept under version control. This unit testing doesn’t have to cover the entire project – a recommendation is to choose a couple operations from the initial project, design simple unit tests for them, and then refactor the code relating to these tested operations. This way, the unit tests provide feedback about whether your refactorings are preserving functionality, without you having to write unit tests for the entire project.
Finally, you need to complete a written report that describes how you did your refactoring. For each of the five refactorings, your report should answer the following questions:
1. What code in which files was altered? Don’t include entire files, just the code snippetsthat were relevant to the refactoring. Line numbers alone aren’t sufficient.
2. What needed to be improved, and why? List any “bad code smells” detected.
3. Which refactoring was applied? What steps did you follow? Use the terminology andmechanics discussed in class or in the Fowler text.
4. What code in which files was the result of the refactoring? See point 1.
5. How was the code tested? Which JUnit test methods were applicable?
6. Why is the code better structured after the refactoring? This could be addressedsimultaneously with point 2.
Use SHA numbers to cross-reference your commits as you describe each refactoring. Also make sure you indicate the refactoring that was required to use branch and merge.
The expected length of the report is about 2–3 pages with standard font and margins, but there are no strict requirements. It is essential, however, that your report is clear, easy to read, thorough, and written in complete sentences.
Submission instructions:
Rubric (100 pts total):
Version control: Used Git/GitLab properly, Multiple small commits with informative messages (25 pts)
Branch/merge: One branch and merge operation used for a larger refactoring (5 pts)
Unit testing: Tests are applicable to refactorings and test robustly for multiple points of failure (15 pts)
Refactorings: Evidence in version control and report of five clear and systematic refactorings. Two of these refactorings result in larger structural changes (25 pts)
Report: Description of each of the five refactorings answering provided questions. Report is thorough and written in full sentences. (25 pts)
Communication: Clear, working instructions on how to access GitLab project. (5 pts)
