Nicolas Carlo

231 Followers
52 Following
96 Posts
🧑‍💻 Refactor Legacy Code. I build tools to help you do the same!
💁‍♂️ I share tips & tricks to deal with Tech Debt • https://understandlegacycode.com
⛑️ Legacy Code: First Aid Kithttps://understandlegacycode.com/first-aid-kit
And the whole bookshelf I am mentioning: https://understandlegacycode.com/bookshelf
The key points of Refactoring at Scale

Maude Lemaire wrote a great book rooted from her experience in the trenches, at Slack. Let's see how it may help you lead large-scale refactoring projects.

"Refactoring at Scale" by
Maude Lemaire is now part of Understand Legacy Code bookshelf 🎉

I like how it's rooted in reality, with concrete use cases from the trenches at Slack

I wrote an overview of what I learned, so you can answer "Is this book relevant to my situation?" 😉

== Scheduled Talks ==

🔷 "Communication is Just as Important as Code" / @andreagoulet

🔷 "Using Code Coverage and Mutation Testing to add tests to Legacy Code" / @claresudbery

🔷 "From Legacy Monolith to Microservices via Event Storming" / @sadukie

🔷 "AI Coding: The State of the Mend" / @lambdapocalypse

I will attend MenderCon 2024—a remote conf for people who deal with legacy codebases

📅 May 16
📍 Remote
🎫 Pay what you want (suggested $5)

There will be open-space sessions: you can bring up a topic you want to discuss

Interested? Join us 😉

Details & registration: https://mendercon.com/

MenderCon

MenderCon is a conference for people who are passionate about modernizing and improving software systems

MenderCon
Fantastic article from @nicoespeon -- Technical Debt Isn't Technical: What Companies Can Do to Reduce Technical Debt https://www.infoq.com/articles/reduce-technical-debt/ -- hint there are humans involved
Technical Debt Isn't Technical: What Companies Can Do to Reduce Technical Debt

This article discusses the impact of technical debt, dealing with maintenance work continuously, the future of technical debt and communicating the importance of dealing with technical debt.

InfoQ

It's common for legacy code to have deeply nested statements

They make code harder to read/think about (cognitive overload) 😵‍💫

Did you know "Guard Clauses" can help you simplify these? Now you know 💂

Here's a JavaScript example 👇

JavaScript's take on the ultimate question:

["🥚", "🐔"].sort()
// ~> ["🐔", "🥚"]

You're welcome 😉

"No but really, that code IS unreadable" 🥸
I recently created a new code kata. It's not a TDD kata, or a Refactoring kata, it's a Test Design kata. The idea is you're given a piece of code without tests, but which has bugs in. The exercise is to write tests for it. The bugs are generally well-commented so it's easy to fix them. The challenge of the kata is to pick a bug, design a test case that fails, then passes when you fix the bug. Repeat until no bugs are left. This is the starting code: https://github.com/emilybache/StrangeCharacter-TestDesign-Kata
GitHub - emilybache/StrangeCharacter-TestDesign-Kata: for writing tests that check correct objects are included in a list

for writing tests that check correct objects are included in a list - GitHub - emilybache/StrangeCharacter-TestDesign-Kata: for writing tests that check correct objects are included in a list

GitHub