Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Three Principles To Bring Your Legacy Code Into the Future
Search
Roland Weisleder
December 11, 2023
Programming
0
84
Three Principles To Bring Your Legacy Code Into the Future
Roland Weisleder
December 11, 2023
Tweet
Share
More Decks by Roland Weisleder
See All by Roland Weisleder
Unit Test Your Java Architecture With ArchUnit
rweisleder
0
170
Immer wieder die gleichen Fehler? Nicht mit ArchUnit!
rweisleder
0
160
Alles einsteigen! Einen eigenen Release Train mit Maven umsetzen
rweisleder
0
200
7 Tipps für eine verständliche Git-Historie
rweisleder
0
67
Other Decks in Programming
See All in Programming
Webアプリをできるだけコードを手書きしないで作ってみる
tomokusaba
2
140
Exploring the Implementation of “t.Run”, “t.Parallel”, and “t.Cleanup”
akarin
1
130
AmperとFleetを使ったAndroidアプリ
yoppie
0
260
Ruby Pattern Matching
bkuhlmann
0
930
2 週間で Twitter Bot を作ってみた
contour_gara
0
770
Implementing Design Systems in Swift
seyfoyun
2
470
Fast JSX: Don't clone props object #28768
yossydev
1
190
Ruby Function Composition
bkuhlmann
1
340
R言語の環境構築と基礎 Tokyo.R 112
bob3bob3
0
280
SIMD Parallel Programming with the Vector API
josepaumard
0
230
MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた
ymd65536
1
510
使ってみよう Azure AI Document Intelligence
kosmosebi
2
360
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
25
2k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Pencils Down: Stop Designing & Start Developing
hursman
117
11k
4 Signs Your Business is Dying
shpigford
176
21k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.7k
Atom: Resistance is Futile
akmur
260
25k
Teambox: Starting and Learning
jrom
128
8.4k
Building Your Own Lightsaber
phodgson
100
5.7k
We Have a Design System, Now What?
morganepeng
43
6.8k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
155
14k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
Transcript
@Ro_Wei Roland Weisleder
[email protected]
Three Principles To Bring Your Legacy
Code Into the Future
About Me Independent Software Developer & Consultant Bringing Legacy Java
Systems Into the Future Spring Boot Trainer @ workshops.de Lecturer @ HTW Berlin in/roland-weisleder @rweisleder @Ro_Wei
[email protected]
What is Legacy Code?* • Still in production use •
Relies on outdated technologies • Has insufficient test coverage • Lacks adequate documentation • Expert knowledge unavailable *According to ChatGPT
Big Bang Rewrite? Too time-consuming
What to improve? What you work on anyway
Rewrite or Refactor? Rewrite only with test coverage
Old bugs need to be added to the rewritten system.
Source: https://martinfowler.com/bliki/StranglerFigApplication.html
How to increase test coverage? Add tests for current behavior
How to understand the current behavior?
Where to start?
Source: https://www.commitstrip.com/en/2016/03/03/its-not-working/
Analyze Stack Trace or Thread Dump Source: https://www.jetbrains.com/help/idea/analyzing-external-stacktraces.html
Call Hierarchy
Source: https://twitter.com/codewisdom/status/1154436195126009858
Understand Code
Scratch Refactoring • Learn through refactoring • Make experiments •
Revert everything
Source: https://www.morling.dev/blog/the-code-review-pyramid/
Document Code
Our code is self-documenting.
• What about the input format? • What about malformed
input? • What about null? • What about thrown exceptions?
• What about the return value? * don’t use double
for money…
Suddenly a wild Java update appears
Unit tests are our documentation.
Who has read the tests of their favorite language /
framework / library to understand how to use it?
None
None
not only Don‘t Repeat Yourself but also Documentation Reflects Implementation
Source: https://twitter.com/sweblogtweets/status/1249698475249467393
Test Code
What should I test? The documented behavior.
Use Descriptive Test Names
Concise Implementation Keep relevant stuff together, hide irrelevant stuff
I want to test private methods Private methods are independent
units in disguise. Extract, document and test.
I have to mock everything So the method does nothing
useful? Keep it simple, delete the method.
The code contains hard-to-mock dependencies Current Time Database External Systems
Declare dependencies as parameters vs vs
Declare dependencies as parameters vs
Separate Domain and Infrastructure to simplify testing
Clean Architecture
Code Coverage • Find untested code • Find dead code
Still doing Scratch Refactoring? Revert everything, except the tests. Congratulations!
Time for TDD.
Inverted TDD
Source: https://twitter.com/kentbeck/status/250733358307500032
Improve Code
Source: https://www.morling.dev/blog/the-code-review-pyramid/
Focus on clean APIs
Define Interfaces Input Process Output
Invalid objects …
… vs valid objects
What about null?
Primitive Obsession vs
Source: https://twitter.com/codewisdom/status/1154436195126009858
None
https://www.youtube.com/watch?v=OGZ1JkC-cQc
Key Takeaways Separate Domain and Infrastructure Documentation Reflects Implementation Input
Process Output
Bringing Legacy Code Into the Future Slides: speakerdeck.com/rweisleder Gilded Rose
Kata: github.com/emilybache/GildedRose-Refactoring-Kata Need help with your Legacy Code? Contact me!
[email protected]
in/roland-weisleder @rweisleder @Ro_Wei