From 6ec8af1640dbc3224a2181eddd5b2367cbf88260 Mon Sep 17 00:00:00 2001 From: pintergreg Date: Tue, 12 Nov 2024 14:18:28 +0000 Subject: [PATCH] deploy: f6d584eef7e0b935826f813181bd9f882a35015f --- slides/summary_full.html | 2684 ++++++++++++++++++++++++++++++++++++ slides/summary_week04.html | 380 +++++ 2 files changed, 3064 insertions(+) create mode 100644 slides/summary_full.html create mode 100644 slides/summary_week04.html diff --git a/slides/summary_full.html b/slides/summary_full.html new file mode 100644 index 0000000..677250d --- /dev/null +++ b/slides/summary_full.html @@ -0,0 +1,2684 @@ + + + + + + + summary + + + + + + + + + + + + + + + + +
+
+ +
+

summary

+

Gergő Pintér, PhD

+

gergo.pinter@uni-corvinus.hu

+
+ +
+

program is like a recipe

+
+
+
    +
  • executing a program is following a recipe
    • +
  • programming is like creating a recipe
    • +
+
+
    +
  • software development is like running a restaurant +
      +
    • come up with recipes,
      • +
    • cook the food,
      • +
    • ingredient logistics and preparation,
      • +
    • food serving,
      • +
    • marketing,
      • +
    • cleaning
      • +
    • +
+
+
+
+
+

+
+
+

+
+
+
+
+
+ +
+

software development often compared to house building

+
+
+
    +
  • because it is an engineering discipline
    • +
  • but software does not have to obey the laws of physics
    • +
  • software design should focus only on the data structures and the +connection between the modules +
      +
    • not the implementation details
      (e.g., hardware)
      • +
    • +
+
+
+

+
+
+
+
+ +
+

software development is more like gardening

+
+
+
    +
  • a garden might be planned
    • +
  • external factors influence the result +
      +
    • weather, pests
      • +
    • +
  • garden needs constant care to bloom
    • +
  • sometimes also experimentation +
      +
    • methods, tools
      • +
    • +
  • garden is like an art (with function)
    • +
+
+
+

+
+
+
+
+ +
+

software growth

+
+
+
    +
  • number of lines of code is increasing +
      +
    • which increases complexity
      • +
    • +
  • “every line of code written comes at a price: maintenance” [1] +
      +
    • larger garden, more gardening
      • +
    • +
  • software development processes to handle the complexity
    • +
+
+
+

+
+
+
+
+ +
+
+

evolution of software life cycle models (incomplete)

+
+
+
    +
  • software life cycle models +
      +
    • waterfall +
        +
      • improved waterfall
        • +
      • +
    • V model
      • +
    • iterative
      • +
    • agile
      • +
    • +
  • regarding to change management
    • +
+
+
+

+
+
+
+
+
+

waterfall model

+
+
+
    +
  • sequential, rigid model +
      +
    • (originally) not possible to step back to a previous phase
      • +
    • +
  • testing is after the implementation, errors are found late in the +process
    • +
  • not possible to make changes during the development
    • +
  • could take years
    • +
+
+
+

+

+
+
+
+
+
+

V model

+
+
+
    +
  • still rigid
    • +
  • each phase has output and a review process +
      +
    • errors are found at early stage
      • +
    • decreases the risk of failure
      • +
    • +
  • large to small: testing is done in a hierarchical perspective
    • +
+
+
+

+
+
+
+
+
+

iterative model

+
+
+
    +
  • software is built incrementally, +
      +
    • with each iteration adding new features or refining existing +ones
      • +
    • +
  • possible to get feedback after each iteration
    • +
  • can be rigid within an iteration
    • +
+
+
+

+
+
+
+
+
+

agile model

+
+
+
    +
  • continuous collaboration and fast response to change, while the +iterative model takes a more gradual approach, building up the final +product over multiple iterations
    • +
  • scrum is an agile methodology
    • +
+
+
+

+
+
+
+
+
+
+

scrum team

+
    +
  • optimally 3 to 9 people
    • +
  • cross-functional
    • +
  • self-organizing
    • +
+
+
+

roles

+
    +
  • scrum master +
      +
    • responsible establishing scrum as defined in the Scrum Guide +
        +
      • by helping everyone understand the theory and practice, both within +the scrum team and the organization
        • +
      • +
    • responsible for the scrum team’s effectiveness
      • +
    • +
  • product owner +
      +
    • responsible for maximizing the value of the product resulting from +the work of the scrum team
      • +
    • also responsible for effective product backlog management
      • +
    • +
  • developers
    • +
+
+
+

sprint planning

+
    +
  • initiates the sprint
    • +
  • maximum of eight hours for a one-month sprint
    • +
  • define a sprint goal +
      +
    • definition of done
      • +
    • +
  • it is up to the developers how to turn product backlog items into +increments
    • +
