...
Het class diagram is tot nu toe vrij klein, dit komt omdat we nog weinig functionaliteit hebben en daarom alleen de hoognodige klassen hebben opgenomen. In de komende sprints gaan we meer en meer functionaliteit toevoegen en dit zal het diagram ook uitbreiden.
2.4 Code fragment
Ik ga hier kijken naar een stuk code die ik van onze bitbucket af heb gehaald
Specefiek kijk ik naar dit stuk
Code Block | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
public class TabDAO {
GraphService graphService;
@Inject
public void setGraphService(GraphService graphService) {
this.graphService = graphService;
}
private DatabaseConnection databaseConnection;
@Inject
public void setDatabaseConnection(DatabaseConnection databaseConnection) {
this.databaseConnection = databaseConnection;
}
public ArrayList<TabsDTO> getUserTabs(String token) throws NoUserFoundException {
ArrayList<TabsDTO> tabs = new ArrayList<TabsDTO>();
try {
PreparedStatement getTabs = databaseConnection.getConnection().prepareStatement("SELECT tabName, TabId FROM Tab Where userToken = ?");
getTabs.setString(1, token);
ResultSet getTabsResult = getTabs.executeQuery();
while(getTabsResult.next()) {
TabsDTO tabsDTO = new TabsDTO();
tabsDTO.setId(getTabsResult.getInt("tabId"));
tabsDTO.setName(getTabsResult.getString("tabName"));
tabsDTO.setGraphsDTO(graphService.getAll(getTabsResult.getInt("tabId")));
tabs.add(tabsDTO);
}
} catch (SQLException e) {
throw new DatabaseExceptions(e);
}
return tabs;
}
} |
Kijkend naar de Clean Code principles, hier een opsomming van. Voldoet de code er tot zo ver aan. Ik gebruik hier geen dependencies maar het is wel volgens lower camelCase geschreven, er is geen onnodig commentaar en als functie heeft het maar een doel.
De code voldoet daarom ook de kwaliteitseisen in het PvA.
De code voldoet aan de kwaliteitseisen uit het PvA. Het maakt gebruik van SOLID via de Single Responsibility Principle. Van GRASP wordt Protected Variations gebruik gemaakt, omdat deze klasse een Interface implementeert. Hierdoor zal het altijd dezelfde inputs en outputs hebben, terwijl de logica anders kan worden. Het voldoet aan de Definition of Done. Er is eerst gecontroleerd of het is uitgewerkt in het SRS en SDD en of dit overeenkomt. De code hoort bij de aanmaken job usecase. Het staat niet in de sequence diagram, maar wordt benoemd in een Design desicion. Nadat de code is geprogrammeerd zijn er tests voor geschreven, is het nagekeken door groepsgenoten en is het via Jenkins en SonarQube op codesmells gecontroleerd.
We hebben nog een tijdje gehad dat we niet met Jenkins controleerden, omdat we het nog niet werkend hadden. Toen het eenmaal werkte, hebben we meteen de codesmells en bugs opgelost.
Ik geef de code een goede voldoende.