Refactoring is just a fancy term that means improving your code without changing how it behaves.
Let's look at some reasons why you should learn ...
For further actions, you may consider blocking this person and/or reporting abuse
I have a few real-world refactoring stories. The gist of each one take the following rough outline:
For a real world example, I had been using the ClassyHash gem fairly extensively as part of a project. I needed to start extending it for more specific test cases than were possible by default with classy hash. I tried for a day to make my own extension and it was like pulling teeth. Realizing I was pulling teeth was step one.
Next I had seen that there was a giant conditional statement at the heart of ClassyHash. I know big conditionals are bad practice. I had found the source of the pain.
Third, I know that polymorphism is the fix for conditionals.
Finally, I rewrote the whole gem in the course of 4 hours including tests.
So, what did this gain me? After the re-write I could write an extension with tests in 10-20 minutes, an order of magnitude development speed increase.
Nice! It's an awesome feeling when you come back to that task you were trying so hard to pull-off, and it takes a fraction of the time to do and is just really simple and straightforward now. 🥳
It’s nice to read a post on the importance of refactoring. It would be nice to read a hands-on example on and why it made a difference, with the code itself.
I previously had some comments on the original text, that is now changed, this the comments no longer relevant, so removing these.
Good luck with the book, it will be nice to see a great resource on Typescript and software craftsmanship!
I never said not refactoring was a cause. In context, this was concerning being a software craftsman. I did say:
Sure - there are many issues and causes we could look at in this specific case, which actually further my point about taking time to build quality systems (whether software or otherwise).
As far as the engine issue, I read somewhere that the decision to go with the larger engine and not change anything else was in efforts to get this thing done faster in order to match a competitor. For software developers out there, that should sound awfully familiar...
But as a segue, I think the point remains that as software developers we should seek to be craftsmen and value building quality systems.
I have no issues with developers from outsourced countries - but if they have a lack of experience in that particular industry for such a critical system and the company outsourcing (Boeing) is getting rid of its experienced senior devs in efforts to "cut costs", then that perceived trade-off of "less quality = fewer costs" is not true.
Quoting the article:
Did that cause the crash? Dunno.
However, seeking to squeeze out costs and ignore quality in these kinds of critical and/or complex software systems do matter and have long term consequences that end up affecting costs negatively when bugs and unexpected behaviour do finally occur.
One of the ways developers can make sure they are doing their part is to address code quality and take ownership of it.
One of the tools to do that is refactoring.
Hopefully, that's clearer 😊.
I see - thanks for the clarification! And good luck with the rest of the book.
I just added some more context and re-worded things in the article to make it more clear 👍
Hopefully, that's more clear. Thanks for the feedback!
Yes, it’s a lot easier to follow your train of thought. Thanks! 👌👏
Awesome 🤜🤛
I think the author trying to say is the quality of your code is important. Every developer should care about and be responsible for it. And refactoring your code to be cleaner is the key.
Great article.
If only each and every one of us takes the time to find a better(sometimes cleaner) way to code, so many of these accidents can be avoided.
Hope that day comes.
Nice and thoughtful article with great example that shows how hurriedly and badly written software impact on people lives.
Thanks James.
Thanks Branislav 👍