Quora Feeds
Active Member
Marcus Geduld
For me, the answer is test-driven development (TDD) and composing apps out of small, testable units. This is counter-intuitive, because it means writing more code than if I skip the tests, and it's certainly true that more keystrokes = more time. But what takes even more time is fixing bugs.
When I code without testing, I make constant mistakes, and I spend hours fixing them. My mistakes are unpredictable. I'll be speeding along without a hitch and then, all of the sudden, a single bug will set me back three hours.
Often, that happens at the "just one more thing and I'm done," stage. I'll call my wife and say, "I'm wrapping things up, here. What do you want for dinner?" Next thing I know, it's 2am, and I'm still in the office.
To my surprise, when I switched to TDD, I sped up. Not immediately, because I had to get past the TDD learning curve. But once I'd done that, coding became easier, less stressful, and faster.
Now, I write a test for a function, run the test, watch it fail (because the function doesn't exist yet), and then write the function so that the test passes. Once I've done that, I can move on, because I have a unit I know works. It's relatively rare that I find any bugs in code I've developed that way.
I have four rules of thumb that also help:
1. I get suspicious if a function is more than eight lines long.
2. I get suspicious if a function has more than one sub-level of indentation inside it. In other words, a conditional is fine, but a conditional inside a conditional is fishy.
3. I get suspicious if a function takes more than three parameters.
4. I get suspicious if I have to scroll to see all of a file.
Sometimes one needs to write long, complex functions or files, which is why I get suspicious, not forbidding. Complexity is a code smell, not an indicator of code that is definitely bad. Still, I keep an eye on it.
One more trick: I continually work on the lowest-hanging fruit. Let's say I'm coding Pacman, and I have no idea how to write the ghost AI. My strategy is to ignore the problem. I code whatever I do know.
Sometimes, that's very little. Perhaps, with Pacman, I don't know how to represent the maze; I don't know how to make the Pacman move; I don't know how to make him eat dots ...
Okay, but I do know how to write a function that adds points to a high score. I don't know how to display the score, but I know how to add 100 + 500. So I'll write that (using TDD). Then, when that's done, I'll work on the next-lowest hanging fruit. Maybe it's displaying a single dot on the screen ... I'll keep doing this until there's no fruit left.
Which speeds me up, because, inevitably, the little solutions I find for easy problems suggest solutions to the harder problems. It's really hard to mentally grasp how to make ghost AI when you don't even know how to draw a ghost, or a maze, or how to represent the ghost and maze as data structures ... So I start small and gradually build on top of the simple things I've already built. Brick by brick.
This speeds me up, because I don't wind up staring at the screen, thinking, "How the hell am I going to do that?"
Sometimes, when I finally get to the hard problems, I realize they don't exist. Without trying to, I've taken so many little bites out of them, there's nothing left to chew on. Writing no code is the fastest way to program.
See Questions On Quora
Continue reading...
For me, the answer is test-driven development (TDD) and composing apps out of small, testable units. This is counter-intuitive, because it means writing more code than if I skip the tests, and it's certainly true that more keystrokes = more time. But what takes even more time is fixing bugs.
When I code without testing, I make constant mistakes, and I spend hours fixing them. My mistakes are unpredictable. I'll be speeding along without a hitch and then, all of the sudden, a single bug will set me back three hours.
Often, that happens at the "just one more thing and I'm done," stage. I'll call my wife and say, "I'm wrapping things up, here. What do you want for dinner?" Next thing I know, it's 2am, and I'm still in the office.
To my surprise, when I switched to TDD, I sped up. Not immediately, because I had to get past the TDD learning curve. But once I'd done that, coding became easier, less stressful, and faster.
Now, I write a test for a function, run the test, watch it fail (because the function doesn't exist yet), and then write the function so that the test passes. Once I've done that, I can move on, because I have a unit I know works. It's relatively rare that I find any bugs in code I've developed that way.
I have four rules of thumb that also help:
1. I get suspicious if a function is more than eight lines long.
2. I get suspicious if a function has more than one sub-level of indentation inside it. In other words, a conditional is fine, but a conditional inside a conditional is fishy.
3. I get suspicious if a function takes more than three parameters.
4. I get suspicious if I have to scroll to see all of a file.
Sometimes one needs to write long, complex functions or files, which is why I get suspicious, not forbidding. Complexity is a code smell, not an indicator of code that is definitely bad. Still, I keep an eye on it.
One more trick: I continually work on the lowest-hanging fruit. Let's say I'm coding Pacman, and I have no idea how to write the ghost AI. My strategy is to ignore the problem. I code whatever I do know.
Sometimes, that's very little. Perhaps, with Pacman, I don't know how to represent the maze; I don't know how to make the Pacman move; I don't know how to make him eat dots ...
Okay, but I do know how to write a function that adds points to a high score. I don't know how to display the score, but I know how to add 100 + 500. So I'll write that (using TDD). Then, when that's done, I'll work on the next-lowest hanging fruit. Maybe it's displaying a single dot on the screen ... I'll keep doing this until there's no fruit left.
Which speeds me up, because, inevitably, the little solutions I find for easy problems suggest solutions to the harder problems. It's really hard to mentally grasp how to make ghost AI when you don't even know how to draw a ghost, or a maze, or how to represent the ghost and maze as data structures ... So I start small and gradually build on top of the simple things I've already built. Brick by brick.
This speeds me up, because I don't wind up staring at the screen, thinking, "How the hell am I going to do that?"
Sometimes, when I finally get to the hard problems, I realize they don't exist. Without trying to, I've taken so many little bites out of them, there's nothing left to chew on. Writing no code is the fastest way to program.
See Questions On Quora
Continue reading...
