When I first started writing code, I just wrote whatever I wanted, without regards to format or style. If something wasn't working, I just figured it out myself without ever asking someone for help. And even though I always wrote simple programs (usually homework) I often found myself stuck for a long time only to find a simple little error that I could change in less than a minute.
Not only did I do things by myself in whatever rough, ship-shod way I wanted, I never practiced anything . I just started straight off on my programs, sometimes having to redo almost all of it because I realized that there's a huge logical error in the way I structured something.
As things became more complex, I found myself thinking about what I was going to code and practicing small little things first before putting it all together. And then when I had trouble I found myself going to others for advice or help. Because suddenly others are involved, I needed to start thinking about how to style, review, and distribute what I wrote. Here are a couple things I (slowly) began to realize.
When you write something, it's important to review the code in addition to actually testing it. Testing is good for finding defects or bugs, but often I would write a program, check it for bugs, and then call it a day, only to find out that I forgot to implement something important. By reviewing my own work, I was able to make sure everything that needed to be in there was. In addition, I was able to cut down on actual coding time because with things planned out and reviewed systematically, I didn't have to rewrite as much as I normally would. And then later, when I reviewed things in group projects, it ensured that everyone had some idea of what was going on with the program. (instead of having one person do all the work and the rest sitting idly.)
So when you test, you can also review what you're going to test! For example, in a previous blog or two I was talking about my robocode project. In testing it, I really had to think about what to test. There were no super obvious defects because the robot run and generally shot at the enemy. But by first making tests for each helper function, I was able to ensure that they gave the correct output each time (and I found that they didn't!) Then I made some behavior tests to make sure the robot did what it was supposed to every time. Like for some reason, my robot would always miss when robots stopped to turn and then started moving again. It thought of them as stationary targets and fired a wave of bullets, all of which missed once the enemy moved just a bit. By testing behavior, and things like movement or firing, you can further ensure that your robot works correctly and this requires some review of the tests.
Also in terms of reviews, there are multiple "techniques" or "forms". The one that I most utilized was a "code walkthrough" which involved me asking people to look at my code and tell me what's wrong. Or I'd say I'm interested in implementing something and do they have any ideas on how to do it. It's quick, it's easy, but a lot of times people wouldn't be able to help. No harm in trying though right?
Another form that I found used often in programming classes is technical reviews. They involve looking at code for defects, and then noting it or writing something down that the writer can look at later. Because these required knowing what to look for, and usually forms to fill out, it was more time consuming than walkthroughs but probably helped me out more.
And lastly, something that I haven't actually tried, but have heard of is inspection. This one seems the most time consuming but most useful of all. It involves planning things out, forming teams, looking at objectives, making comprehensive lists of errors, fixing them all, and verifying that they've been fixed. It involves multiple people and a lot of planning which makes it troublesome to do in a classroom setting. And because we're usually writing simple things, it may be overkill. But out in the "real world" I feel that it's really useful.
In addition to reviews, I used a build system to get all the files together when I distribute some programs. I found it really useful, but using build systems was something new to me. Also, the programming theory and styles was a lot different compared to writing in something like Java, or C. In those languages, I wanted to waste as little space as possible, by not including things twice, or double declaring variables. But in a build system, I found myself adding dependencies to everything I needed, regardless of if something else also depended on it. The reason for this is that if someone has part of the files they need but not the others, the necessary dependencies may not run. Also, build systems are cool and don't rerun things you've already done so it never hurts to just go wild with dependencies and make sure everything required goes on every target or function.
Finally, moving away from reviews and going back to how I started practicing simple things then adding them together, is the concept of a kata. In Karate, a kata is a formalized set of movements and techniques that you can do over and over to refine and perfect. In computer programming, it's a training exercise designed to help the learner gain some understanding in to concepts and make/fix mistakes without having an actual cost to it (like it would if you made mistakes when developing some professional software) So by doing simple little katas it becomes a lot easier to make something more complex, something I especially noticed when writing my robot.
That's all I can think of for now, and really I've probably written too much already. Till next time then.
No comments:
Post a Comment