CSC323 2010S, Class 28: Wrapup

Overview:
* Program Demo.
* Code highlights.
* Lessons learned.
* Code critique (selective).
* Discussion of final exam.
* Evaluations.

Admin:
* We're almost done!
* If you haven't finished your requisite hours, you can catch up until 5 p.m. on Friday of final's week.
* Email me an answer to the questions:
  * What do you consider your primary contributions to the project?
  * If you think you deserve higher than a B, why do you deserve to be considered "above average"?

Program Demo
* Done

Code highlights
* None

Lessons Learned
* Don't check in non-working code.
  * Can we break our own branch?
    * Probably not.
  * Why did you check in non-working code?
    * We didn't test the non-working parts.
    * Making high-risk big change to the code.
      * That's a good time to branch
    * Treating check-in as save
      * They are not intended to be equivalent.
  * If you can't get it working and it's not making sense, DUMP IT
    * Really hard to actually convince yourself to do this
* Write working unit tests
  * Some parts are hard to write unit tests for (GUI, maybe network)
    * You need to look at the GUI
    * You may need to deal with blocking for the network
  * Writing unit tests takes a long time, so hard with a short development
    cycle.
  * Weren't doing test-first development
  * Cycling between parts of the project made it more difficult.
  * But would save beating our heads against the wall
    * And we ended up doing manual tests instead for some things, which
      took longer!

* Suppose we could teleport back in time eight weeks.  What would
  you do differently?
  LEARNED PYTHON IN MORE DEPTH
  * We produce bad code to start with
  * And why should people suffer through our bad code?
  * One important lesson: It's better to produce a small amount of
    working code than a large amount of buggy code.
  * It's worth N hours of your time to read some "good" code in the
    language.
  UNIFIED VIEW OF THE PROJECT
  * Needed a much more concrete list of functionality.
    * We had an informal list, but needed a formal list.
  * Needed documentation of the responsibilites of each class.
  HOW?
  * A brainstorming session might have helped (but maybe we had too many)
  * CRC cards could have helped if we'd better documented what we
    understood, as opposed to compiling a short story
  MORE ANALYSIS OF THE PARTS OF THE GUI AND NETWORK
  * Particularly features
  * How do you deal with lack of knowledge?  Courage!  Go ahead and
    build something.
  DON'T SWAP GROUPS, OR AT LEAST NOT SO FREQUENTLY
  * So fast that there wasn't transfer of knowledge

Final Examination
* Here's some working Python code.  Critique it.
* Here's a problem, design a solution.
* Here's some code, document it with UML.
* Here's a procedure.  Design unit tests.
* Here's some buggy Python code.  What are the likely bugs?