Giters

isaqb-org / curriculum-foundation

iSAQB Curriculum for the CPSA - Foundation Level. This repository contains copyrighted work.

Home Page:https://public.isaqb.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

LG 03-04 (V2025) Reduce (drastically) the number of exam-relevant design principles

rhoadesre opened this issue · comments

commented

There are way too many principles that are exam relevant. Candidates in my opinion are "conceptual integrity", "simplicity", and "expect errors".

commented

@alxlo and @gernotstarke reviewed the existing principles and found NO candidate suited for deletion.

"Conceptual integrity" has been called by Fred Brooks as the "most important principle", and "simplicity" (KISS) seems
highly relevant these days too...

Therefore I propose to close this issue

commented

In going with the KISS principle, I'd still like to reduce the number of exam-relevant principles.

commented

While I agree in principle, agreeing on which one to cut will be difficult.

To illustrate the point: I'd cut "conceptual integrity" (despite the fact that it was formulated by Brooks) - his definition is vague at best and esoteric at worst. If large projects depend on this, I'd consider an antipattern.

While I also value "simplicity", we probably don't agree what it means.

commented

Like many other topics, simply reduce the number of required principles and make the rest R3. Then every trainer can emphasize the principles they want. There was already agreement on what is test relevant.

commented

FLWG:

  • expect errors -> R3
  • abstractions (R2), other subtopics
    • models (see also #429)
    • (abstract) interfaces
    • patterns
  • SOLID: remove term, cherry-pick (remove SLI, keep OD)
  • replace simplicity by "reduce complexity (R1-R3)"
    • remove subgoal "as a means to reduce complexity (R1)"
    • KISS, YAGNI -> R3
    • move CUPID as subgoal here
  • remove "other principles"
commented

I remember the discussion about removing SOLID and keep only some of the principles. I agree to keep O and D and remove S and L. But why should we remove Interface segregation? That still makes sense for me not only for object oriented interfaces but also for all kind of APIs (multiple small interfaces than one).

commented

imho "interface segregation" is overly specific to be a general rule. Consider e.g. GraphQL interfaces, or interfaces having JSON or similar payloads - makes no sense in applying this "I" principle here. Therefore I'm still in favor of removing it