How To Write Unmaintainable Code

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 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 write "better" code (whatever this means) :-)

The whole thing will be an entertaining journey into large codebases which might change the way you look at code.

Transcript

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