I'm working on a personal project and I've found myself switching between doing some refactoring for a day or two and then some feature-adding for a few days. I like it, and I noted it was similar to how an instructor I worked with wanted to rework the class website. First, she froze the features and worked on refactoring the website, then once that was done, she focused on the features and only noted the things to refactor.
What is this process of refactor-features-repeat called?
[Context: I am a PhD student in computer science in the USA. My experience with software engineering per se was a short software engineering internship, but it was not at a company whose main product was software.]
3 Answers 3
You might be describing someone following Behavior Driven Development.
You might just be describing someone following Test Driven Development.
If you want something that specifically requires many things be refactored while all feature development is on hold I don't know of any named process that covers that. I do know I've done it as well. Do enough of it and we call it a rewrite.
More typically the refactoring cycle is done, not with "make the design awesome" in mind but a new feature in mind. The refactoring rearranges the code in a way that makes adding the new feature easy. By doing the refactoring first we spare ourselves the pain of fighting the old design. Of course sometimes refactoring is just cleaning up the code. So there is a little fuzziness about exactly where that "start" step really goes.
-
Can you elaborate more on "make the design awesome" vs "fitting a feature"? I would feel that fitting a feature is awkwardly short-sighted. Can you explain that more?Mark Miller– Mark Miller2018年03月05日 08:10:47 +00:00Commented Mar 5, 2018 at 8:10
-
2@MarkMiller Fitting a feature isn't awkwardly short-sighted. It's blissfully short-sighted. It's a refactoring with a clear goal and definite need. "Make the design awesome" is neither.candied_orange– candied_orange2018年03月05日 10:13:02 +00:00Commented Mar 5, 2018 at 10:13
-
Can you please define your terms? What is "BDD"? I know that "TDD" is test-driven development, so I assume BDD is <Something beginning with B>-driven development? Business? Bees?user1118321– user11183212018年03月21日 02:10:21 +00:00Commented Mar 21, 2018 at 2:10
-
@user1118321 better?candied_orange– candied_orange2018年03月21日 02:47:44 +00:00Commented Mar 21, 2018 at 2:47
Martin Fowler in his book about "refactoring" describes it as putting on different "hats".
For me it is a part of a broader programming cycle:
Write code -> refactor -> write code -> refactor ->...
It doesn't have to be TDD. It just happens to be an integral part of it.
-
I wish the down-voters would give a reason here. I find Martin Fowler's approach to refactoring quite practical and easier to deploy (less risk of bugs slipping from the MR reviews etc.)...Halil Sen– Halil Sen2024年05月28日 17:33:39 +00:00Commented May 28, 2024 at 17:33
No process that i can think of. However there is a process of understanding the problem which is initial development and then once you have consolidated what needs to be done in you mind refactoring the code to make it simpler and more maintainable. I know this is often what i will do.
@CandiedOrange does show the accepted practice of TDD with some nice graphics :) . BDD does also feed into changing unit tests but I find this happens more often than not only when bugs are found.