Dave Read

Rewarding to see students recognize the presence or absence of good software engineering practices in other projects. At the start of the semester, they discussed the ideas, then applied them as a development team, and now demonstrate the ability to identify them in broader contexts.

Noting redundant code, "DatabaseManager repeats logic in at least 6 methods. Each one opens a connection, prepares a statement, executes, and closes; all identically structured. This is a textbook DRY failure that could be solved with a single helper that accepts a lambda or query callback."

Noting some attention to security, "The [JDBC code] also uses prepared statements, which protect against SQL injections. There is even evidence of some limited penetration testing, as the database includes a user named SELECT * FROM."

A shout-out to using enums, "Algorithms seem to be simple, with limited use of nested if-else or nested loops. One aspect of this efficient code is the widespread use of enums. Each event in the game is represented as an enum. This makes controlling and updating the flow of the game quite easy."

Pointing out the value of git comments, "there are a vast number of commit messages such as: 'Changes made' or just 'standards'. Messages like these hamper the development team. When someone needs to view changes that were made, they now need to spend more time combing through each commit."

Weak validation, "The [email] input is only verified that it is not null and has a non-zero length, which means that any non-empty string would be valid. A much more accurate approach would be to use something like regex to pattern match strings that follow allowed email formats."

Ah, communication, "Additionally, the teams struggled with cross-functionality [between tiers], sometimes even creating duplicate work due to a lack of communication."

Standards lacking, "the biggest [git] issue was students pushing broken code into main. This was an issue for every sprint except sprint 4... they should have updated their development standards, as it has no mention that broken code should not be pushed into the main branch."

And noting the disconnect between team-created standards and follow-through, "The testing standards page had a goal of 90%>=, their final code coverage ended up being 6% in total. There are entire packages that don’t have a single unit test."

First up, testing, "reviewing the testing done by the [Project Name] team... before covering the issues within tests they do have, it’s important to address one of the largest issues first, the lack of unit testing in the first place... They had 62 tests for 18 thousand lines of code."