From 6dcd1727eb9d5dbfcb8f6e9599ada10d33063bac Mon Sep 17 00:00:00 2001 From: Simeon Simeonov Date: Wed, 18 Jan 2023 21:12:31 +0100 Subject: Remove some old presentations --- reveal.js/flow.html | 194 ---------------------------------------------------- 1 file changed, 194 deletions(-) delete mode 100755 reveal.js/flow.html (limited to 'reveal.js/flow.html') diff --git a/reveal.js/flow.html b/reveal.js/flow.html deleted file mode 100755 index c5b2ef3..0000000 --- a/reveal.js/flow.html +++ /dev/null @@ -1,194 +0,0 @@ - - - - - QA flow - - - - - - - - - - - - - - -
- - -
-
-

QA flow

-

Idas and thoughts

-
-

- Simeon Simeonov -

-
- -
-
-

Agenda

-
-
    -
  • The problem with the current QA flow
    •  -
  • Alternatives
    •  -
  • Suggestions
    •  -
  • Q&A and discussion
    •  -
-
-
- - -
-
-

The problem with the current QA flow

-

“Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” - Wikipedia

-
-

“Accumulation of technical debt is not always a choice.” - Simeon Simeonov, 21st century developer

-
- -
-

The problem with the current QA flow (2)

-
-
    -
  • Based on pull-requests (tactical)
    • -
  • Poor or lack of technical (strategic) design
    • -
  • Lack of supervision
    • -
-
- -
-

The problem with the current QA flow (3)

-
-

Typical challenges

-
    -
  • What entities do we need and how will we name them? (module, package, a script...)
    • -
  • Where will the code reside?
    • -
  • What is the best way to interract? (Object-oriented design in the case of Python)
    • -
  • Is this the best way (even in pragmatic terms)?
    • -
  • Any known best practices?
    • -
-
- -
- - -
-
-

Alternatives

-
-

What do others do?

-
- -
-

Alternatives (2)

-
-

Google, Microsoft...

-
    -
  • Detailed technical design is expensive and requires hierarchial structure
    • -
  • They do not exploit our logistical advantage of being in one place
    • -
-
- -
-

Alternatives (3)

-
-

Linux...

-
    -
  • Brutal and hierarchial structure with a lot of overhead
    • -
  • They do not exploit our logistical advantage of being in one place
    • -
-
- -
- - -
- -
-

Suggestions

-
-
    -
  • Automate most of the current QA tasks through better test coverage, static checking and linting
    • -
  • Modify the QA flow
    • -
  • Consider a more detailed technical specification(s)
    • -
-
- -
-

Automation

-
-
    -
  • better test coverage - as much as possible, something is better than nothing
    • -
  • own flake / pylint modules, as well as disabling the annoying ones as part of CI
    • -
-
- -
-

New QA flow

-
-
    -
  1. Decide whether the task is "strategical" during planning and mark it accordingly in Jira
    2. -
  2. Assign supervising developer once the task is picked
    3. -
  3. Commence the design phase(*)
    4. -
  4. Approval by the supervising developer should be required
    5. -
-
- -
-

New QA flow (2)

-
-

Design phase

-
    -
  1. Identify all entities, entry points and parameters (in case of CLI)
    2. -
  2. Decide on names, naming conventions and where different enteties will reside
    3. -
  3. Decide on code entities and define the public interface (OO design)
    4. -
-
- -
-

A more detailed technical specification?

-
-

May be feasible when developing new systems and micro-services

-
- -
- - -
-

Q&A

-
- - -
-
- - - - - - - - - - - -- cgit v1.3