+

+
+ +
+

sprint

+
    +
  • 1-4 week long
    • +
  • considered a short project
    • +
  • turns backlog items into increments
    • +
  • includes daily scrum
    • +
+

+
+ +
+

sprint review

+
    +
  • scrum team presents the their work to the stakeholders +
      +
    • increment is evaluated
      • +
    • +
  • the attendees collaborate on what to do next
    • +
  • maximum of four hours for a one-month sprint
    • +
+

+
+ +
+

sprint retrospective

+
    +
  • concludes the sprint
    • +
  • maximum of three hours for a one-month sprint
    • +
  • the scrum team discusses what went well/bad, what problems +encountered
    • +
+

+
+ +
+

kanban

+
+
+
    +
  • uses a visual workflow
    • +
  • pull-based system +
      +
    • no task in the workflow without request
      • +
    • +
  • uses columns for states of the product
    • +
  • defines conditions when to move a task between columns
    • +
  • conditions flow +
      +
    • no iterations (sprints)
      • +
    • no roles
      • +
    • +
  • encourages to improve the workflow
    • +
+
+

+
+
+
+ +
+
+

steps of requirement analysis

+
+
+based on [2] + +
+
+
+
+

functional and non-functional requirements

+
+
+
    +
  • functional requirements define
    what a system is +supposed to do
    • +
  • non-functional requirements define
    how a system +is supposed to operate +
      +
    • e.g., legal requirements (GDPR)
      • +
    • +
+ +
+

+
+
+
+
+

minimum viable product

+
+
+

+
+

+
+

+
+
+
+
+

+
+

+
+

+
+
+
+

based on Making +sense of MVP (Minimum Viable Product) by Henrik Kniberg

+
+
+ +
+

what is a user story?

+
+
    +
  • a popular tool in requirements analysis, particularly in agile +software development methodologies
    • +
  • simple description of a software feature +
      +
    • from the perspective of the end user or customer
      • +
    • +
  • and are often accompanied by acceptance criteria (BDD), +
      +
    • which define the conditions that must be met to be considered +complete
      • +
    • +
+
+
+

as a [type of user], I want to +[action/function] in order to +[benefit/value]

+
+
+ +
+

behaviour-driven development

+
+
+
    +
  • BDD starts from a user story and
    focuses on adding acceptance +criteria
    • +
  • extends user stories how the software should react in some with +scenarios (conditions)
    • +
+
+
Title (one line describing the story)
+
+Narrative:
+As a [role]
+I want [feature]
+So that [benefit]
+
+Acceptance Criteria:
+(presented as Scenarios)
+
+Scenario 1: Title
+Given [context]
+  And [some more context]...
+When  [event]
+Then  [outcome]
+  And [another outcome]...
+
+Scenario 2: ...
+
+
+
+ +
+
+

user story mapping

+
+
+
    +
  • performed in workshops including +
      +
    • users,
      • +
    • (UI) designers,
      • +
    • developers,
      • +
    • testers,
      • +
    • and stakeholders
      • +
    • +
  • build a shared understanding of the product and a common +language
    • +
  • living document
    • +
+
+

+
+
+
+
+

user story mapping mistakes

+
+
+

+
+
+
+

+
+
+

+
+
+

+
+
+
+
+
+

more from Jeff Patton: 5 story +mapping mistakes

+
+
+
+

wireframe

+
+
+
    +
  • a wireframe is an outline / blueprint / concept art of a webpage or +application
    • +
  • can be hand drawn on paper or built out digitally
    • +
  • provides visual understanding of page structure, layout, user flow, +functionality and intended behaviours
    • +
  • presented to stakeholders before the interface is coded
    • +
+
+

source: [3]

+
+
+

+
+
+
+ +
+

types of wireframes

+
+
+
+low-fidelity + +
+
+
+ + +
+
+
+high-fidelity + +
+
+
+
+ +
+

wireframe map

+

+
+

shows user flow, ~ user story map flow

+
+
+ +
+

wireframing

+
+
+
    +
  • responsibility of the UI/UX designers
    • +
  • occurs during the exploratory design phase +
      +
    • experimenting
      • +
    • +
  • iterative process
    • +
  • iterations are presented to the stakeholders to gain feedback
    • +
  • some professional tools: Figma, +Balsamiq, Sketch +
      +
    • any drawing/diagramming tool can be used +for the low or mid fidelity wireframes
      • +
    • +
+
+
+Interaction Design Foundation [4] | CC BY-SA 4.0 + +
+
+
+
+

based on: [3]

+
+
+ +
+

software design and architecture stack

+
+based on Khalil Stemmel’s figure [5] + +
+
+ +
+
+

gang of four (GoF) design patterns

