Refactoring : Improving the design of existing code by Martin Fowler

[shoneill]

I have just bought and am slogging through the aforementioned book on refactoring.

 

While it focusses mainly on OOP (not a problem for me) I was interested to read that the author mentioned that the scope of the information is really rather limited due to specific idiosyncracies of particular languages or applications.  I immediately thought of LabVIEW (I wonder why that would be) and wondered if there was ever any ideas to approach the idea of refactoring along the same lines of this book.

 

I know we've been receiving lots of helpful information regarding the seminal Gang Of Four book regarding design patterns but I think the missing link for many users who have existing code is how to get from here to there.

 

Due to the different programming paradigm of LabVIEW, refactoring often looks a bit different and we have probably got our own set of spaghetti nightmares.  Add to this the aesthetic aspect (readability aspect) and you have a significantly different approach required.

 

While I have my own refactoring experience I was wondering if there are any such standardised approaches to refactoring in LabVIEW?

[Jordan Kuehn]

At risk of sounding stupid, which book are you referring to?

[shoneill]

Title of the post:

Refactoring : Improving the design of existing code

written by Martin Fowler

 

HERE

 

Shane

Edited August 21, 2014 by shoneill

[Jordan Kuehn]

*woosh* I completely missed that.

[PaulL]

Well, I think refactoring (in an OOP context, at least)  is for the most part a reasonably straightforward application of design principles, such as the Single Responsibility Principle (see http://smile.amazon.com/Head-First-Object-Oriented-Analysis-Design/dp/0596008678/ref=sr_1_1?s=books&ie=UTF8&qid=1405959788&sr=1-1&keywords=head+first+object+oriented+analysis+and+design,  for one) to achieve certain goals (maintainability, reusability, etc.).  I think using a modeling tool  (I'm thinking UML here) greatly expedites the process--and I think the modeling shows that the differences between OO languages, at least at some levels, are not so great.  (There are essential differences, of course, but I think many classes--at least the lower-level blocks--will have the same basic structure in any OO language. At the level of more complex constructs such as design patterns, there is perhaps a little less commonality, but the principles are still the same.  I have not, however, read this particular book of Martin Fowler's.  Maybe I should read it....)  

[shoneill]

I think the way from UML to design pattern is more or less documented but the aspect of refactoring I am missing is when you have inherited a bloody mess of entangled (non-LVOOP) code from someone and getting from THERE to a proper decision of what when and how to refactor it.

 

I'm talking about large code bases which have grown organically over years and comprise several hundred (or even thousands) of VIs.  Many of these VIs make (to me) some VERY dubious design choices but the tenmillion dollar question is: Where to start refactoring.  There are several aspects to the code which I would love to change but they touch nearly every VI in the hierarchy.  Making changes there breaks everything.....  Knowing where to start unravelling the ball of twine is sometimes the difference between success and abject failure.

[ShaunR]

 but they touch nearly every VI in the hierarchy.

 

Thats where you start. Modularise. Compartmentalise and simplify. In tLabVIEW. It's usually a bottom up, iterative process and diamonds are a programmers best friend.

 

Oh. And refactoring doesn't necessarily mean re-architecting.

Edited August 21, 2014 by ShaunR

[Mark Balla]

I had these 2 links concerning re-factoring in my archive

 

http://labviewguy.com/refactoring/

 

http://www.ieee.li/pdf/viewgraphs/refactoring_labview_code.pdf

 

They help break it down into parts to think through but I've not found any silver bullet when it comes to re-factoring.

I always seem to have lots of backups and forced to do lots of testing. Commiting often to Source code control was a big help in my last re-factoring project.

 

Mark

[shoneill]

Thanks.

 

I found those two links yesterday.  I still think that there are certain types of code smell which are typical to LabVIEW which would benefit the community if we could categorise and name them.  The immediate follow-on to that is detailing ideas on how to actually refactor them into better code.

 

Please note that I'm not necessarily looking for resources for myself, I just happened to think that it's weird that we don't have any kind of resources in that direction.