#refactor

This might be the most obvious of #linktuesday links in ages, but really, I've recently been helped a lot by #rector. So yes, I'm sharing Rector today: https://getrector.com

If you have not worked with it before, it may seem intimidating, but take some time to get used to it, because it can really make your life a lot easier, especially when working with #legacy code

#php #refactor

Tonight's dev log update for Rack Root

I finally finished my refactor from sqlalchemy with sqlite over to SQLModel with PostgreSQL and refactored much of my code. I had a mixture of snake_cake and camelCase which has since been fixed to be all camelCase.

I adjusted many of my imports, classes, database tables, database foreign key relationships, and testing to fit the new design. I also had to adjust some of my tests because my IDs were off by one.

This database focused refactor also gave me all the structure and space I needed to build out the basic IPAM features. When a new network is added, all the associated IP records are created, and marked as 'Available'. If a gateway is set, that gets changed to 'Gateway' and when I implement DHCP ranges, that will be set to 'DHCP'.

I still have some things to do such as make sure the IP records cascade delete when a network is deleted, and fun stuff like that.

Now that the backend is (re)designed, I can get back to the front end side of things.

If you're curious to check out my code for this refactor, it's all up on my GitHub here:

https://github.com/alongchamps/rack-root/commit/0fc99dfcf10bf3ab6a5dfdc348894fe7e6221acd

#devlog #programming #rackroot #homelab #python #fastapi #sqlmodel #pytest #refactor #postgresql #backend

Manager: Don't refactor. It already works! It's a waste of time.

Me: OK, the next time I present something, I'll use my first Powerpoint draft. The information is all there!

A reminder that we write programs for the humans, not for the machine.

https://blog.nawaz.org/posts/2025/Jan/just-present-the-first-draft/

#refactor #programming

TDD is a great _technique_ for guiding you and helping you discover unclear code or designs that could be improved, but you, the developer, have to not only pay attention, you also have to know how to #Refactor and know what better design is so you can refactor in that direction.

I compiled useful refactoring techniques into a course that guides you through different ways to refactor with code examples.

Check it out:
https://dometrain.com/course/from-zero-to-hero-refactoring-for-csharp-developers?affcode=1115529_nl-teyzg

#Courses #Refactor #Refactoring #SoftwareEngineering

last 2-3 weeks, besides a bunch of mostly aimless traveling, were dedicated to this insane 70+-#commit #refactor on the #rust #tui #daw, bouncing between 5 and 512 compile errors...

and i'm still not happy with the code quality... but let's say i've massaged the code around enough, and collected the not-yet-clarified bits in several places rather than all over the place...

my favorite language feature that neither #rustlang nor #ecmascript has? #mixins. there, i said it

New tiles include "Refactor" (duhh!) and "Integrate" (h/t @tottinge and Industrial Logic). #Refactor "recipe" cards are the next step.

Two layout ideas: Refactor as an optional path (first image), or Refactor always on your path (second image), though still "optional".

... with the codebase, can become quite complex, and therefore must be easy to understand and #refactor when needed. Too many companies try to stick with YAML pipelines, working around limitations by cramming PowerShell or Bash scripts alongside the YAML files—even though there are much better alternatives. This doesn't even take into account the potential need to migrate from one build engine to another, such as moving from Azure DevOps Pipeline to #GitHubActions, or, for a...

#AI is absolutely incredible at helping #refactor repetitive #code. I love it when it just picks up on a pattern I've been applying and offers to perform what takes me 10 clicks in a single keystroke.

And for all the anti-AI folks: this is a great example of it working on (A) a local machine without significant additional power usage, and (B) pattern matching against my own actions, not "stealing" anything from its source materials except basic syntactical patterns.

Your irregular reminder that #TDD is writing one (1, uno, single) test at a time, and watching that one (single, only, uno, 1) test fail for the right reason, and only then writing the least amount of code to get that one failing test to pass (without causing any other tests to fail).

Then, if needed (often, but not always), you #refactor.

Only then do you go ahead and write another test, using the knowledge that you gained above.

This does not mean you can't plan ahead, sketch the tests you think you'll write, but you're not writing all of those tests at once and trying to make them all pass.

It's possible to even have two¹ tests failing and getting one to pass before getting the other one to pass, but that's not the same as "let's write thousands of tests and then write the code to get them all to pass". That's not TDD.

#OneFailingTestEachTime

¹ I've occasionally done 3, but not always successfully, so I really try to limit it to 1 by disabling other failing tests that are usually "wide" tests.

Too often, what people call technical debt is simply an encounter with the limits of functional anticipation. If you think a system will never need to do X given the foreseeable usecases and then one day it does need to do X, you don't have technical debt.

Technical debt arises when you then try to shoehorn the needed functionality in, instead of asking/making/taking the time and effort to redesign it.

#dev #technicaldebt #refactor #architecture

Many people say that #Rust is very hard to #prototype with or to #refactor. This couldn't be further from the truth! It is the exact opposite!

Let me share with you one of the most profound experiences I had with #RustLang on a casual sunday - a thread

I'm currently rewriting my #transpiler from #nom to #chumsky and until now everything has turned out great so far, until I've hit the following road block:
Implementing parsers by using #parser functions that have indirect #recursion.

1/11

New year, no fear.
#refactor #Liblast

Refactoring isn't about fixing bugs; it's about system enhancement and keeping the codebase nimble for quick pivots. Think of it as preventative maintenance. #Refactor #AgileCode

@natpryce @westghost Interesting. From the first workshop we learnt that people could uncover the clear design from the clear code. Equivalents to wikipedia discussions could be:
- commit comments (I experimented with a pre-commit hook that forced eg. '#test' '#refactor' etc. prefixes. it shows a kind of trail in git log --oneline of the kind of work and gives a feel for the cadence)
- Architecture Decision Records in the code base / repository 1/2 #ADR #stigmergy

IBM’s generative AI tool aims to refactor ancient COBOL code for its mainframes
Humans are still "in the driver's seat," but it could make code more modular.
https://arstechnica.com/information-technology/2023/08/ibms-generative-ai-tool-aims-to-refactor-ancient-cobol-code-for-its-mainframes/ #IBM #COBOL #GenerativeAI #refactor

How the Flocking Rules Can Help You #Refactor Your Code
https://www.youtube.com/watch?v=7Khf0xrlLgk

Thanks @_chrismay for hopping on and sharing these great insights.

"There is probably a right & wrong way to order all these vector math operations"
Write it the naive way with way too many parentheses => see if the IDE complains about anything => refactor to clean everything up.

"I need to remove some elements from this list of objects"
Instead of carefully building a reverse loop, I generate a foreach loop, and write the logic => refactor it to a for loop => refactor it to a reverse for loop.
#programming #refactor #IDE

#Kotlin is a great language, but there's a lot of #Java out there.

Come to @natpryce and Duncan McGregor’s session at #SoCraTes UK's #training day to learn how to #refactor from Java to idiomatic Kotlin.

buff.ly/2uITA1x 1-4 June, in beautiful Wiltshire, UK

#Kotlin is great, but there's so much #Java out there 🫣

Come to @natpryce and Duncan McGregor's session at #SoCraTes UK's #training day to learn how to #refactor from J to K

https://socratesuk.org/ 1-4 June, near Swindon

#softwarecrafts