Luis made a blog post explaining some difficulty he was having in evolving the design the code he's working on for the class. While I can't give him incredibly direct information, here are some general tips.

---

Luis made a post saying he was having some difficulty evolving the design now that stack pointer dereferences are coming into play. Specifically, the class he is using to track values in the analysis is now being pulled in too many directions. For all you XP/TDDers reading, it is a little more complicated than the standard TDD Stack Collection interview test. That being said, it isn't shouldn't be *that* much more complicated. Sometimes high-level advice can be very effective because code is code, and if you've paid attention to these issues long enough you can get a good idea of the root problem. Here is some generic advice for anyone who similarly gets stuck.

First, look through all the tests. Are there are that are redundant or written in a confusing way? Refactor the tests and the interfaces to be clearer first. Sometimes in the rush of making things pass, it's easy to be so happy with good progress and velocity that one forgets to listen to the code. The code will tell you what to do, usually.

Now that the tests are clear, with no duplication, does the class express its intention clearly? Each individual method? Look for code smells like coupling, temporary variables, cohesion, duplication, etc. Refactor away from those smells. Use the Refactoring book's front and back index of smells to help guide things.

With the code and tests clear, you're now in a good place to talk to someone out loud about the problem. Do this away from the code. Find some technical peer, meet up with them in person, and tell the story and the conflict. In person is important -- visual cues, hand expressions, etc can really make the difference. Sometimes just talking about it out loud and slowing things down in the process lets you see a salient detail that you were previously passing over in your rapid thoughts.

If that still doesn't help, stop looking at the code. In this specific case, take a look at the static analysis whitepapers mentioned on the prep page . Specifically, check out the Buffer Overrun Detection using Linear Programming one. It has good discussion about value tracking, constraints, etc. Preferrably, print the paper, go for a long walk to a cafe, sit down, and read it through and highlight/annotate away. Take your time and finish your beverage before getting up -- rushing into things can force a solution that might work but with consequences that can't be seen in the high-speed chase toward "done". Get a peer to read the papers with you, look over all of them together, and then discuss. Then try the previous step again and see if that helps.

This might sound really 'granola', but give it a try. Taking a deep breath, getting some distance, and slowing down almost always yields better visibility of the path to take than being in the thick of things and trying to force a path through.

Discussion: showing all 0 messages

(No messages)

>

Post a new message:

---