4. A. I can't work with it
• Missing source code
• Missing protocol documentation, passwords
• Missing tooling (e.g. no licence for Visual C++
5.0)
• Legal or regulatory reasons
5. B. It won't work properly
• Breaks often in production
• Performs poorly
• Hard to deploy
• No monitoring or logging
6. C. I won't work with it
• Brittle code
• Big ball of mud
• Hidden knowledge
• I don't know the language
• Unused code
8. "Programmers are, in their hearts,
architects, and the first thing they want to do
when they get to a site is to bulldoze the
place flat and build something grand.
We're not excited by incremental renovation:
tinkering, improving, planting flower beds."
-- Joel Spolsky - "Things You Should Never Do"
http://www.joelonsoftware.com/articles/fog0000000069.html
9.
10.
11. "Programmers are, in their hearts,
architects, and the first thing they want to do
when they get to a site is to bulldoze the
place flat and build something grand.
We're not excited by incremental renovation:
tinkering, improving, planting flower beds."
-- Joel Spolsky - "Things You Should Never Do"
http://www.joelonsoftware.com/articles/fog0000000069.html
12. It's never just the code
Sysops
Third parties
Designers
Other teams
Marketing
Technology
salesmen
26. Steps to introduce tests
in legacy code
• Find where to make the changes
• Find what to test
• Break dependencies (without refactoring)
• Write tests
• Make changes and refactor
29. Swallow small bits
• Carve an integration point (service, DB)
• Rewrite only the parts that touch it
• Don't try to rewrite the whole monolith at once
30. Rewrite by feature,
not by module
• Play to the strengths of your target language and
framework
• Don't replicate past implementation
31.
32.
33.
34. Take your time
• Insist on quality
• Train the team. Build good habits
• Absorb the culture of your new
language/framework
• Be aware of cultural dissonances
37. Thank you!
Get in touch:
hello <at> iuliandogariu <dot> com
@yu_li_yan
Please help our nice hosts #Codecampiasi,
give them feedback
Editor's Notes
Thank you for choosing this talk
You must either be an engineer, or a manager
Please sit next to each other.
If you're neither , ... wow! I am flattered.
You've been thinking about rewriting a big software system, for good reasons. Or if you're a manager, your team has proposed a rewrite. Or you've asked for one :) Should you do it? And if yes, how?
I must admit the title was clickbait. I will not tell you how to rewrite PHP in Scala or Angular.
Instead I'll spend the first 1/3 playing the role of Satan, questioning your faith.
in the process maybe also offend you a little.
But hey, you come to conferences not to hear only ideas that you already agree with.
The second 1/3 giving you some hints
And the final 1/3 answering questions and sharing anecdotes.
I am Iulian, been doing software for 15 years. Including about three rewrite projects
In the last one I was an architect on the consultant side.
I'm an engineer so beware of my bias :)
What are the most often-quoted reasons?
I'm dividing them into three categories.
as in I wish I could but I can't
Valid reasons, but it's safe to say you're not in one of these cases.
This is not a reason to rewrite.
You must fix it.
Optimizing for performance is a 20-80 effort
You change from PHP to Scala, you gain concurrency
but you now hit the database with 10 simultaneous queries instead of one. Whaddaya think this will do to your perf?
Performance at the database Might be due to the Data model
(it's really unpleasant):
- Brittleness. Frustratingly slow to make changes
- "Big ball of mud" (no architecture, high coupling)
- Hidden knowledge (tacit, non-explicit). I don't understand the code.
- It's in a language I don't know (PHP), or It's hard to hire developers
- Unused code, or code for handling legacy data (e.g. nulls)
- No source control history (incl things like branches)
It MAY be a reason to rewrite, But by the end of this talk I hope I'll have convinced you to think VERY HARD whether to throw your code away and start fresh.
Code is an asset, it's what makes a business tick, make money, pay our invoices, etc.
BUT code is not where the value is. Only code that is running is of value to anyone.
It is a unique kind of asset
It takes time to grow,
it needs care and feeding
just like a kid
I'm not a parent but was a kid some time ago.
I was sticking my fingers everywhere
What if my parents said "aa, fuck it, let's throw him away and start from scratch"
sysops will have to learn to deploy, monitor and diagnose an entirely new app. Do you think they will love you??
You store data, the DB may still be legacy.
Designers
Other developers
Misbehaving browsers
integrations with third parties
Marketing people and technical writers will have to adjust their works - a button that was there suddenly isn't .
And salesmen pushing their technologies. There is always sales. You are not immune to it. Hadoop, no Cassandra, no MongoDB. Microservices, No, ESB. Scala, no, NodeJs, no, Erlang. YOu think NodeJs doesn't have a company pushing it? That's OK, but you need to be aware of who is influencing your decision. Think of the other players in your ecosystem
https://newcodepoet.files.wordpress.com/2013/01/sourcecode.jpg
Are you sure everyone wants a rewrite? Are you sure all wnat to learn the new technologies?
http://www.blogging4jobs.com/wp-content/uploads/2012/10/office-politics.jpg
whose job is at risk if the project succeeds (!)
There's a thing worth repeating, about legacy code:
Nobody wakes up in the morning thinking “I’ma gonna write myself some legacy code today"
Nimeni nu vine la serv cu gandul "azi o sa scriu o functie de 5000 de randuri"
Code got this way because of a lot of pressure, and because we didn't know any better.
http://img3.wikia.nocookie.net/__cb20130620100935/starwars/images/d/d8/Emperor_Sidious.png
How did the code get to a legacy state?
Step by step!
Nobody did it intentionally to give you a hard time
They responded to pressure, limited staffing
Have a little empathy
for in 5 years when AngularJs becomes tomorrow's PHP, some dev who is a kid today will say bad things about your app that you're building right now
"You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version." -- Joel
http://imgur.com/gallery/4Sas579
Careful about estimation. It is very tricky to estimate based on lines of code.
Remember you're not rewriting code, you're reproducing behaviour.
https://d3bg2441si4wp3.cloudfront.net/prod/wp-content/uploads/blogs.dir/3/files/2014/05/Erich-Marx.jpg
The reductionist (deconstructionist) approach: decomposing the legacy system into parts and estimating each.
To show you how ridiculous such an approach is, here's a challenge
Can you estimate when we will have artificial humans? i.e. androids
We have plastic surgery, artificial limbs, artificial intelligence, computer vision
http://hivewallpaper.com/wallpaper/2014/11/androids-7-cool-wallpaper.jpg
OH: “That’s easy! I can do that in a couple of hours.” dangerous especially if it's not him who's gonna do it.
Beware the "Estimator" with no skin in the game.
- Any time we work with a new code base our speed will be slower - need to account for that when planning/estimating.
This is basic hygiene in development. No excuses.
You'll need these anyway, whether you rewrite or not.
https://www.relfe.com/wp/wp-content/uploads/2014/04/germs-wash-hands-with-soap.jpg
Infrastructure automation: Get good at it
Or else you'll be forever stuck in development limbo (or development hell)
Automation test suite through the UI: What if you introduce regressions?
Business vocabulary: A group of related users was either a Group, or an Account
It's a four letter word
Of course, Test.
To change code, we need tests.
To introduce tests, we must change code.
- Carve an integration point. Absolutely never start rewriting the entire monolith
Of course your BA / Product Owners should support you
1. Shorter!
But not only that
2. Better coupling
When Should you rewrite? As a startup.
When you want to change your product significantly.
I want to augment a statement that I made earlier.
I said Code is not the main asset. A running system making money is the main asset.
If you're a startup, learning is your main asset.
You use the previous rewrite as an investment in _learning_.
Using a language with static types. So much easier to do automatic refactorings.
Code review
Regular meetings with domain expert
Rewriting a small piece of functionality
Rewriting from the outside in
Not rewriting everything!
Negotiating limitations with product owners.
Domain knowledge hasn't changed that much. It needed better formalism, that's it.
We still had a domain expert
Toggles. Old feature. new feature.
Things that didn't:
Wrong boundaries
Wrong reasons to rewrite
Long time to victory. Getting a full CI pipeline straight to production took months.
PHP dynamic language, hard to do automated refactorings
