Clearly, the initial thing is to build a mental model of the software, then - guided by that model - look at the specific parts of the code that might be problematic. But what does that mental model look like?
Embarrassingly, I haven't dedicated any time at all to researching the literature in mental models of programming, despite having written a blog called Semantic Programming for two years. A good place to start might be with this paper (CMU and Microsoft Research) and its citations.
A brief sketch of the mental model I've built of Fly might be something like this:
- The "main" file sets up the UI, then starts the thread; the thread starts the Plover listener and then goes into a standard Pygame loop.
- During each turn around the loop, Fly checks up on all the parts of the UI, checks and handles keyboard and mouse events, and redraws the UI appropriately.
... You know, writing it all down would be impossible. (Which is why nobody ever does.) It is literally easier to just poke around in the code for a day, which is essentially the problem with programming. How do you get from code to a simulated mental model? That's probably more important.
No comments:
Post a Comment