M16_lab02.md instructions

These are the instructions for the M16_lab02.md file that you will add to the forked copy of the legacy code repo to which you were assigned during M16 lab02.

Your next set of steps will be, in general, to learn about the project, and write about the current state of the project Your goal is to understand what the project is about, identifying things that are good, and things that could be improved.

For each repo, there is a list of known “issues”. * These are found on github.com on the ORIGINAL repo that you forked from, the one under https://github.com/UCSB-CS56-Projects * They will not be on your forked copy. * IMPORTANT: When adding new issues, you will add them directly on the UCSB-CS56-Projects version of the repo, not on the forked copy.

You’ll be trying to understand those issues, as well as determine additional issues that could be added.

In the end, you are doing the steps you’d need to do to “get ready” to take on this as your legacy code project.

Is this the project we’ll be working on the rest of the quarter

Maybe yes, maybe no. Its partially up to you.

You will be given that option—but you’ll also have the option to switch to another project. So part of this exercise is also to see whether you think this project is interesting enough that you want to stick with it, or whether you want to trade away for some other project.

If you trade away, then you’ll contribute your project into a “pool” of available projects. Once that pool is established, you’ll be invited to rank the projects in that pool by your preferences. Then, based on preferences plus an element of random chance to break ties, we’ll make a second project assignment. You are not guaranteed to get your first choice, but historically, most folks have gotten their first, second, or third choice in that second round.

If we find things that need to be fixed, should we fix them?

Note that ACTUALLY making code changes is NOT part of this lab. You MAY do that, but it isn’t necessary at this stage.

Why it might be a good idea to go ahead:

Why it might be a good idea to wait:

Ok, got it. We’re ready to get started. What should we do?

Together with your pair partner, take turns driving/navigating through these steps.

You can use regular or strong-style pairing, as you see fit.

The main tasks are this:

Add a file to the repo called M16_lab02.md in the root directory of the project. In that file, write a short assessment of your findings.

It should include the following.

How to get started

  1. Put your name, your partner’s name, and each of your github ids in the file.
  2. Read the README.md file and try to understand what the project is about.
  3. Read the “issues” on github.com (these will be on the ORIGINAL repo that you forked from) and try to understand what each one is asking the programmer to do.
  4. Run the ant build.xml file with ant -p and see what the ant targets are. Then also look into the build.xml file directly—if there are some targets that don’t have description elements but SHOULD, that’s something to notice.
  5. Try compiling and running the code and see if the code actually works or not.

Once you’ve done all of that, show it to your mentor. Then, along with your mentor, come up with a plan for some things you can do in about 2-3 hours time that can improve the code somewhat. These may include:

  1. Writing proposals for improving the README (perhaps with screenshots, developer documentation, and build/usage instructions)
  2. Identifying bugs with the project
  3. Looking at test coverage (and noting which portions of the project have no test coverage)
  4. Suggesting additional features and adding them as issues
  5. Identify portions of codebase that can be cleaned up and refactored and create corresponding issues
  6. Commenting on existing issues to ask clarifying questions, or point out any parts of the issues that are unclear. Ask yourself—if I were assigned to work on this, would I know what to do and where to start? Or would I be confused and have questions? If its the latter, ask the questions in the comments.

Code related stuff:

  1. Identify uncommented portions of codebase, add normal and Javadoc comments to that portion of codebase, and/or change variable and method names to ones that make comments unnecessary/superfluous.
  2. Read build.xml and attempt to identify unnecessary/obsolete/confusing portions of build script and make corresponding issues.
  3. Checking package names to see whether they correspond to the preferred naming convention for legacy code projects.
  4. Check public, private, “package private” for attributes and methods.
  5. If there are objects that have too much functionality bundled into them, but they should be refactored into multiple smaller objects, make this observation.

Write all of your observations in the M16_lab02.md file.

Low Hanging Fruit

Low Hanging Fruit means some specific easy things you can do to improve the code!

We may add some hints as to what those things might be here, so refresh and revisit this page often.

If/when we do add new material, we’ll post on Piazza.

When you are done… do a pull request

When you are finished, do a pull request back to original repo that you forked from. The pull request will typically only be the change of adding your M16_lab02.md, unless you went ahead and made some changes to improve the project. If you did, those changes will count towards your future lab07 grade (which is the lab where we do the next round of legacy code work by actually working on the issues identified in the project.)

Your mentor will comment on the pull request, and then your TA will “accept” the pull request when your submission is graded. The grade will put into Gauchospace, and your feedback will be added to your feedback repo.

http://UCSB-CS56-M16.github.io/lab/lab02/M16_lab02

http://UCSB-CS56-M16.github.io/lab/lab02