Borealis

Welcome to Borealis

Check Out Our App

FAQ

Are there any particular design smells, or brilliant design decisions?

A Brilliant Design Decision

In our registration feature we simply checked if a student can register using if statements, this started out as a smell and quickly grew into an open/closed violation (SOLID violation). To fix this we came up with a brilliant overhaul of the feature's logic. We instead use an abstract class with validator subclasses. They all have one valid() method and some have helper methods. There is then an array list in registration of the validators, before registering a student the list is cycled through and each element (a different validator) gets a .valid() called on them and if none throw an exception (user cannot register) then the user is registered.

What went wrong in the development process?

Our teams organization and planning could have been more organized. We roughly did our iteration planning with the features, stories, and development tasks on a shared Google Docs thinking this would be more flexible. Ultimately we had to cram at the end of each iteration to get everything we needed onto GitLab. We would have likely been better off to just organize them on GitLab with time estimates and issue specific internal deadlines, and then assign people to the issue on GitLab.

How large is the project (number of methods, classes, etc)? How much of this is (roughly) devoted to each major system component? And any other quantifiables (e.g. if you have a record of hours spent on tasks).

Quantifiables

Stats:

  • Class Count: 182
  • Method Count: 792
  • Line Count: 3970
  • APK Size: about 12 MB
  • App size: About 113 MB
  • Repo size: About 122 MB
  • Number of Commits: 486
  • Average Commits per Day: 7.3
  • Highest Commits per Weekday: Wednesday, 127 Commits
  • Number of Days spent on project: 44 (at 8 hours per day)
    • Iteration 1: 3d 4h | 38 Issues
    • Iteration 2: 3w 1d 3h | 38 Issues
    • Iteration 3: 1w 1d .5h | 61 Issues

By Component:

  • Logic:
    • 22% of classes
    • 15% of methods
    • 15% of lines
  • Objects
    • 8% of clases
    • 22% of methods
    • 8% of lines
  • Persistance
    • 15% of classes
    • 14% of methods
    • 31% of lines
  • Presentation
    • 52% of classes
    • 45% of methods
    • 44% of lines
What did you learn about team or large project development? What will you start doing, keep doing, or stop doing next time?

The project was an immense growth experience as developers. In our project, we made a strategic choice to focus on setting up clear interfaces in the logic part of our software from the start. This decision (made through learning from the sample project) matched what we later learned in class (Dependency Injection). Through defining these interfaces early on, we could all work on our own parts, knowing what output we can expect from others but without caring how they will implement their code. Seeing how effective this was, we know we should keep doing this in future projects.

What Will We Keep Doing?

Another practice we learned was branching strategies and version control. At the start of the project we started out with hectic branching, unplanned and some of us did not pull often leading to large merge conflicts. Throughout the iterations we worked on this and improved, but at the end we still had a few large merges and many conflicts (one was 40+ files). We will now start merging and pulling more often as we did near the final release.

What Will We Stop Doing Next Time?

As to what we would stop doing next time, leaving code clean up to the last minute. When having weekly meetings with the team throughout the term, we would often plan for all code to be done the night before,leaving minimal time for cleaning up comments and checking for SOLID violations. This led to finalizing code 10 minutes before submission as well as letting some dev comments slip through. This was a learning experience and taught us to not repeat that mistake next time.