#Refactoring
23 notas · última:
Why Bad Code Exists
The article says bad code usually comes from process and context: no active review, no editing or refactoring, weak technical knowledge, time pressure, fear, and lack of care or investment in quality.
Refactoring Catalog
The post lists refactorings the author plans to cover in Tidy Together, argues that refactorings are reversible in both directions, and groups them by whether they change access and invocation or the arrangement of state and logic.
F# Advent of Code 2023: A random walk in the direction of functional enlightenment
The post follows Scott’s refactoring of old Grace CLI code to make it more idiomatic F#, showing how smaller functions, less duplication, and monadic bind improve clarity while exposing older bugs.
Time to refactor legacy with OOP
The article shows a legacy stats method that mixes tuple fields and is hard to read, then refactors it with OOP, iterators, and a builder-based workflow.
Refactoring
The newsletter argues that refactoring keeps a codebase healthy, easier to maintain, and simpler to extend, and recommends doing it incrementally with tests and IDE tools.
Opportunistic Refactoring
Refactoring should happen continuously and opportunistically, whenever code needs cleanup, while tests are green. Small changes done now keep the codebase healthier and reduce slower progress later.
Clean Code: The Good, the Bad and the Ugly
The article praises Clean Code for naming, readability and code-smell awareness, but criticizes its outdated Java focus, dogmatic advice and verbose examples, especially the prime generator.
The most valuable skill in 2026 isn't writing code. It is deleting it.
The text argues that AI makes creation cheap but maintenance costly, so senior engineering is shifting toward removing code, shrinking complexity, and curating systems instead of adding more.
Clean Code: 7 tips to write clean functions
The post argues that clean functions are small, easy to understand, well named, limited in parameters, free of nested conditionals and booleans, and preferably pure.
We Need to Talk About Technical Debt
Argues technical debt and bad code are not the same thing: debt is a deliberate, repayable trade-off, bad code is a skills gap. Unpaid debt compounds into a rewrite.
A month without R# or Rider - Editing, Debugging & Refactoring
The author compares Visual Studio 2019 with Rider for editing, refactoring, unit testing, and debugging, and argues that Rider is more complete, faster, and better optimized for keyboard-driven work.
10 Refactorings to Boost your Clean Code Skills
The article argues that clean code grows from small refactorings. It groups common changes into extract and move operations, then shows how each one helps make code clearer, safer to change, and easier to read.
CUPID - for joyful code
The page argues that code becomes more pleasant to work with when it is composable, follows Unix philosophy, is predictable, idiomatic, and domain-based, with each quality reinforcing the others.
5 things I wish I knew before starting serious development (a journey into code perfection)
The article argues that clean code depends on intention-revealing names, minimal comments, consistent formatting, short focused functions, and a team mindset that improves shared code.
How to Write Programs Without Bugs
The article explains Test-Driven Development as writing tests before code, then building and refactoring feature by feature to reduce bugs, avoid overbuilding, and make changes safer.
Refactoring: My 6 favorite patterns
The post outlines six refactoring patterns that improve readability, maintainability, and parameter handling, and shows how extracting logic into objects or methods makes code easier to change.
Replacing Throwing Exceptions with Notification in Validations
The article argues that validation failures should usually be collected in a Notification instead of thrown as exceptions, so code can report all errors and keep validation inside normal flow.
The thing with code clarity: you can't be proud of something I can't read
The post argues that code clarity matters because code must communicate to people as well as computers, and that readable, maintainable code comes from naming, structure, spacing, comments, and refactoring.
Why Comments Are Stupid, a Real Example
The post argues that comments often signal unclear naming or oversized methods, and shows a .NET refactor where better names and structure remove comments without reducing clarity.
Refactoring code that accesses external services
The article shows how to refactor code that mixes YouTube access, data translation, and domain logic into separate connection, gateway, domain, and coordinator objects, using small behavior-preserving steps and tests.
Understanding the Four Rules of Simple Design
The book draws lessons from coderetreat workshops and Conway’s Game of Life to explain Kent Beck’s four rules of simple design and how they support flexible, adaptable software.
SOLID: Part 1 – The Single Responsibility Principle
Explains SRP as the rule that a class should have one reason to change, tied to one actor. It shows how separating presentation, persistence, and business logic reduces coupling and change impact.
The five programming books that meant most to me
The author says most programming books age quickly, while a small set of books shaped his coding style by focusing on durable principles, architecture, problem framing, and writing.