content
W1 -System Processes
SDLC
Plan
Code
Build
Test
Release
Waterfall
Plan
-> Software requirement documents, product roadmaps, what software should do...etc
Design -> Design architecture, user interface, database (Figma, ER models)
Code -> Developers working concurrently to work on different components in the software
Integration -> Combine all individual components to create a unified software
System Test -> Testing at the end of the software creation
✅ Logical and organised as the requirements are stated very early on; follows an iterative and incremental process. ❌ A plan is executed, and it is not purposeful; this method assumes plan is clear from the start, but an iterative and incremental process brings in uncertainty as there may be discovery of bugs, change in clients plan/goals midway through the project.
Agile Process
No standard template/checklists/procedures
More prescriptive than descriptive
Examples: Scrum, Extreme Programming (XP), Kanban
Scrum
Uses short iterations called sprints that focus on productivity
Breaks down a product into sprints, with each sprint focusing on one feature/task of the project.
After each iteration, show something to the client.
Roles:
Product Owner: Lead user of the system, person with the vision of what he/she wants to build
Team: Develops the product
Scrum Master: Facilitates the process of stand ups.
Process:
Plan
Customer presents user stories and prioritises the business value a feature will bring, and the developers will choose what features they can realistically deliver in a week
Execute
Review
Potentially, when done, customer tries the features in a working build.
XP
Focus on software engineering practices and quality
XP Main Practices
Pair Programming + Test-Drive Development (TDD)
Developers pair up to write automated tests like unit tests
Code is then written to make the test pass, and then refactored to improve code quality
Pairs rotate to share knowledge and improve code quality.
Continuous Integration
Automated build and test process for a team
Code Review and Refactoring
Studying of source code by others
Modify existing code to imrpove design, structure, without changing functionalities
Kickoff/Sprint Planning
Each project begins with a kickoff meeting
Overview of the project and the goals
Who will be working on the project
Determining the point person for client sign-off/contact
Creating project backlog
Determining which features to work on
Getting on the same page.
Software Operations
Operate
Make sure apps runs well, reliably and avail with adequate security
Monitoring
Be able to respond to any incidents early and predict future incidents
Handle Requests and Feedback from Users
Collect and analyse data on availability/performance, security and other operations-related processes.
Securtiy
Data Theft, Data tampering, DDoS
Internal and external threats
Access control: authorisation and authentication
Incidents and Recovery
Unplanned service interruption
Reduce quality of service
Minimize negative impact of incidents by restoring normal service operation as quickly as possible
To identify active and potential causes of incidents - prevent future incidents -proactive
Dev vs Ops
Dev became faster than ops because of agile
Testing and deployment were isolated activities done after code-build
Separate Dev and Ops team timelines did not align well
DevOps team
About collaborating to quickly develop deploy and support production
CICD
CI: Automating software build and test
CD: Pipeline to build, test and deploy the whole package.
Dev Ops Anti-Pattern
Assign role of DevOps Engineer ⇒ No point! We are trying to collaborate so that everyone is doing Agile
DevSecOps
Traditionally, security if an afterthought, and dev team might be disbanded by the time security testing are run and software issues are found.
Security team finds it hard to understand root causes of software issues.
Automate core security by embedding security practices and considerations in SDLC.
To start:
Plan on where, how and where security testing will be done: Jira, Slack, IriusRisk
SAST/DAST, code analysis, code reviews: Gerrit, PMD, SpotBugs, Copilot
Build: OWASP Dependency-Check, Synk, SonarQube
Test: ZAP, BurpSuite
Release: Ansible, Chef, Docker
Deploy: Osquery,Chaos Monkey
Operate: IMperva RASP, Alert Logic
W2
Software Requirement
Customers must communicate with the software-building team
This is a business vs technical side kinda situation
If either side dominates the communication, the project loses
All about functionalities and time, little to no concern on whether the tech team understand what is needed, or able to deliver by deadlines.
Hard to predict software projects
Requirements, Complexity grows and changes as the project progresses
Difficulty to estimate how long thinfs will take
User story
Define things user want from your product
"As a (XX user), I want to [do smth] so that i can [get to the goal]"
Product Backlog
Something that is continuously derived and refined from large/existing customer stories.
Usually describes the features, known issues/defects/research that is related to the product.
Backlog is something continuously refined
Product Backlog Operations Requirements
Consider: availability/latency/operational performance -> how much downtime?, scaling, monitoring needs
Logging: what to log, purposes, and how to proper logging
Testing needs: dynamic security testing, penetration testing
Security and compliance: SAST, encyrption, data protection
User Story: Components:
1) Card - holds the story
2) Conversation - Detailed requirement (what models, what classes, what teams)
3) Confirmation - Acceptance criteria
INVEST
Independent
Negotiable - flexible implementation choices
Valuable
Estimable
Small
Testable
Production:
User Testing/Accepting
Business and Technical Stories are the same, stories
Business stories are dependent.
Story to Epic -> 1 to 1
Technical Story to Epic -> M:1
W3
Snapshots vs Delta-based (Difference) Version Control
W3
Component
A class file/jar file, etc.
Service
Uses protocols
An application outside of core application that communicates with the main application
DI can be done on Componenets and Services.
Coupling
A situation in which a class depends on another concrete class
Tight coupling: Hard to change/modify
Dependency Injection
A system design pattern that connects components into apps
Need for this might not be clear.
if we allows class to create dependences, the parents need to change
Tight coupling
Loosely dependent code
Car is not responsible to creating driver type.
Do your own thing kinda concept
DI implements IOC concept
>> Makes more things modularised, by injecting anything a concrete class needs; rather than making the class create what it needs.
This makes the injected dependency open for extension
✅ Easier to unit test
✅ Java Standard under JSR 330
❌ Difficult to read and debug code
❌ Dependence on DI frameworks
Circular Dependency
Chicken or Egg thing
The solution is to use a setter injection to bypass the circular dependency
Spring Bean lifecycle
Set application context, preDestroy, Destroyed
Spring will manage this for you
Spring Framework
Component-based software
Create/Manage beans
SpringBoot
Helps to abstract from boiler codes
Less monolithic, more microservices
More abstraction, more devops
AutoConfiguration/Classpath
Monolithic
❌ Hard to scale everything is bloated
Microservices
to FrontEnd too
Micro front-end ->
Loose coupling
REST/SOAP
Uses multiprotocols
Streamable HTTP
HTTP Methods
Safe -> Will not change the resource
Idempotent -> Can be called several times with the same results
POST
N
N
GET
Y
Y
PUT
N
N
DELETE
N
N
Best Practices
Use correct verbs for actions
Use only logical nesting for paths
Return appropriate error codes
Version your API, and show major only
MAJOR.MINOR.PATCH
Major ⇒ Breaking Changes
Minor ⇒ (99% updates here - does not affect consumers, backend kinda of stuff)
PATCH ⇒ Bug Fixes (Changelog - Major Version)
In Spring:
@Get/Post Mapping
@ResponseStatus
@RestController
GraphQL
Can specify field, more personalised
Order ala carte
Last updated