Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

How to measure the risks of refactoring an application that has no documentation?

 
Ranch Hand
Posts: 75
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there a way to measure the risks of refactoring an application that has no documentation?
 
Sheriff
Posts: 16660
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's look at the assumptions that this question suggests:

1. Having no documentation makes it risky to refactor
2. Having documentation makes it less risky to refactor

With either assumption, I would say it depends on what you consider as "documentation".

Textual documentation in the form of code comments or, God forbid, Word documents, is unreliable, IMO. There's a good possibility that these kinds of documentation are either inconsistent or incomplete. At worst, they are obsolete and altogether wrong. I would argue that documentation that does not accurately reflect the current state of the code is worse than having no documentation at all and it poses a greater risk to refactoring. At least when you have no documentation, you are forced to turn to the code to see what's actually happening. Documentation that is not accurate can lead you to doing things you really shouldn't be doing.

On the other hand, if you agree with Jack Reeves about code being design, then you will consider well-written code and tests as themselves being detailed documentation. This kind of documentation, IMO, is a more superior kind of documentation. Tests should be written so that they document details of the design. Having well-written tests as detailed documentation is a great help in refactoring. If you have no tests, then you have to turn to the code. Code itself should be self-documenting. If code is unclear and isn't self-documenting, then the risks of refactoring are higher.

How to measure the risk is another story. Why do you feel you have to measure that risk? I would say if I had to have one, my scale would be very course-grained, like "a lot", "some", "very little", and "none" based on the kind of documentation you have, as I mentioned.
 
Junilu Lacar
Sheriff
Posts: 16660
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<shameless-plug>

I recently had a very long discussion in the Design forum about doing TDD to implement a Vending Machine program.

The self-documenting nature of code and tests documenting the design can be seen in this example:

https://github.com/jlacar/ranch-samples/blob/master/samples/src/test/java/com/coderanch/samples/design/vend/VendingMachineTest.java

</shameless-plug>
 
Junilu Lacar
Sheriff
Posts: 16660
278
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This just occurred to me but how much of the risk of refactoring do you attribute to other factors? What are some of those factors?

One factor, which can perhaps be seen as rather cynical, are the skills of the person or people attempting to do the refactoring. Realistically and honestly though, a skilled developer will pose a lesser risk than one with less experience and/or skills. Who would you rather have do the remodeling of your kitchen, a bonded contractor with a good track record and excellent references or some random guy running a fly-by-night operation?
 
Marshal
Posts: 26912
82
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd agree with Junilu that the skills of the people who will be doing the refactoring constitute an important factor. Another factor is the size of the application -- I would suggest that the cost to refactor increases at least as fast as the square of the size of the application. Whatever "size" means... that could be estimated in many ways, of course.
 
reply
    Bookmark Topic Watch Topic
  • New Topic