| Functionality |
Completes all iterations |
Completes all functionality in iterations 1 through 5. |
Does not complete one of the following iterations: 2, 3, 4, 5 |
Does not complete two or more of the following: iterations 1, 2, 3, 4, 5 |
| Object Oriented Programming |
Students use abstraction and clearly named methods/classes to make code easier to read and understand. Students make clear and defensible decisions around what to store as state and behavior in their classes. A project at this level likely employs techniques or strategies not specifically addressed in class. |
Project is well organized. Students can clearly identify the responsibility of each class that they created and the methods that they wrote. Students are able to describe why they have organized their code in the way they did. Students follow Ruby conventions in the naming of files, classes, methods, and variables. No class is over 150 lines long. |
Students may have difficulty describing the primary responsibilities of classes and methods they have created. Code may violate Ruby conventions around the naming of files, classes, methods, or variables. |
Students have difficulty explaining the reason they have organized their code in the way that they did. They may have few files that seem to be doing the vast majority of the work in the project, and have not drawn clear lines between the responsibilities of different classes they have created. |
| Test Driven Development |
Mocks or stubs are used appropriately to ensure that classes can be tested without relying on functionality from other classes. |
Test coverage is above 99%. Students are able to identify tests at both the unit and integration level. Git history demonstrates students are writing tests before implementation code. |
Test coverage is above 90%. Students may not be able to identify unit or integration tests. Git history may demonstrate that students are writing implementation code and then writing tests. |
Test coverage is below 90%. |
| Version Control |
Students document and implement a code review process throughout the project whereby comments on pull requests are addressed before PRs are merged. |
Students contributed roughly equally to the project in terms of number of commits and lines of code. Commits are made in small chunks of functionality. Students used pull requests as a collaboration tool by reviewing each other’s PRs, making comments, and never merging their own PRs. |
Students did not contribute equally to the project in terms of number of commits or lines of code. Commits include multiple pieces of functionality. Pull requests present but do not include comments or were merged by their author. |
Less than 10 commits. No pull requests. Code is not hosted on the master branch of a Github repository. |