+
    +
  • GoF: Erich Gamma, Richard Helm, Ralph Johnson, and John +Vlissides
    • +
  • 23 common software design patterns +
      +
    • published in “Design Patterns: Elements of Reusable Object-Oriented +Software” (1994) [6]
      • +
    • +
  • provides solutions to common design problems
    • +
  • categorized into three main groups +
      +
    1. creational
      2. +
    2. structural
      3. +
    3. behavioral
      4. +
    • +
+
+

read about the design patterns in details, for example at refactoring.guru

+
+
+
+

GoF design patterns in functional programming

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OO patternFP pattern
factory patternfunction
strategy patternfunction
decorator patternfunction
visitor patternfunction
……
+

Peter Norvig demonstrated that 16 +out of the 23 patterns are simplified or eliminated by language features +in Lisp or Dylan (1998) [7]

+

more +about it from Scott Wlaschin [8]

+
+
+

SOLID principles

+

SOLID is a mnemonic acronym for five +design principles intended to make object-oriented designs more +understandable, flexible, and maintainable [9]

+
+
single responsibility principle
+
+a class should do one thing and therefore it +should have only a single reason to change +
+
open-closed principle
+
+classes should be open for extension and +closed to modification +
+
Liskov substitution principle
+
+if class A is a subtype of class B, B should +be able to replaced with A without disrupting the behavior of the +program +
+
interface segregation principle
+
+many client-specific interfaces are better +than one general-purpose interface. Clients should not be forced to +implement a function they do no need. +
+
dependency inversion principle
+
+modules should depend upon interfaces or +abstract classes, not concrete classes. It’s an inversion because +implementations depend upon abstractions and not the other way +round +
+
+
+

based on [10], [11]

+
+
+ +
+

coupling

+
+
+
    +
  • the degree of interdependence between software modules
    • +
  • coupling is usually contrasted with cohesion +
      +
    • low coupling often correlates with high cohesion, and vice +versa
      • +
    • +
+
+
+ + +
+
+
+
+

source Wikipedia +[12]

+
+
+ +
+

architectural styles / topologies

+
+
+

+

+
+

+
+

+

+
+
+
+ +
+

architectural patterns

+
+
+
+MVC + +
+
+

ASP.NET, Django (Python), Ruby on Rails, Laravel (PHP)

+
+
+
+MVP + +
+
+

Windows Forms, Java Swing

+
+
+
+MVVM + +
+
+

WPF, AngularJS

+
+
+
+
+
    +
  • view is responsible for rendering UI
    • +
  • controller responds to the user input (in MVC) and performs +interactions on the data model
    • +
  • model is responsible for managing the data
    • +
+
+
+ +
+

interface is an agreement

+
+
+
    +
  • how a module / component will work
    • +
  • so as long as the agreement is complied the components do not need +to know about the internal structure/work of the other components +
      +
    • separation of concerns
      • +
    • single responsibility principle
      • +
    • the other component can be replaced, mocked
      • +
    • +
+
+

+
+
+
+ +
+
+

interface changes should be communicated

+
+
+
+
    +
  • during design / development +
      +
    • change can be necessary / allowed, but communicate towards the +impacted teams
      • +
    • diagrams show inner dependencies
      • +
    • +
+
+
+
    +
  • services announce API deprecations
    • +
  • so as library / framework developers +
      +
    • can be a source of new issues even if downstream code is not +changed
      • +
    • +
+
+
+

+
+
+
+
+

API versions

+
+
+

+
+

+
+
+
+

https://developers.facebook.com/v21.0/me?fields=id,name

+
+
def unary_union(self):
+    warnings.warn(
+        "The 'unary_union' attribute is deprecated, "
+        "use the 'union_all' method instead.",
+        DeprecationWarning,
+        stacklevel=2,
+    )
+    return self.union_all()
+
+
+
+

implementation planning

+
    +
  1. define goals +
      +
    • practically done with requirement analysis
      • +
    2. +
  2. conduct research +
      +
    • partially done at the requirement elicitation phase
      • +
    3. +
  3. map out risks
    4. +
  4. schedule milestones
    5. +
  5. assign responsibilities and tasks
    6. +
  6. allocate resources
    7. +
+
+

based on What is an +implementation plan? 6 steps to create one [13]

+
+
+
+

learning could be a task

+
+
+
    +
  • you may need to work a technology / framework / language that you +are not familiar with
    • +
  • that may require research +
      +
    • fail fast
      • +
    • document findings +
        +
      • minimal workable example
        • +
      • +
    • +
  • or you just have to learn a new codebase
    • +
  • calculate with learning during the planning
    • +
+
+

+
+
+
+
+
+

identify and prioritize risks

+

a risk is a possibility that something bad can happen

