Slide 1

Slide 1 text

How to Write Unmaintainable Code

Slide 2

Slide 2 text

#me

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

Less Lines of Code Self-Documenting Code Work with Objects My Goals 15 Years Ago

Slide 19

Slide 19 text

show blog post

Slide 20

Slide 20 text

edit blog post

Slide 21

Slide 21 text

ā˜‘ Photo by Stan B on Unsplash

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

hmm?

Slide 25

Slide 25 text

Bene fi ts we prevented lots of security issues (SQL Injection, CSRF, ...) Drawbacks "Magic" - di ff i cult to follow extensible, but not extensible

Slide 26

Slide 26 text

Less Lines of Code explicit Code Self-Documenting Code Documented Code Work with Objects Immutable & Functional Patterns

Slide 27

Slide 27 text

Elements of Maintainable Code

Slide 28

Slide 28 text

Photo by Alexander Hafemann on Unsplash

Slide 29

Slide 29 text

basically: compact is good. BUT: explicit is better than "compact". clear is better than "magic".

Slide 30

Slide 30 text

Key Question: What do I need myself to understand the code in 3 years from now?

Slide 31

Slide 31 text

1) Intrinsic Similarity consistent naming coherence "new code should be written the way old code was"

Slide 32

Slide 32 text

2) Immutability & Pure Functions

Slide 33

Slide 33 text

Immutability = state in object does not change ā‰ˆ no setters

Slide 34

Slide 34 text

final readonly class Node { private function __construct( public ContentSubgraphIdentity $subgraphIdentity, public NodeAggregateId $nodeAggregateId, public OriginDimensionSpacePoint $originDimensionSpacePoint, public NodeAggregateClassification $classification, public NodeTypeName $nodeTypeName, public ?NodeType $nodeType, public PropertyCollection $properties, public ?NodeName $nodeName, public Timestamps $timestamps, ) { } public static function create(ContentSubgraphIdentity $subgraphIdentity, NodeAggregateId $nodeAggregateId, OriginDimensionSpacePoint $originDimensionSpacePoint, NodeAggregateClassification $classification, NodeTypeName $nodeTypeName, ?NodeType $nodeType, PropertyCollection $properties, ?NodeName $nodeName, Timestamps $timestamps): self { return new self($subgraphIdentity, $nodeAggregateId, $originDimensionSpacePoint, $classification, $nodeTypeName, $nodeType, $properties, $nodeName, $timestamps); } public function getProperty(string $propertyName): mixed { return $this->properties->offsetGet($propertyName); } public function hasProperty(string $propertyName): bool { return $this->properties->offsetExists($propertyName); } public function equals(Node $other): bool { return $this->subgraphIdentity->equals($other->subgraphIdentity) && $this->nodeAggregateId->equals($other->nodeAggregateId); } }

Slide 35

Slide 35 text

Bene fi ts Objects will never change easily comparable easily composable

Slide 36

Slide 36 text

calculateLabel(Node) Node Pure Functions no side e ff ects deterministic (same input => same output) result a() b() c() d()

Slide 37

Slide 37 text

composable functions = processing pipelines

Slide 38

Slide 38 text

Recommendation: learn some functional programming fi lter, map, reduce divide-and-conquer

Slide 39

Slide 39 text

3) Libraries over Frameworks your code your code lib 1 lib 2

Slide 40

Slide 40 text

4) (e2e) Tests mocks only for faking external APIs

Slide 41

Slide 41 text

5) Reduce Complexity

Slide 42

Slide 42 text

Complexity = all parts making it di ffi cult to understand software or to change it. Root Causes of Complexity = Dependencies + Obscurity

Slide 43

Slide 43 text

we want Deep Modules

Slide 44

Slide 44 text

6) Document "Why"

Slide 45

Slide 45 text

Dokumentation "Why" DESIGN COMMENTS ... The design comment basically states how and why a given piece of code uses certain algorithms, techniques, tricks, and implementation. It is an higher level overview of what you'll see implemented in the code. With such background, reading the code will be simpler. Moreover I tend to trust more code where I can find design notes. At least I know that some kind of explicit design phase happened, at some point, during the development process.

Slide 46

Slide 46 text

Goal: Give Context Explain WHY

Slide 47

Slide 47 text

every class: a Why Comment, or a link to a Why Comment.

Slide 48

Slide 48 text

Sketches + Diagrams

Slide 49

Slide 49 text

7) Write Concepts

Slide 50

Slide 50 text

Konzepte

Slide 51

Slide 51 text

Konzepte

Slide 52

Slide 52 text

at a single place, f.e. at the source code (Alternative: Wiki oƄ) with Date with Author

Slide 53

Slide 53 text

Length: depends on target audience incomplete might also be fi ne

Slide 54

Slide 54 text

8) Review and Discuss

Slide 55

Slide 55 text

No content

Slide 56

Slide 56 text

Summary How to write unmaintainable Code What is Good Code? Property Mapper example: Goals change over time Elements Of Maintainable Code Intrinsic Similarity Immutability & Pure Functions Libraries over Frameworks (e2e) Tests with little mocks Reduce Complexity by building deep modules Document WHY Write Concepts Review and Discuss

Slide 57

Slide 57 text

Thanks!

Slide 58

Slide 58 text

No content