Dave - that is excellent!!! If I was still running a team of programmers I would print it out and pin it on the wall. I try and follow those precepts myself (with greater or lesser success <g>) but don't always succeed.
John Weller 01380 723235 07976 393631 > > Whil, > I think that the secret is in the documentation of the system(s) you do > before beginning the project. In a word (or three) Design, Design and > Design. > > There is an excellent book called "The Pragmatic Programmer: From > Journeyman > to Master" by Andrew Hunt and David Thomas has some good reading in it > regarding refactoring or generating code from projects that have > been picked > up again or from other people. > > > Although not 100% relevant to your question but useful when coding in > general, I particularly liked the following recommendations > amongst some of > my own: > > 1. Use the DRY Principle (Don't Repeat Yourself) > Keep the low level knowledge in the code where it belongs and reserve > comments for other high level explanations and simple diagrams. > > 2. Design Orthogonal Systems > This effectively removes the "Effects Between Unrelated Things" and allows > you to pick up projects/code without having to absorb the whole > thing first, > which is difficult after a layoff. In the book he describes a "non > Orthoganal" system to be akin to a helicopter. Only three > controls but they > all have a mutual effect on each other. The collective moves you > up and down > but when you descend the helicopter moves its nose down and > begins to rotate > to spiral - a secondary effect. Lower the left hand lever and you > then need > to add compensating backward movement to the right hand stick and push the > right pedal erc etc. Those of you who have tried to hover a > helicopter will > understand that it is a constant juggling act trying to balance all the > interacting forces. Modifying a system designed in this way is > consequently > a nightmare - so stop it happening. Designing a project in layers > provides > a level of abstraction because each layer should only use the abstractions > provided by the layers below it. > > 3. Keep your code decoupled > Always ensure your code remains isolated from the implementation of other > outside code > > 4. Avoid global data > Not always possible I know, but a good rule of thumb to keep to > if possible. > > 5. Always be critical of your own code > Look for any opportunity to improve structure and the resultant code when > revisited will require the minimum amount of modification. It is > always more > difficult to remember what you "thought you should do to code 6 > months ago" > as opposed to "what you have to do now" to improve a system > > 6. Testing > Have a fully documented set of tests to carry out after any modifications. > That way the "oh, I'll just add this code...I'm sure that it won't affect > anything else" phrase won't come back to haunt you. > > 7. Use the "Tracer Bullets" technique > As it says in the book "There are three ways to fire a machine gun in the > dark" > a. Find out the exact conditions, location of the target, specification of > your machine gun and use the manufacturer's tables to calculate the exact > elevation and bearing to fire on. If you estimated correctly you will hit > the target. > > b. Close your eyes and spray bullets wildly in the general > direction of the > target - how many systems have you seen where this is the norm? > > or > > c. Use tracer bullets > These are bullets loaded onto the ammo belt at intervals which burn > phosphorous when fired and "glow in the dark". If the tracer bullets are > hitting the target then you know damned well that the intervening bullets > are as well. > > Inserting code into a system the equivalent of "tracer bullets" gives > instant feedback and can produce major changes in the way you approach a > project. Rather than designing a "fixed specification" allow the tracer > bullets to refine the final "system" and don’t be afraid to refactor the > design based upon the "tracer bullet" results. This is a much > better method > than prototyping in the normal sense of the word as it can give actual > factual performance data back immediately. The added benefit is that you > will have something to demonstrate very early on in the project - which > customers like. Leave these tracer bullets in to indicate the > current status > of NEW code that needs to be generated or features that need to be added > > 8. Save all your estimates and be critical of them when making NEW > estimates. It is really easy to just say "No problem - I can do that > easily". How often have you done this and when revisiting the code the 5 > minute job took 5 hours. If you ever make an incorrect estimate, > then LEARN > from it by finding out WHY it was incorrect. > > 9. Use the Rubber Duck Technique > If possible when trying to pick up a project take time out to explain the > project design to another person. Their head should just be nodding like a > "rubber duck in a bathtub" regardless of whether they understand or not. > HOWEVER, the very fact that you are explaining the design/problem to a 3rd > party in detail will allow you to get a full insight into the > project. Note > that the 3rd person can be inanimate - it is the action of > describing simply > to someone/something else that makes the technique worthwhile. > > 10. Use the correct language for the job > Need I say it - VFP!!! > > _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