+
    +
  • there is risk inherent with building any piece of software
    • +
  • whether you’re building a completely new greenfield project,
    • +
  • or adding a new feature to an existing codebase +
      +
    • other parts cease to work
      • +
    • the new feature alienate users
      • +
    • data loss
      • +
    • +
  • often difficult to prioritise which risks you should take care of +
      +
    • the probability: how likely is it that the risk will happen?
      • +
    • and the impact: what is the negative impact if the risk does +occur?
      • +
    • +
+
+

based on riskstorming.com | +CC BY 4.0

+
+
+
+

risk storming

+
+
+
    +
  • visual and collaborative risk identification technique
    • +
  • created by Simon Brown (author of C4 model)
    • +
  • motivation: often only one person evaluated risks
    • +
  • risk evaluation should be collaborative activity
    • +
+
+

+
+
+
+

based on riskstorming.com | +CC BY 4.0

+
+
+
+

risk register

+
+
+
    +
  • a risk register is a document used as a risk management tool
    • +
  • contains all identified risks with additional information +
      +
    • category, name, responsible, probability, impact, mitigation, action +by, action when
      • +
    • +
  • it can be displayed as a table or as a scatterplot
    • +
+
+
+by Hou710 | CC BY-SA + +
+
+
+
+ +++++++ + + + + + + + + + + + + + + + + + + + + + + + + + +
RiskImpact
(1-3)		Likelihood
(0-10)		Risk
(I * L)		Mitigation
Rust Language Changes2714Target a specific Rustc version
Missing GCC 13 upstream window166Merge in GCC 14 and be proactive about reviews
+
+
+
+

schedule milestones

+
+
+
    +
  • visualize project milestones +
      +
    • Gantt chart
      • +
    • +
  • keep the entire team posted
    • +
  • pay attention to holidays +
      +
    • multiple countries in the case of an international team
      • +
    • +
  • things won’t go as planned, so +
      +
    • add safety margin (wiggle room)
      • +
    • e.g., an extra week before deadline for fixing bugs
      • +
    • +
+
+
+ + +
+
+
+
+ +
+
+

assign responsibilities and tasks

+
+
+
    +
  • every task you want to make done should have exactly one person +responsible +
      +
    • no assignee – no one will do it
      • +
    • more than one – “I though the other one was doing it”
      • +
    • +
  • define area of responsibility +
      +
    • a task (as in scrum) should have definition of done, which specifies +it
      • +
    • +
  • everyone needs to know what other people are responsible for +
      +
    • scrum/kanban board can visualize it
      • +
    • issue/ticket trackers can also work
      • +
    • +
+
+

+

at the end of a sprint planning, every task in the sprint backlog +should have an assignee

+
+
+
+

source: [14]

+
+
+
+

dependencies

+
+
+
+
+

+
+
+

+
+
+
+

+
+
+
+
+
+

allocate resources

+
+
+
    +
  • scrum (and agile in general) does not say anything about +how to estimate (time)
    • +
  • story points are often used instead +
      +
    • (relative) unit of effort required to fully implement a product +backlog item
      • +
    • e.g., 1–5,
      • +
    • Fibonacci: 1, 2, 3, 5, 8, 13…
      • +
    • powers of 2: 1, 2, 4, 8, 16, 32…
      • +
    • +
+
+
+ + +
+
+
+
+

“Story points reward team members for solving problems based on +difficulty, not time spent. This keeps team members focused on shipping +value, not spending time [15].”

+
+
+
+

estimation is guessing

+
+
+
    +
  • many developers do not like to estimate
    • +
  • seemingly simple task can turn out to be difficult +
      +
    • some difficulties are hard to foresee
      • +
    • bad architectural decision +
        +
      • “Adding manpower to a late software +project makes it later.” – Fred Brooks
        • +
      • +
    • +
  • make educated guesses instead +
      +
    • measure +
        +
      • burn down charts, cumulative flow +diagram
        • +
      • +
    • infer from previous tasks
      • +
    • +
+
+

+
+
+
+
+

code quality

+
+
+
agile
+
+working software over comprehensive documentation +
+
+
+
+
+
software craftmanship
+
+not only working software, but also well-crafted software +
+
+
+
+
+
+
well-crafted
+
+
    +
  • high quality
    • +
+
+
+
    +
  • well-designed
    • +
+
+
+
    +
  • validated and verified
    • +
+
+
+
    +
  • tested
    • +
+
+
+
    +
  • code is clean, easy to understand and maintain
    • +
+
+
+
+
+
+ +
+
+

code smell

+
+

a code smell is a surface indication that usually corresponds to a +deeper problem

+

– Martin Flower [16]

+
+
+
+

software rot is the degradation, deterioration, or loss of the use or +performance of software over time [17]

+
+

requirement smell: signs in the requirements that +are not necessarily wrong but could be problematic [18]

+
+
+
+
+

clean clode violations as code smells

