[ajug-members] Which Source Version Control System do you pre fer?

[Justin Meads]

In my environment, we would turn a large refactoring into an  
"Architectural Feature" and allow the customer to prioritize it into  
a release.  In all of the agile methods i am aware of, the customer  
decides what work should be completed in any given release.  Our  
customers have been very good about letting us make several very  
large refactorings by prioritizing them into releases.  Of course we  
have to present a good reason for doing it.

It is interesting you mention entropy.  If you were to leave a system  
untouched for 100 hundred years, it would be exactly as you left it.   
Software left alone will not deteriorate.  What causes software to  
deteriorate is constant unchecked change.  Based on my experience i  
only want developers on my team to change code if it is relevant to  
their assigned task.

-Justin



On Dec 2, 2005, at 9:09 AM, Christopher Gardner wrote:

> Assuming you have a good set of unit tests in place, if you see the
> opportunity to improve the code, you should do so, lest your software
> fall into entropy.  Granted, you may have to ask your project
> management for a 1 week refactoring iteration for big refactorings.
> In fact, it might be a good idea to schedule a cleanup iteration from
> the get-go (say after 3 or 4 iterations).
>
> What would be an unnecessary change to code?  Changing a method name?
> Breaking a 1000 line method up into a few composed methods?  Giving a
> class a single responsibility by moving its errant code to another
> class?  Such things make code more maintainable, amenable to change,
> and may even lower the likelihood of defects.
>
> You mention that it is always dangerous to change working code.  Isn't
> it more dangerous not to refactor code when it needs it?  Changing the
> name of a class to something more appropriate for the domain, for
> example, while potentially far reaching, may clarify an important
> concept for exisiting and new developers.
>
> On 12/2/05, Justin Meads <jmeads at adelphia.net> wrote:
>> Actually we do it to discourage any unnecessary changes to the code.
>> It is always dangerous to change working code even if you have unit
>> tests (it is just less dangerous with tests).  Remember Martin Fowler
>> has a big section in his book on when not to refactor.  That being
>> said, we strongly encourage the developers on my team to refactor the
>> code if it is related to a feature or defect they are working.  We
>> just don't want them randomly "improving the code".  It would be hard
>> for us to explain to our customer why we introduced a new bug in a
>> section of the application that shouldn't have changed.
>>
>> We also use the defect information to perform code reviews.  We can
>> sit down in a small group and look at all of the code that was
>> changed in order to implement a given feature or defect.
>>
>> -Justin
>>
>> On Dec 2, 2005, at 12:32 AM, Eric Friedman wrote:
>>
>>> I also wondered why one would want to tie every check-in to a
>>> defect. I think Paul made some good points. But I think this would
>>> discourage refactorings. Maybe it depends on the maturity of the
>>> product and the discipline of the developers.
>>>
>>> Couldn't you get most of this information when needed from a report
>>> or a diff? I am not that familiar with Subversion. (But I will be.
>>> My team will start using it next week. I like the timeliness of the
>>> question and am happy to hear that the Subversion users are happy
>>> with it.)
>>>
>>> Regards,
>>>
>>> Eric
>>>
>>> At 09:03 PM 12/1/2005, you wrote:
>>>> IMHO, a comment in the code is not enough information to track
>>>> anything larger than a trivial change.
>>>>
>>>> Using your example, simply changing a method name (very easy in
>>>> Eclipse) can potentially have a far reaching impact: Any code that
>>>> calls that method, bean-mapping code, configuration code, database
>>>> schema, etc. I find it difficult enough to keep track of changes I
>>>> personally made a month ago, much less what's going on with a
>>>> large codebase that 20 developers are working on.
>>>>
>>>> A defect report provides a way to tie changes across the codebase
>>>> to a single point: The code changed, the reason changed, how to
>>>> test it, where to find more documentation. Further, a bug report
>>>> tied to a check-in tied to a release gives you a point to go back
>>>> to if (knock on wood) you should happen to make a mistake in the
>>>> refactor. I won't speak for anyone else, but I have made plenty of
>>>> stupid mistakes during "simple" refactors.
>>>>
>>>> Do I really think that I need a bug report to change the name of a
>>>> private method that is only called one place? No. But how often
>>>> does that really happen? IMHO, what really happens is that
>>>> developers want to get in there and write code and that the impact
>>>> and complexity of some "simple" changes can be much greater than
>>>> originally expected. Writing a bug report first (I think) is
>>>> similar to the XP practice of writing the test case first: What do
>>>> you want it to do? A good question to ask before writing the code.
>>>>
>>>> Just MHO, based on years of screw-ups.
>>>>
>>>> Christopher Gardner wrote:
>>>>> Why is it important to track have to tag every checkin with a
>>>>> specific
>>>>> defect or feature task?
>>>>> On 12/1/05, Christopher R. Gardner <chris.r.gardner at gmail.com>
>>>>> wrote:
>>>>>> Seems like waste to me.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: "Paul Philion" <philion at acmerocket.com>
>>>>>> To: "General AJUG membership forum (100-200 messages/month)"
>>>>>> <ajug-members at ajug.org>
>>>>>> Sent: Thursday, December 01, 2005 7:21 PM
>>>>>> Subject: Re: [ajug-members] Which Source Version Control System
>>>>>> do you pre
>>>>>> fer?
>>>>>>
>>>>>>
>>>>>>> Christopher Gardner wrote:
>>>>>>>> How do you check in code if you have to do a refactoring  
>>>>>>>> that has
>>>>>>>> nothing to do with a requirement or defect (e.g., renaming a
>>>>>>>> poorly
>>>>>>>> named class, changing a method name, etc.)?
>>>>>>> Write a defect to track the refactor.
>>>> _______________________________________________
>>>> ajug-members mailing list
>>>> ajug-members at ajug.org
>>>> http://www.ajug.org/mailman/listinfo/ajug-members
>>>
>>>
>>> _______________________________________________
>>> ajug-members mailing list
>>> ajug-members at ajug.org
>>> http://www.ajug.org/mailman/listinfo/ajug-members
>>
>> _______________________________________________
>> ajug-members mailing list
>> ajug-members at ajug.org
>> http://www.ajug.org/mailman/listinfo/ajug-members
>>
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members