Fwd: Compiler Guided Refactoring.

John Carter <[email protected]> Tue, 2 Jul 2013 15:41:54 +1200
Newsgroups gmane.comp.programming.refactoring
Message-ID <CAFD1m3FUf7gcqpyHfK2-DDAVZ8EEM7ANk4O9D+Kn8jmtk0mMKQ@mail.gmail.com>
The context for this is a Very Large body of embedded C, real time
critical, resource constrained code.

So, we have an opportunity to get a bunch of Summer Students in to "do
stuff".

Now this is always a bit of a problem... it often takes a highly experience
developer 6 months or more to become really useful and good at not
accidentally breaking things.

So I have an idea.

A very simple idea.

I plan on getting the summer student to play a very simple Refactoring Game.

He(she?) may change a single declaration in a single file....

And then compile.

The _only_ sort of change permitted is a _strengthening_ on the constraints
checked and enforced by the compiler (and/or splint).

No change of behaviour is permitted. ie. True refactorings only.

If it fails and can be trivially fixed, eg. Making the same change to the
definition as made to the declaration. Do so, else, revert.

Maybe make a note of what you were trying to do, but revert the change.

If the fix would have involved first doing a matching tightening of a
declaration used by some dependent part of the code... revert and make that
change first. (Mikado Method style)

If it compiles / links / runs tests.... push to the mainline.

The changes I expect to make are utterly trivial....

Make something "const".

Make something that is "global" scope, file "static".

Make a file scoped "static",  function scoped.

Split big uncohesive files.

Remove a #include.

The critical factors here are....
* True refactorings only (no change in behaviour).
* Trivial changesets, trivial to review.
* Trivial changesets, whose value is banked hourly.
* Only strengthen constraints the compiler enforces.
* No introduction of risk.

Any other strengthenings you can think of?

Of course, a Good Summer Student is going to get Bored Silly.

He will be Lazy with a Big L.

He is going to get Impatient.

He will believe he can think a Better Way of doing this....

And therein lies the True Challenge.



--
John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                       Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch       Email : [email protected]
New Zealand

-- 

------------------------------
This email, including any attachments, is only for the intended recipient. 
It is subject to copyright, is confidential and may be the subject of legal 
or other privilege, none of which is waived or lost by reason of this 
transmission.
If you are not an intended recipient, you may not use, disseminate, 
distribute or reproduce such email, any attachments, or any part thereof. 
If you have received a message in error, please notify the sender 
immediately and erase all copies of the message and any attachments.
Unfortunately, we cannot warrant that the email has not been altered or 
corrupted during transmission nor can we guarantee that any email or any 
attachments are free from computer viruses or other conditions which may 
damage or interfere with recipient data, hardware or software. The 
recipient relies upon its own procedures and assumes all risk of use and of 
opening any attachments.
------------------------------


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/