+
+
+
    +
  • long method
    • +
  • long parameter list
    • +
  • naming +
      +
    • notation in names
      • +
    • inconsistent names
      • +
    • uncommunicative names
      • +
    • +
  • comments
    • +
  • large class +
      +
    • possibly do more than one thing
      • +
    • +
  • a function / class does more than one thing
    • +
+
+
    +
  • magic number
    • +
  • duplicated code
    • +
  • speculative generality
    • +
  • dead code
    • +
  • too complexity comditions
    • +
  • feature envy
    • +
  • bad comment +
      +
    • obsolete, redundant (noise), commented-out code
      • +
    • +
+
+
+
+

source: [19], [20]

+
+
+
+
+

how to measure code quality?

+

it is hard to objectively measure the quality of code

+
+
+
    +
  • number of source lines of code +(SLOC)
    • +
  • style guide compliance – is the code clean?
    • +
  • Halstead metrics
    • +
  • cyclomatic complexity – is the code simple?
    • +
  • maintainability index
    • +
  • test coverage – is the code tested?
    • +
+
+

+
+
+
+
+

cyclomatic comlexity

+
    +
  • developed by Thomas J. McCabe in 1976
    • +
  • quantitative measure of the number of linearly independent paths +through the source code
    • +
  • computed using the control-flow graph of the program
    • +
+

defined as:

+

M=E−N+2P M = E - N + 2P

+
+
    +
  • E: the number of edges of the graph
    • +
  • N: the number of nodes of the graph
    • +
  • P: the number of connected components +
      +
    • for a single method, P always equals 1
      • +
    • +
+
+
+
+

cyclomatic comlexity – example

+
+
+
def calculate_progress(
+    finished: int,
+    total: int,
+    as_percentage: bool,
+    foo: bool
+) -> float:
+    progress = finished / total
+
+    if as_percentage and foo:
+        return progress * 100
+    else:
+        return progress
+
+
+

activity diagram

+
+

+
+
+

control flow

+
+

+
+
+
+

CC=E−N+2 CC = E - N + 2 +CC=7−6+2 CC = 7 - 6 + 2 +CC=3 CC = 3

+
+
+
+

WTF per minute

+
+ + +
+
+ +
+
+

V model [21]

+
+
+
    +
  • each phase has output and a review process +
      +
    • errors are found at early stage
      • +
    • decreases the risk of failure
      • +
    • +
  • testing is done in a hierarchical perspective
    • +
+
+
+
+ + +
+
+
+
+
+
+

requirement analysis review

+
+
+
+ + +
+
+
    +
  • can be discussed / reviewed
    • +
  • even with a customer representative
    • +
+
+
+

+
+
+user story “reviewed” in an issue tracker + +
+
+
+
+
+

architecture review

+
+
+
+C4 diagrams as the output of the high level design + +
+
+

+
+
+risk storming as a review process + +
+
+
+
+
+

code review

+
+
+
def query_progress(user_id:int) -> float:
+    # establish connection
+    con= sqlite3.connect("data.db")
+    # build query
+    progress_query = f"""
+    SELECT
+        lesson / 50.0 AS progress
+    FROM activity
+    WHERE
+        user_id = {user_id} AND
+        result = 'success'
+    ORDER BY
+        lesson DESC
+    LIMIT 1
+    ;
+    """
+    # execute query
+    res =con.execute(progress_query)
+    progress=res.fetchone()[0]
+    return progress
+
+
    +
  • does not respect style guide
    • +
  • does 3 things +
      +
    • establish DB connection
      • +
    • build query
      • +
    • execute query
      • +
    • +
  • contains separation comments
    • +
  • hard coded divisor +
      +
    • magic number
      • +
    • +
+
+
+
+
+

+
+

every work product can and should be reviewed

+
+
+
+

review types by formality

+ +++++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
typeformalityled byeffortdocumentation
informalnot formalnooneminimalundocumented
walkthroughnot formal1authorsvery lownormal, fault-finding
technicalless formaltrained moderator, not the authormoderatemore detailed
inspectionmost formaltrained moderatorhighthorough; based on standards, +checklists
+
+ +
+

review – author’s perspective

+
    +
  • be humble +
      +
    • mind that everybody’s code can be improved
      • +
    • you are not perfect, accept that you will make mistakes
      • +
    • +
  • open to feedback
    • +
  • you are not your code
    • +
  • the goal is to deliver higher quality code, not about arguing who +was right +
      +
    • you and the reviewer are in the same side
      • +
    • +
  • you and the reviewer are not only talking about the code, +
      +
    • you are exchanging best practices and experiences
      • +
    • +
  • you can learn from the review
    • +
+
+

source: Code Review +Guidelines for Humans [22]

+
+
+ +
+

review – reviewer’s perspective

