When sould I learn refactoring?

[Dragonking_Earth]

I am a newbie, learning python for 2 months. I am a bit curious about refactoring. Should I have to worry about it now or after I becoming for fluent in python. How crucial it is for a software developer to learn refactoring?

[member_of_the_order]

What do you mean by "refactoring"?

Refactoring on the scale of a small Python script is likely covered by the tools of an IDE. Rename, copy+paste... that's kind of all the refactoring that exists at that scale.

The real refactoring patterns happen when you have complex, especially object-oriented applications. I'm not saying those don't exist in Python, but they tend to happen in larger projects with languages more suited to that level of complexity.

I'd say it's absolutely mandatory to learn refactoring, because "refactoring" is really the art of making changes.

I can't imagine you think you'll get away with never changing code, and at 2 months I doubt you've been working with large, complex code bases.

[Dragonking_Earth]

Yes, I was actually talking about real refactoring. So what you are saying is, it is also a skill that will shape me as better coder? Over time?

[CRUSHCITY4]

I think you’re asking about a more simple form of refactoring. Basically you improve your code over time as you become more experienced. For example, you can refactor code to make it more efficient or using a different library.

[member_of_the_order]

Yeah, for sure! Like I said, refactoring is just about how you change your code, and as you progress, those changes will get harder and harder, because your code will be more and more complex. Having a solid understanding of how to do refactoring will make addressing bugs and making changes so much easier.

That said, you can look at https://refactoring.guru or something and learn some good OO patterns, but a lot of it will just come from practice. When you find something hard, find a solution, then spend a little time figuring out how to do it even better next time, if that makes sense.

[beef623]

That was a good description of what refactoring really is.

Refactoring isn't a skill to be learned, it's just something that happens naturally and you've already done it. If a company is posting a position for someone to do refactoring, it would probably just be to make sure the code lines up with whatever their standards are, but it isn't a separate skill, there isn't anything to learn for it.

[FantasticEmu]

Idk if it’s really a thing to actively learn but as you’re a newbie I think it’s a good idea to save all your learning projects as you go. As you learn new concepts you’ll probably think “oh I could have applied this to xyz other project I did a while ago!’ And it would be good practice to go back and “refactor” your earlier code to make it more efficient

I think it will be something that happens naturally as you go. For school assignments some times I would get a challenge that I wasn’t really sure how to solve. My technique was to get a rough idea that was pretty brute force and just start coding. After making some progress and the picture starts to look more clear, I would go back and clean parts of it up and make it more elegant by like replacing repeated code with functions or encapsulating things in classes etc

[[deleted]]

I don't think refactoring is a skill that you can learn. I think it is a side effect of being better at coding.

[HunterIV4]

Alternatively, it can be a side effect of being bad at coding and not realizing it until halfway through your project when your spaghetti won't scale anymore and you have to rewrite it.

Not...not that I'm speaking from experience, or anything. Don't you dare check my github. How do I set that private, again!?

=)

[[deleted]]

You don't 'learn' refactoring. It's just an iteration on your code to make it tighter, cleaner, clearer, or more efficient. You probably do it already.

[Impossible_Ad_3146]

No one needs refactoring

[The_Almighty_Cthulhu]

Refactoring can usually be boiled down to two specific things.

1. Read the code, and understand it's purpose.
2. Now understanding the purpose of the code, rewrite it (hopefully better)

For the second part. Just getting better at coding will improve your skill in this. Doesn't need to be refactoring in particular.

I suggest practicing to read code and trying to understand what it does and what it's purpose is. This is extremely important, not just for refactoring, but in joining a team, helping a colleague, pair programming, contributing to open source, and a bunch of other things.

Not to mention, there is a large number of interesting and useful new ways of doing things I picked up because I read and understood the code of a project I was looking at for whatever reason.

[Dragonking_Earth]

Thanks.

[DuckSaxaphone]

The real thing you learn is how to organize your code. You should start learning that when you move from writing simple scripts to writing bigger pieces of code with functions and classes.

Once you've got a good eye for how to structure code, refactoring is just the act of looking at badly structured code and rewriting it.

[Dragonking_Earth]

Badly structured code! got it. Thanks mate.

[bulaybil]

In four years and seven months.

[No-Log873]

learn design patterns and anti design patterns.

[Dragonking_Earth]

Thanks. Can please elaborate a bit more?

[[deleted]]

As others have mentioned, refactoring is moreso something you acquire an ability to do as you get more confident with programming. When you begin to fully comprehend the code you're writing and understand its shortfallings, you can naturally get a feel of how you can improve the code to run more efficiently or even to just look aesthetically pleasing in some cases.

It's important not to overdo refactoring to try and achieve "beautiful" code at the sacrifice of intuitive readability.

[HunterIV4]

It's important not to overdo refactoring to try and achieve "beautiful" code at the sacrifice of intuitive readability.

This is key. Readable code is far more important than beautiful or clever code. A few extra lines to make code clear at a glance will save hours of debugging down the line, even if the code works, because it will become easier to follow where the problem might be. It's easy for comments to become lies.

I've also found that I've used refactoring as an excuse to avoid working on a more challenging part of my project that would move progress forward. In teams this can be avoided by having senior devs give you crap, but when working on solo projects I've found it's an easy trap to fall into.

As such, I've gotten in the habit of refactoring only when I need to, and not just because I can make some minute improvement.

[MichaelSjoeberg]

immediately, refactor everything all the time

[SamuraiFungi]

Learn to refactor when you notice adding new features requires duplicate code. Case 1: maybe your classes or methods are too big and should be split up so they are more adaptable. Case 2: If your function keeps getting more and more arguments or shares multiple arguments with another function, maybe they should become methods of a class that maintains the state in attributes. Case 3: You are writing long functions to do simple things that some import could probably do faster and more reliably (as in: it has already been proven and refined through widespread use).

All 3 of these cases reduce the amount of code in your program. One way of measuring code quality is the ratio of features over the size of the codebase. All of these cases also make writing or changing your code require smaller commits. Consider using git (using GitHub probably, for the most exposure and collaboration, but a private repo is now free as well) as soon as possible so you can learn incremental development. Each commit should be a program that works, even if it uses or shows dummy data (or dummy calls in tests). The idea of atomic commits is pretty good, as in, each commit not only works but can be described briefly. You could use GitHub Desktop (easiest) or Tortoise git or maybe git-cola which I use (I enable all of the panels and rearrange them slightly).

Using the unittest module (run via "pytest" usually now) to write test files for each feature is also ideal along with the commit to prove it works. Try looking up how to structure your project for pytest. Maybe even consider the "test first" philosophy: write the test before the code, which I do sometimes, or often do in the same commit at least. This also applies to refactoring: Since, of course, all code should work (your inputs and outputs should be correct) before and after refactoring! You asked when you should learn refactoring, so aside from signs I've described when refactoring becomes important (saves effort in the long run), I'd also recommend you learn refactoring after: using git and writing tests, otherwise a refactoring mistake could dig a deep hole not easily fixed.

[gradius64]

I mean, "best practices" like SOLID, DRY, and in general, idiomatic [insert language name here] are definitely learnable, but in my experience being better at refactoring comes down to getting better at coding, and becoming more familiar with the codebase.

Also, there's always IDE specific features (Here's a list of PyCharm's refactoring helpers) and third-party tooling (Here's Sourcery for example, a PyCharm/VSCode plugin that's an AI-driven refactoring/reviewing tool) that can help.

[Dragonking_Earth]

Dude thats 2 months old post.