Please enable JavaScript.
Coggle requires JavaScript to display documents.
COMP23311 Software Engineering 1 - Coggle Diagram
COMP23311 Software Engineering 1
Building and Testing
Build automation
This points to the need for the build process to be automated
Build automated tools - maven, ant, MSBuild etc.
Aim: make build
painless to initiate, completely repeatable, quick
Testing
Release pipeline gateways
Code Review
Coding standards/documentation procedures
Automated tests
JaCoCo
Test coverage tool - reports what perceatge of code covered by the tests
Can check perceatges by individual files and check which lines were run or not
If statements are highlighted yellow if not every option is executed.
Reading Large Codebases
Ways to understand large codebases
Improving general programming knowledge
Improving domain secific application knowledge
Try to understand how systems and hierarchies within code are set up
Use IDE functionalities
Assume previous coders were competent (dumb)
Read tests
Unit testing
Unit - small piece of code, a single class or method
Tests should only ever test one class/method
Unit tests should be able to run quickly
Tests should run independently
Arrange Act Assert Pattern
Arrange
set up objects to be tested, reffered to as System Under Test, which is configured to a certain state
usually the largest, if code to arrange system is repeated it is commonly put into a private method
Act
invoke code being tested, save output of method
usually just one line, invoking the method
Assert
assert that the output of the code is the same as the expected value
Avoid repeating the AAA pattern and if statements within the test
Debugging
Debug process
Start with a problem
Stailise the problem
Isolate the source of the problme
Fix the problem
Test the fix
Look for similar errors
Cost Estimation, WBS
Example Work Breakdown Structure
You could break each step down further into sub-sub-tasks
Test First Development
Git Workflows
Commit message rules:
Separate subject from body with a blank line
Limit the subject line to 50 characters
Captalize the subject line
Do not end the subject line with a period
Use the imparative mood in the subject line
Wrap the body at 72 characters
Use the body to explain what and why vs. how
4 common workflows
Feature branches/Feature branches with code review
GitFlow
Github Flow
Trunk-based development
Lines of development
A contiguous sequnece of code versions that have a common role in the development process
Several different kinds found in practice
Main - the latest stable release of the code
Integration - integration of new changes prior ro preparation for release
Release - versions of the code that are bein prepared for release
Validation - versions of the cod awaiting QA (e.g. code review)
Change - implementation of changes to features/addition of features
Fix - implementation of corrections to code behaviour
Feature Branch workflow - a "foundational" workflow
Lines of development
Main, integration - one long-lived branch
Change, fix - many short-lived branches
Branch off Main, integrate back into Main
Release - tags on main or short lived branches for release preparation tasks
Branch off Main, may integrate back into Main
Uses merge for change/fix branch integration
Uses rebase for syncing local with remote
Feature branch with code review
The same basic workflow as Feature Branches
But integration is done through pull/merge requests
Feature branches tend to be a little longer
initial commits
then commits to fix issues raised by code review
Other than this, the commit graph looks the same
GitFlow
The first Git workflow to become generally knwon and used
Gives several levels of protection for team development
Give great protection for the released code, but felt to be unnceccesarily complex
Lines of development
Main - one long-lived branch
Integration - one long-lived branch
Changes and fixes - short lived, branch off integration, non-ff merge back into integration
Hotfixes - short-lived, branch of main, merge into main and integration
Releases - short lived, branch off integration, merge into main and integration
GitHub Flow
A simpler flow but with emphasis on clean builds/code quality
Assumes "cluster of forks" repository configuration
One long-lived branch for integration and main
Short-lived branches for changes, fixes and releases, branch from main, integrate into main
Rule: every commit on main is deployable
Code review through pull requests
Change branches must be tested in production before merging
Trunk-Based Development
Aim: keep a clean development history, support continuous deployment/delivery
One long-lived branch for everything - the trunk
Change/fix/release wok done on local master
Code integration done by squash and rebase
Ony clean code on trunk
Only deplyable code on trunk
Code Smells, Refactoring, Technical Debt
Refactoring
Replacing literals with constants
Shortening methods
Removing excessive comments
Ways of removing coe smells
Common patterns of code changes
Code changes
Corrective change - bug fix
Perfective change - adding features
Adaptive change - porting to another platform, changeing to another programming language
Preventative change - change implementtion to prevent future issues
does not affect funcionality, improves code quality, makes future code changes easier
Functional Requiremements
features the system should implement
e.g. players should eba ble to chat
Non-functional Requirements
Quality criteria not related to functionality
e.g. the system should support real time play for 100 players
Peformance:
Throughput, Capacity, Savlability, Availability, Usability
Maintainability
Readability, Extensibility, Portability, Localisability
Modern approach to code quality
Keep costs low by keeping scale of preventative change small where possible
Use tool support to reduce costs and risks
Use a comprehensive test suite to reduce te risks
Use knowledge of common patterns to reduce costs and risks
Code Smells
A code pattern that suggests poor quality code
Too many parameters - indicates a possible missing class
Primitive obsession - many primitive data types rather than classes and objects
Technical debt
Poor quality code/design knowingly introduces into the code base, in order to meet delivery goals
Get extra developer time now to meet delivery goals
Pay back later through harder-to-change code and/or time spent removing the techincal debt
Technical debt is repaid by finding an removing code
Designing for Testability
Software Design Patterns
Risk Management
Software Architecture Patterns