+
    +
  • use I-messages
    • +
  • talk about the code, not the coder
    • +
  • ask questions instead of making statements
    • +
  • refer to the behavior, not the traits of the author
    • +
  • accept that there are different solutions
    • +
  • respect and trust the author
    • +
  • mind the OIR-rule of giving feedback +
      +
    • observation, impact, request
      • +
    • +
  • before giving feedback, ask yourself: +
      +
    • is it true? (opinion != +truth)
      • +
    • is it necessary? (avoid nagging, focus on +the current work product)
      • +
    • is it kind? (no shaming)
      • +
    • +
  • be humble; you are not perfect and you can also improve
    • +
  • it’s fine to say: Everything is good!
    • +
  • don’t forget to praise
    • +
+
+

source: Code Review +Guidelines for Humans [22]

+
+
+ +
+
+

V model [21]

+
+
+
    +
  • each phase has output and a review process +
      +
    • errors are found at early stage
      • +
    • decreases the risk of failure
      • +
    • +
  • testing is done in a hierarchical perspective
    • +
  • review is a testing process usually without executing the code
    • +
+
+

+
+
+
+
+

test pyramid

+
+
+

+
+
+
+

+
+
+

+
+
+
+
+
+

the turtle and rabbit figures by Delapouite under CC BY 3.0 via game-icons.net

+
+
+
+
+

what is a unit?

+
    +
  • defined as a single behaviour exhibited by the +system under test +
      +
    • usually corresponding to a requirement
      • +
    • +
  • often corresponds to a function or a module / method or a class +
      +
    • depending on the paradigm
      • +
    • often, but not always
      • +
    • +
  • “only entry points to externally-visible system behaviours define +units” +
      +
    • by Kent Beck [23]
      • +
    • +
+
+

a unit test is another piece of code, that tests the given unit

+
+
+
+

arrange, act, assert(, annihilate) pattern

+

parts of a unit test

+
+
+
+
arrange
+
+set up the testing environment (e.g., create objects) +
+
act
+
+call the tested unit +
+
assert
+
+compare the result of the ‘act’ step to the expected value +
+
(annihilate)
+
+free resources +
+
+automatic in modern languages +
+
+
+
def test_fizzbuzz():
+    # arrange
+    test_input = 3
+    # act
+    result = fizzbuzz(test_input)
+    # assert
+    assert result == "Fizz"
+
+
+
+
+
+

mocking

+
+
+
    +
  • the whole unit test suite should be able to run in +milliseconds +
      +
    • to give immediate feedback
      • +
    • +
  • slow elements of the software should be mocked +
      +
    • e.g., database, network connection
      • +
    • +
  • part of arrange step
    • +
+
+

+
+
+
+
+

test doubles – mock object types

+

there is no open standard for categories

+
+
+
    +
  • dummy
    • +
  • stub
    • +
  • spy
    • +
  • mock
    • +
  • fake
    • +
+
+
+ + +
+
+
+
+

these are from the book xUnit test patterns: Refactoring test +code – by Gerard Meszaros [25]

+
+
+
+
+

test-driven development (TDD)

+
+
+
    +
  • write test before writing the tested code
    • +
  • without the called unit the test fill fail +
      +
    • the called function does not exist
      • +
    • +
  • write code, that makes the test pass
    • +
  • improve the code quality +
      +
    • e.g., make it clear and clean
      • +
    • both the test and tested code
      • +
    • +
+
+

+
+
+
+
+

+
+

As the tests get more specific, the code gets more generic.

+

– Robert C. Martin, The +Cycles of TDD [26]

+
+

+
+
+
+

test coverage

+
    +
  • the percentage of the code lines ‘protected’ or covered by +tests
    • +
+
+
+

code/fizzbuzz.py

+
+
+
def fizzbuzz(i: int) -> str:
+    result = ""
+    if i % 15 == 0:
+        result += "FizzBuzz"
+    elif i % 3 == 0:
+        result += "Fizz"
+    elif i % 5 == 0:
+        result += "Buzz"
+    else:
+        result = str(i)
+    return result
+
+
+
def fizzbuzz(i: int) -> str:
+    result = ""
+    if i % 15 == 0:
+        result += "FizzBuzz"
+    elif i % 3 == 0:
+        result += "Fizz"
+    elif i % 5 == 0:
+        result += "Buzz"
+    else:
+        result = str(i)
+    return result
+
+
+
def fizzbuzz(i: int) -> str:
+    result = ""
+    if i % 15 == 0:
+        result += "FizzBuzz"
+    elif i % 3 == 0:
+        result += "Fizz"
+    elif i % 5 == 0:
+        result += "Buzz"
+    else:
+        result = str(i)
+    return result
+
+
+
+

code/test_fizzbuzz.py

