1

I had a discussion with a co-worker yesterday about design philosophy. The other coder is more experienced then me, and I fully admit that he is likely much better at properly automating his testing, which I'm just now trying to break sloppy habits. However, it seems that some of our dispute is a philosophical issues where I'm unwilling to simply yield to his greater experience.

Generally he is a Directing programmer, who follows all of the formal approaches. He has interfaces for nearly every class and has automated tests for everything down to getter and setters on basic POJO objects. He sees refactoring as a dirty word which is a sign that things weren't written/designed properly from the start, it’s inevitable and done as necessary but everything should be done to avoid having to do it and you should feel bad when you have to.

I feel I'm a more flexible/Enabling programmer. I feel that interfaces should be used as necessary, but not thrown in until they are needed (KISS), and that it's easy enough to pull an interface out of an existing object by refactoring if you decide an interface/polymorphism makes more sense later. I also felt that, while I admit I need to be better at testing then I am currently, the level of automated tests he suggested seemed too rigors since it would take so long to implement and, more importantly, make refactoring a nightmare since I wouldn't be free to modify the behavior of any non-private method. As my requirements grow and change I find myself refactoring heavily and that level of testing feels like it would kill my flexibility. His view is that I shouldn't be refactoring so it doesn't matter if the tests make it harder to do.

Ultimately all of the other philosophical discussions seemed to boil down to the word 'refactor'. I love refactoring, I feel it should be used liberally any time you feel that something isn't quite as clean and beautiful as it should be, and that the natural course of growing a program or adding new requirements will necessitate refactoring to better enable code reuse, moving logic to new classes/packages as it grows more complex, and yes fixing inevitable design mistakes which will happen from a flexible agile development approach (and that’s not always bad if your code is written to allow modification!). He disagrees with all of that.

I'm wondering what other's thoughts are on refactoring. How common should it be? Is writing code with a philosophy of "I'm doing it simple now, I can refactor it later if more complicated logic proves necessary" inherently flawed/dangerous? Does acceptability of refactoring depend on program approach and style? I generally am on rapid prototyping or “clean up this ugly, but working, prototype some non-engineers wrote”, while it sounds like he actually gets to do formal programming with official requirements that don’t change; I’ve never once had a job like that myself!

Crono
  • 1,617
  • 15
  • 24
