How To Write Unmaintainable Code - PHPDD 2024

How do I write code that is as "good" as possible? What does that even mean? I have been working on large open source frameworks (initially TYPO3, now Neos and Flow) for around 20 years. In that time, I have produced a lot of code that I would never write in the same way today - and from which we can learn a lot together. I will critically discuss principles such as extensibility and DRY, show what mistakes I have made when developing frameworks and show which principles we can use to gradually improve our code. The whole thing will be a joint journey into large codebases. I'm looking forward to it!

Transcript

1. How to Write Unmaintainable Code
2. #me
18. Less Lines of Code Self-Documenting Code Work with Objects My Goals 15 Years Ago
19. show blog post
20. edit blog post
21. ☑ Photo by Stan B on Unsplash
24. hmm?
25. Bene fi ts we prevented lots of security issues (SQL Injection, CSRF, ...) Drawbacks "Magic" - di ff i cult to follow extensible, but not extensible
26. Less Lines of Code explicit Code Self-Documenting Code Documented Code Work with Objects Immutable & Functional Patterns
27. Elements of Maintainable Code
28. Photo by Alexander Hafemann on Unsplash
29. basically: compact is good. BUT: explicit is better than "compact". clear is better than "magic".
30. Key Question: What do I need myself to understand the code in 3 years from now?
31. 1) Intrinsic Similarity consistent naming coherence "new code should be written the way old code was"
32. 2) Immutability & Pure Functions
33. Immutability = state in object does not change ≈ no setters
34. 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); } }
35. Bene fi ts Objects will never change easily comparable easily composable
36. calculateLabel(Node) Node Pure Functions no side e ff ects deterministic (same input => same output) result a() b() c() d()
37. composable functions = processing pipelines
38. Recommendation: learn some functional programming fi lter, map, reduce divide-and-conquer
39. 3) Libraries over Frameworks your code your code lib 1 lib 2
40. 4) (e2e) Tests mocks only for faking external APIs
41. 5) Reduce Complexity
42. Complexity = all parts making it di ffi cult to understand software or to change it. Root Causes of Complexity = Dependencies + Obscurity
43. we want Deep Modules
44. 6) Document "Why"
45. 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.
46. Goal: Give Context Explain WHY
47. every class: a Why Comment, or a link to a Why Comment.
48. Sketches + Diagrams
49. 7) Write Concepts
50. Konzepte
51. Konzepte
52. at a single place, f.e. at the source code (Alternative: Wiki oÄ) with Date with Author
53. Length: depends on target audience incomplete might also be fi ne
54. 8) Review and Discuss
56. 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
57. Thanks!