Processes/conventions/styles/habits keep me from having to think too much. I find that thinking too much gives me problems. Processes/conventions/style/habits allow me to focus my resources on a problem without having to spend time thinking about mundane details like names, capitalization, indenting, etc. I'm trying to develop a process for programming so I can focus on what I need to do now and not have to worry about what to do next. I'm probably just lazy.
I've distilled this information from other pages on Wiki through my own programming habits. If I could remember where on Wiki that I saw this stuff, I'd reference it, but, unfortunately, I don't. Please add appropriate references. I also welcome anyone's comments or descriptions of their own processes for programming without thinking too much.
-- MarkAddleman
The process has three major steps: First, understand the change. Second, make the change easy. Third, make the change.
Understand the change:
- Understand the change from the client's perspective (where client is could be a user, another system, some other class or method)
I'd love to put more detail on this step, but the process for understanding requirements is still somewhat mystical to me. I've found there are really only two tools worth their salt for understanding requirements: Talking to interested parties and drawing pictures (mostly on whiteboards). Possibly using CRC cards; I've never used them, but they seem to be simply a way of combining talking and drawing.
Make the change easy:
- Establish a base line of the current code base and BACK IT UP!
- Examine the current code base to determine the easiest way to accomplish what I want to do (don't start coding yet)
- Collect and/or construct tests that cover the applicable portions of the current code base
- Make sure the tests run
- Decide how I want to change the current code base
- Apply the necessary refactorings to make my desired changes easy (don't add or change any functionality yet)
- Make sure the tests still run. If they don't, drop back to the baseline and examine the code base again.
Make the change:
- Establish a new base line of the new code base and BACK IT UP!
- Pick the smallest unit of work from the change that I can do and feel like I've accomplished something and still be done with it in about 15 minutes.
- Run the test and make sure it fails. If it doesn't fail, either rewrite the test or pick a larger unit of change.
- Code to the unit of work and nothing but the unit of work. Record all interesting diversions along the way, but don't work on them (Window's notepad works really well for this). For each interesting diversion, remind myself that I'll be done with this bit of work in less than 15 minutes, so I can get to it then.
- Run the test. If it fails, quickly check the test to see if it is bug-free and return to the previous step.
- Run all the appropriate tests. If too many tests broke, then I didn't make the change easy enough and I should stop and make the change easier. If the right number of tests broke, fix the tests and move on.
- Backup what I have, examine the code for duplicate code and readability. Apply any refactorings and rerun the tests. Backup again as soon as the tests run.
- Pause to make sure I really do understand the change. After mucking around with the code for this long, I may find that I do not understand the change as well as I thought I did. If I don't, backup the code the way it is, put it aside and drop back to understand the change.
- Look at my list of interesting diversions. Decide whether any of them are worth it keeping in my that WorkingCodeTrumpsEverythingElse?. Ultimately decide that most (if not all) aren't worth pursuing at the moment.
- Repeat this process until the change is complete.
AeGis is a big help in all this (Understand The Change, Make The Change Easy, and Make The Change).
After rereading some of the Wiki pages on ExtremeProgramming, I realized that my process doesn't include the concept of AcceptanceTests. Lately, we've been doing a lot of UI heavy coding and I find that automated tests of the UI are either too fragile or too complex to be very useful. So, we rely on visually inspection.
I find that "not thinking too much" is important in programming and unit tests are the way to do it, but none of the mundane things in the list really bother me: I consider names important, so they aren't mundane. Capitalization and indenting come from my backbone without much conscious thought. So what would be a better list of stuff to avoid by "not thinking too much"? I would suggest that the stuff you want to push out of your head is the parts of the program that are not changed. And the only way to comfortably forget about the rest of the system while doing changes is to have extensive unit tests. (Pair programming and acceptance tests also help.)
Process For Programming Without Thinking Too Much