+
+
+
from fizzbuzz import fizzbuzz
+
+
+def test_fizzbuzz():
+    assert fizzbuzz(15) == "FizzBuzz"
+    assert fizzbuzz(3) == "Fizz"
+
+
+
from fizzbuzz import fizzbuzz
+
+
+def test_fizzbuzz():
+    assert fizzbuzz(15) == "FizzBuzz"
+    assert fizzbuzz(3) == "Fizz"
+    assert fizzbuzz(5) == "Buzz"
+
+
+
from fizzbuzz import fizzbuzz
+
+
+def test_fizzbuzz():
+    assert fizzbuzz(15) == "FizzBuzz"
+    assert fizzbuzz(3) == "Fizz"
+    assert fizzbuzz(5) == "Buzz"
+    assert fizzbuzz(17) == "17"
+
+
+
+
+
+
+

test coverage: 70%

+
+
+

test coverage: 90%

+
+
+

test coverage: 100%

+

four control flow branch, all of them needs to be tested

+
+
+ +
+
+

how to measure code quality?

+

it is hard to objectively measure the quality of code

+
+
+
    +
  • number of source lines of code +(SLOC)
    • +
  • style guide compliance – is the code clean?
    • +
  • Halstead metrics
    • +
  • cyclomatic complexity – is the code simple?
    • +
  • maintainability index
    • +
  • test coverage – is the code tested?
    • +
+
+

+
+
+
+
+

what to test - the edge cases

+
+
+
def calculate_progress(
+    finished: int,
+    total: int,
+    as_percentage: bool,
+) -> float:
+    progress = finished / total
+
+    if as_percentage:
+        return progress * 100
+    else:
+        return progress
+
+

this function need some value checking

+
+
+
+
what does this function do?
+
+
    +
  • divides the number of finished lessons by the total number of +lessons
    • +
+
+
+
    +
  • returns progress in the closed interval of [0, 1] or [0, 100]
    • +
+
+
+
+
+
edge cases
+
+
    +
  • total is 0
    • +
+
+
+
    +
  • total is less than 0
    • +
+
+
+
    +
  • finished is less than 0
    • +
+
+
+
    +
  • finished is greater than total
    • +
+
+
+
+
+
+
+

test coverage only measures that every control flow branch is +tested

+

the point of testing is testing for the edge cases

+
+
+
+

changing the software

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
add featurefix a bugrefactoroptimize
structurechangeschangeschanges
new funcionalitychanges
functionalitychanges
resource usagechanges
+
+

Michael Feathers, Working Effectively with Legacy Code: part 1 pp 6 +[27]

+
+
+ +
+

testing approaches

+
+
+

black box

+

+
    +
  • examining / testing the functionality without knowing the inner +structure
    • +
  • works at all levels: unit, integration, system, acceptance
    • +
  • also for debugging a legacy code
    • +
+
+

white box

+

+
    +
  • testing the internal structure as opposed to its functionality
    • +
  • often associated to unit testing, but also works on higher levels +(i.e., integration, system)
    • +
+
+
+
+ +
+

references