dsollen
  • 1,123
  • 1
  • 12
  • 28
  • possible duplicate of [Does craftsmanship pay off?](http://programmers.stackexchange.com/questions/82159/does-craftsmanship-pay-off) – gnat Apr 09 '14 at 13:30
  • 2
    I don't agree with the duplicate. To me, this question reads more as a debate between designing your code up front for all contingencies and growing your design. – Bart van Ingen Schenau Apr 09 '14 at 13:50
  • Could you edit this question a little please? A poll for others' thoughts is largely off-topic here. – Telastyn Apr 09 '14 at 13:56
  • `since I wouldn't be free to modify the behavior of any non-private method`. Are you implying you are now? If you change the behaviour of an API right now, you'll probably cause the client code to break. You can't change the semantics of anything with clients you don't own. – Phoshi Apr 09 '14 at 14:41
  • Interesting question. I refactor constantly and obsessively, so the question never even occurred to me. Interesting to call out the two views, because I've always just assumed that refactoring was part of coding. – sea-rob Apr 09 '14 at 17:42

4 Answers4

4

I think the answer lies in between the two of you.

Changes are to be expected as software evolves. No matter how competent you are, you can't predict the future with 100% accuracy. And even if you could, it may not match your customer's predictions or taste. Since he's the one who pays he (most unfortunately :) ) has a say in it. So unless it's dead simple, it's almost impossible to design an application with everything in it's right place from day one.

On the other hand, you still do have the responsibility to be, at all times, as close as possible to that. You have to plan and think ahead of requirements so that you will be less likely to paint yourself in a corner and make it nearly impossible for your code to adapt to new demands (and believe it, there will be demands).

Therefore, while I fully agree with you that refactoring is a great thing to do whenever you feel things could be better, calling it a "rule" doesn't sound quite right to me. If refactoring code is something you do on a daily basis then clearly something is wrong with the way you are coding your apps.

On this question:

Is writing code with a philosophy of "I'm doing it simple now, I can refactor
it later if more complicated logic proves necessary" inherently flawed/dangerous?

If you expect - or even just suspect - that more complicated logic will be required eventually, the answer is most definitely yes. If not then it really depends on code's usefulness, how deep it will be in your app, project deadlines and perhaps most importantly, common sense.

If your customer is a bike workshop in Wisconsin it's very unlikely that he'll need an app that supports international phone numbers. Therefore it's reasonable for you to design a PhoneNumber class that's really just holding a three digits area code and a seven digits number. In the unlikely event that it becomes necessary for your customer to store data on bikers from France, refactoring may then become helpful.

This is of course just an example but you get the idea: while at first it may make sense to write pretty straightforward code, as time passes and requirements changes you might find that the way your application now relies on it may be a problem. This is the kind of scenario which you should normally try to avoid but unless you're God you won't be able to avoid all of them. Sometimes it won't even be your fault; software customers tends to be very imaginative when it comes to transform a bike workshop management application into a pizza ordering system.

In any case, you should still always write code in the way you think it should be upon release. Think of refactoring as a way to fix things you made wrong assumptions on.

Crono
  • 1,617
  • 15
  • 24
  • 2
    YAGNI. I have suspected in the past many times that things were going to be needed, because they made sense logically. But for one reason or another (change on requirements, scope or even the project being cancelled) they never happened. So it was wasted time. – Miyamoto Akira Apr 09 '14 at 14:45
  • 1
    @MiyamotoAkira Granted that does happens, but depending on how much actual time you've put into it, it might not be a complete waste. The extra time you are taking designing your objects the way you think it should be helps keeping an overall coherent design. That alone may actually *save* you time. – Crono Apr 09 '14 at 14:55
  • Of course, refactoring usually is assumed to be a 'code thing', but if your bike app suddenly needs international phone numbers, you may be changing your DB schema (and customer web front end too). Refactoring your app isn't quite so trivial then, it would have been much better to have considered this up-front. – gbjbaanb Apr 09 '14 at 15:11
  • @gbjbaanb this is why I've used the terms "may be helpful". For such an unsuspected turn of events it's almost certain that refactoring won't be the only thing you will have to do. As for "considering this up-front", remember that requirements can change with time. A feature judged mandatory later could have been overkill on day one. – Crono Apr 09 '14 at 15:18
  • 1
    I'd like to point out that refactoring is not the same as adding features or changing behavior. It's a restructuring of code to make it more maintainable. So if you get a new requirement for French phone numbers, the code should have already been in a state where it's easy to add the new functionality. Refactoring happens when you realize it's not easy to add hypothetical new features. – Phil Apr 09 '14 at 16:25
  • @Phil, this is just an example. Of course it should be relatively easy to add support for French numbers to an existing `PhoneNumber` type. However, this added feature may lead you into rethinking its design. Especially if it did more than simply expose an array of digits. If for example you had an `AreaCode` property, it would now make sense for it to hold a `InternationalCode` too. And while we're at it, why not adding a `Extension` property as well? – Crono Apr 09 '14 at 16:56
  • (continued) Oh but wait... now how will that affect methods that formats the number for display? Will it still make sense to surround area code with parenthesis in other areas of the world? Will I want the international code to appear there as well in *every* case? Shouldn't I use parameters to determine that? See, these are the kinds of questions that might come with adding features and changing behaviors. So while at it's basic definition refactoring isn't the same thing, it remains something you will likely do in conjunction with that. – Crono Apr 09 '14 at 16:59
4

Embrace refactoring. Embrace the fact that you can create code that works, and you have tests that make it work, and then you can change the internals having confidence that you are not breaking anything. And as you mention, KISS.

About the view of not having written/designed correctly from the start, for me the answer is that I have not worked in a project in which there were no changes at some point (or rather, very often). Even if someone spent a month "designing" the solution. Changes that introduce duplication, that introduce generalization, that introduce new use cases. For all of them you will refactor.

Even as you are writing a fully "designed" solution, you will find that there is duplicated code, that there are generalizations not taken into account. Coding is designing, and until you are not done coding, you have not finished designing.

One other thing to add: YAGNI.

Miyamoto Akira
  • 2,265
  • 16
  • 17
  • Don't see why this was downvoted, makes sense to me. – Rory Hunter Apr 09 '14 at 14:25
  • Not the downvoter but I do not quite agree with that last sentence of yours. An application may have layers and it's perfectly reasonable to try and isolate them from possible changes while allowing other layers to evolve. – Crono Apr 09 '14 at 15:27
  • I do agree with isolating code. I do apply SOLID and layers on my code. Doesn't really change what I said. – Miyamoto Akira Apr 09 '14 at 15:32
  • 1
    hmm, not sure of the downvote - but I don't think coding is designing. "Think, then act" is my motto, no-one should need to continually refactor, especially as heavily as is implied by the OP. @Phil says it very well in his comment to Crono's post. – gbjbaanb Apr 09 '14 at 16:52
  • @gbjbaanb exactly, and I agree with him (and you). – Crono Apr 09 '14 at 17:01
  • "Think, Act, Evaluate" will be more what I follow. I don't know of anyone, personally, that can get a design 100% before starting to write code. But I agree that you only refactor as much as it is really needed, not changing something just to make it "beautiful". – Miyamoto Akira Apr 09 '14 at 20:30
1

It all come down to who writes better code relative to the amount of time. Your company/team should define what "better" means. Customers have something to say about this as well.

Make sure you have a solid definition of Refactoring. It sounds like you do, but you mention it along with code behavioral changes very close together in your question. Be careful. You two can't maintain this debate if you don't agree on the definition.

Out of everything the two of you are claiming, the biggest issue is his claim to be able to write code correctly the "first" time. Does this occur when code is checked in for the very first time or before it goes into production? Obviously the later gives you a little more time to get things right. Maybe he has worked on this particular project for so long that he is able to do it because he understands the code and the people asking for features. A new PM could be added who doesn't create as detailed of specs or may not understand the domain as much as the current one. Your method may make you more adaptable.

Does he take a disproportionate amount of time to achieve the same objective as you do with fewer bugs/need to improve? Code can be improved to a certain extent forever, but truly good code gets shipped. Do you introduce more bugs into the system? Users want new features and corrections sooner, but there is a point they get too frustrated with too many bugs popping up too often. Every time we update...

Your philosophical arguments are only just personal preferences until you can determine who is the most effective developer. Would your Directing programmer be able to do this on a new project? Are you using "I can refactor it later" as a crutch?

JeffO
  • 36,816
  • 2
  • 57
  • 124
0

I'd say the exception.

Every time you refactor, you're basically changing the way the code looks rather than the way it works (eg you might extract a block of code into a method, or change a switch to a polymorphic function call, in all cases the functionality hasn't changed, you've just altered it).

Now while this maybe useful to make the code easier to maintain or understand, it is still making large changes that will really affect the way your code shows up in the source control logs. You cannot now look at the diffs and see a bug because of a code change, as the code is radically different. Its the same problem when you change the look of code because you want to prettify it (eg change brace positions or rename variables).

So refactoring should really be kept for cases where it is really worthwhile, just so you can keep a sense of what the code does. I used to work with a guy who changed the code dramatically - I'd come in after a weekend and find the codebase was practically a different product. It made working with it tremendously difficult as I had to take the time to figure out where the bits I was familiar with had gone.

There is also a sense that refactoring is overused nowadays, a sense that coders should hack something together that works quickly, and then tidy it up to make it look good later (or even, just tidy it up as you go). I think this is a poor practice. You should think what you're trying to achieve before you do it. If this was done first, you shouldn't need to refactor. In the old days where design-first was much more prevalent, refactoring was solely used for legacy code, never for daily work.

I know one though - 'beauty is in the eye of the beholder'. You may refactor to make things look nicer, but then someone else may come along and refactor again to make it look nice to them (in Fowler's Refactoring book there are refactorings that are opposites!). You'll never stop, spending all day refactoring code and none actually writing product features.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 1
    Refactoring and bug fixes should not be checked-in at the same time. – JeffO Apr 09 '14 at 13:55
  • @JeffO absolutely. But someone who refactors all the time when they're writing new features won't be able to make the distinction. The OPO said: _I feel it should be used liberally any time you feel that something isn't quite as clean and beautiful as it should be_ – gbjbaanb Apr 09 '14 at 14:17
  • @gbjbaanb As long as the code has not been transferred to the test environment, there are no bugs, just unfinished code. Once you transfer to test (or uat, or live) then you have the bugs and you make the distinction. – Miyamoto Akira Apr 09 '14 at 14:50