This box searches only this space. The box at the upper right searches the entire iPlant wiki.

Skip to end of metadata
Go to start of metadata

Section 1: Write programs for people, not computers. (Anthony Dominguez)

    A program should not require its readers to hold more than a handful of facts in memory at once.

  •  There were weekly meetings on discussing the intuitiveness of the programs, which helped reduce it.
  • Grade A

   Make names consistent, distinctive, and meaningful with consistent code style and formatting.

  •  The team had informal code reviews each week, which kept the consistency in the style and formatting of the code.
  • Grade A

 

Section 2: Let the computer do the work. (Jackson Lindsay)

The team used Maven, a tool for managing and compiling Java programs, in order to manage the various software libraries of the project. In addition, making the collection of eBooks within the application persist between sessions was an early goal for the team. This allowed them to test the application's other features without having to add a large amount of eBook each time.

However, the team did not make use of many automated tests. This is understandable, since their main concern was the user's interaction with the software, and subsequently its GUI, but there do exist automated GUI-testing tools that could been utilized. 

Grade: A- 

(Note that, since the program did not make use of the command line, the idea behind "save recent commands in a file for re-use" was not applicable. However, if it is of interest, one team member revealed that ctrl+r can be used in bash to search through previous commands, eliminating the need to save single-line commands in a file.)

 

Section 3: Make incremental changes. (Rafael Barreda)

Work in small steps with frequent feedback and course correction.

    • The team had weekly meetings to discuss the design of the software and what aspects would be most intuitive to the user. The team also held informal code reviews every week, giving feedback on the project. Near the beginning of the project, the team settled a ¨minimum viable product¨ that they set, and this allowed them to have a goal for the finished product.
    • Grade: A

Use a version control system.

    • The team used GitHub as its version control system. They committed throughout the week and performed pushes during their weekly meetings.
    • Grade: A

Put everything that has been created manually in version control.

    • Everything that was created manually was put into GitHub in order for everyone in the team to have it.
    • Grade: A

Section 4: Don't repeat yourself or others. (Erika Tapia)

Every piece of data must have a single authoritative representation in the system.

The team implemented a model-view-controller (MVC) design pattern in order to ensure that the data (i.e. the user's collection of e-books and tags) had a single representation in the program.

Modularize code rather than copying and pasting.

The team modularized their code and proved helpful when they needed to refactor their code later in the project life-cycle. 

Re-use code instead of rewriting it.

Following the MVC design pattern separated the major components of their program, which allowed them to reuse their code.


Grade: A

 

Section 5: Plan for Mistakes. (Erika Tapia)

Add assertions to programs to check their operation.

The team utilized defensive programming by adding assertions to their program in order to check its functionality. Sample assertion statements are shown below:

Use an off-the-shelf unit testing library.

The team implemented another layer of defense - automated testing. As shown in the image above, the team used an automated DataLibraryTest file (amongst several other test files) that ensured single units of their code were returning correct results (unit tests) and that pieces of their code were working correctly when combined (integration tests). The team utilized assertion statements for regression testing in order to verify the behavior of their program didn't change when the details were modified.

The team also implemented/imported libraries to make creating and managing their tests easier. Below is sample of their code:

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

Turn bugs into test cases.

The team wrote their tests as they walked through edge cases (what is normal behavior versus error behavior) in order to trigger bugs in their code and fixed them to prevent the bug from reappearing.  

Use a symbolic debugger.

Since the team did not write the program in an assembly language, there is no need for a symbolic debugger. The team incorporated several effective testing techniques that verified their code and allowed maintenance to become easier over time. 

 

Grade: A+ 

 

Section 6: Optimize software only after it works correctly. (Anthony Dominguez)

    Use a profiler to identify bottlenecks.

  •  When using the software, the team realized that having a lot of ebooks in the library made the program a bit slow to load. After realizing what was bottlenecking the program, they made the executive decision to refactor the way how the e-books were shown to increase the bottleneck.
  • Grade: A

   Write code in the highest-level language possible.

  • The code was written in Java, which is a reasonably high-level language. Not only that, but it is a rather popular language as well.
  • Grade: A

 

Section 7: Document Design and Purpose : (Mo Moghaddam)

529-HW2-Screenshot.png

Document interfaces and reasons, not implementations.

    •  

      According to this suggestion, the documentation should describe an implementation in a high-level language. The team had a great job of recording the rationale behind each implementation. They included some comments in code fragments, which was not necessary. The team could improve the documentation by providing more information about the methods of a class.

    • Grade: A

Factor code in preference to explaining how it works

    •  Based on the paper, code refactoring is the process of code modification without changing its functionality. The paper suggests keeping the fragments of code as simple as possible in order to be documented easily.  The team could fulfill that requirement by keeping the functions and methods as small as possible

    • Grade: A

Embed the documentation for a piece of software in that software

    • The team mostly kept their rationales in the notebook. However, they had a summary of that in the actual developing environment. The work could be improved by providing more information and mechanism in the actual code

    • Grade: B

 

 

Section 8: Collaborate. (Rafael Barreda)

Use pre-merge code reviews.

    • Before ¨pushing¨ onto GitHub, the team used pre-merge code reviews during their weekly meetings. However, the team did commit during the week.
    • Grade: A

Use pair programming when bringing someone new up to speed and when tackling particularly tricky problems.

    • The team only did this once during their weekly meetings. They never really encountered too many problems. If they were to do this again, I would recommend them to have pair programming more, even if they didn´t encounter many problems to stay up to date of each other.
    • Grade: B

Use an issue tracking tool.

    • They used GitHub for this, as they could always revert any issues or commits if it was deemed wrong.
    • Grade: A

I give this project an A-, as they pretty much followed every step in the Best Practices article. 

 

OVERALL: A-

 

POSTMORTEM:

Good: Everyone was eager to work and we partitioned work rather fluidly. We were also open to discussing our answers as we worked on them; Everyone was readily available through Slack. 

Bad: We could've start organizing/working a bit earlier. This did not become a problem, but it could have if there were complications in the project.

Ugly: N/A.

Change: Start earlier. Come up with consistent styling guidelines for our answers. 

 

Mohammad Moghaddam

Jackson Lindsay

Rafael Barreda

Anthony Dominguez

Erika Tapia

  • No labels