+
+
+
[1]
tef, “Write code that is easy to delete, +not easy to extend.” + https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to +, 13-Feb-2016.
+
+
+
[2]
A. +Krysik, “SDLC guide: Requirement analysis in software +engineering.” + https://stratoflow.com/requirements-analysis +, 24-Nov-2023.
+
+
+
[3]
L. +Bruton, “What is wireframing? A complete guide.” + https://www.uxdesigninstitute.com/blog/what-is-wireframing/ +, 08-Sep-2022.
+
+
+
[4]
Interaction Design Foundation, “What are +prototypes?” + https://www.interaction-design.org/literature/topics/prototypes +, 17-Oct-2019.
+
+
+
[5]
K. +Stemmler, “How to learn software design and architecture.” + + https://khalilstemmler.com/articles/software-design-architecture/full-stack-software-design +, 28-Sep-2019.
+
+
+
[6]
E. +Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: +Elements of reusable object-oriented software. Pearson +Education, 1994.
+
+
+
[7]
P. +Norvig, “Design patterns in dynamic languages.” + http://www.norvig.com/design-patterns/ +, 17-Mar-1998.
+
+
+
[8]
S. +Wlaschin, “Functional programming design patterns.” + https://fsharpforfunandprofit.com/fppatterns/ +, Dec-2014.
+
+
+
[9]
Wikipedia contributors, “SOLID — +Wikipedia, the free encyclopedia.” https://en.wikipedia.org/w/index.php?title=SOLID&oldid=1237710587, +2024.
+
+
+
[10]
S. +Millington, “A solid guide to SOLID principles.” + https://www.baeldung.com/solid-principles +, 05-Feb-2019.
+
+
+
[11]
S. +Oloruntoba and A. S. Walia, “SOLID: The first 5 principles of +object oriented design.” + https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design +, 23-Apr-2024.
+
+
+
[12]
Wikipedia contributors, “Coupling +(computer programming) — Wikipedia, the free +encyclopedia.” https://en.wikipedia.org/w/index.php?title=Coupling_(computer_programming)&oldid=1245630908, +2024.
+
+
+
[13]
T. +Asana, “What is an implementation plan? 6 steps to create +one.” + https://asana.com/resources/implementation-plan +, 06-Jan-2024.
+
+
+
[14]
P. +Paquet, “When everyone is responsible, no one is +responsible.” + https://medium.com/@philippelyp/when-everyone-is-responsible-no-one-is-responsible-73e9a179237f +, 07-Oct-2019.
+
+
+
[15]
D. +Radigan, “Story points and estimation.” + https://www.atlassian.com/agile/project-management/estimation +.
+
+
+
[16]
M. +Fowler, “Code smell.” + https://martinfowler.com/bliki/CodeSmell.html +, 09-Feb-2006.
+
+
+
[17]
Wikipedia contributors, “Software rot — +Wikipedia, the free encyclopedia.” + https://en.wikipedia.org/w/index.php?title=Software_rot&oldid=1236668404 +, 2024.
+
+
+
[18]
H. +Femmer, D. M. Fernández, S. Wagner, and S. Eder, “Rapid quality +assurance with requirements smells,” Journal of Systems and +Software, vol. 123, pp. 190–213, 2017.
+
+
+
[19]
J. +Atwood, “Code smells.” + https://blog.codinghorror.com/code-smells/ +, 18-May-2006.
+
+
+
[20]
R. +C. Martin, Clean code: A handbook of agile software +craftsmanship. Pearson Education, 2009.
+
+
+
[21]
K. +Forsberg and H. Mooz, “The relationship of system engineering to +the project cycle,” Center for Systems Management, vol. +5333, 1991.
+
+
+
[22]
P. +Hauer, “Code review guidelines for humans.” + https://phauer.com/2018/code-review-guidelines/ +, 31-Jul-2018.
+
+
+
[23]
K. +Beck, Test driven development: By example. Addison-Wesley +Professional, 2002.
+
+
+
[24]
M. +Seemann, “Unit testing: Exploring the continuum of test +doubles.” + https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/september/unit-testing-exploring-the-continuum-of-test-doubles +, 2007.
+
+
+
[25]
G. +Meszaros, xUnit test patterns: Refactoring test code. Pearson +Education, 2007.
+
+
+
[26]
R. +C. Martin, “The cycles of TDD.” + http://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html +, 17-Dec-2014.
+
+
+
[27]
M. +Feathers, Working effectively with legacy code. Prentice Hall +Professional, 2004.
+
+
+
+ +
+
+
    +

  1. Sometimes it can be somewhat formal.↩︎

    2. +
+
+
+
+ + + + + + + + + + + + diff --git a/slides/summary_week04.html b/slides/summary_week04.html new file mode 100644 index 0000000..45c1f26 --- /dev/null +++ b/slides/summary_week04.html @@ -0,0 +1,380 @@ + + + + + + + week 4 summary + + + + + + + + + + + + + + + + +
+
+ +
+

week 4 summary

+

Gergő Pintér, PhD

+

gergo.pinter@uni-corvinus.hu

+
+ +
+

wireframe

+
+
+
    +
  • a wireframe is an outline / blueprint / concept art of a webpage or +application
    • +
  • can be hand drawn on paper or built out digitally
    • +
  • provides visual understanding of page structure, layout, user flow, +functionality and intended behaviours
    • +
  • presented to stakeholders before the interface is coded
    • +
+
+

source: [1]

+
+
+

+
+
+
+ +
+

types of wireframes

+
+
+
+low-fidelity + +
+
+
+ + +
+
+
+high-fidelity + +
+
+
+
+ +
+

wireframe map

+

+
+

shows user flow, ~ user story map flow

+
+
+ +
+

wireframing

+
+
+
    +
  • responsibility of the UI/UX designers
    • +
  • occurs during the exploratory design phase +
      +
    • experimenting
      • +
    • +
  • iterative process
    • +
  • iterations are presented to the stakeholders to gain feedback
    • +
  • some professional tools: Figma, +Balsamiq, Sketch +
      +
    • any drawing/diagramming tool can be used +for the low or mid fidelity wireframes
      • +
    • +
+
+
+Interaction Design Foundation [2] | CC BY-SA 4.0 + +
+
+
+
+

based on: [1]

+
+
+ +
+

references

+
+
+
[1]
L. +Bruton, “What is wireframing? A complete guide.” + https://www.uxdesigninstitute.com/blog/what-is-wireframing/ +, 08-Sep-2022.
+
+
+
[2]
Interaction Design Foundation, “What are +prototypes?” + https://www.interaction-design.org/literature/topics/prototypes +, 17-Oct-2019.
+
+
+
+
+
+ + + + + + + + + + + +