Debugging...
-
What are your methods? One does not simply debug it | CommitStrip[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
What are your methods? One does not simply debug it | CommitStrip[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
What are your methods?
Well, I take several approaches, often multiple ones: 0. Determine test fixture -- what do I need to set up to actually debug / test? How do I isolate the test fixture? How can it be automated so I'm not clicking through the UI? 1. Write the test first. I actually do this very rarely because I find it hard to express the test results ahead of time. It's only when I write the actual code that I think, ok, this needs to be tested, that needs to be tested. Also, when dealing with new technologies, I often don't know what the format of the data is until I get the hardware or API working -- what does the card scanner actually give me, what does the JSON actually look like? 2. Step through the code. I do this almost all the time to make sure that I'm understanding correctly the tech with which I'm interfacing. 3. Write the test after writing the code. For certain things, I definitely do this. Once the baseline code is working, I can then throw different scenarios at it. Useful scenarios that represent anticipated use cases, not just mindless contract testing or the like. 4. Debug the tests. 5. Try out the code via the UI. Funny thing is, that often reveals things I didn't consider. 6. Put the app in front of someone else. Not so funny is seeing how other people go about using the app, and the bugs that are revealed in that process. Not just algorithmic bugs, but also UX bugs -- if the user experience sucks, I consider that a bug. 7. Put the app in front of select customers. Very revealing and is the best way to discover that the spec itself is buggy. So debugging is not just about code. It's about the user experience, whether the spec accurately captured the user's needs, and understanding how stuff is used in the wild. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Kornfeld Eliyahu Peter wrote:
What are your methods?
Well, I take several approaches, often multiple ones: 0. Determine test fixture -- what do I need to set up to actually debug / test? How do I isolate the test fixture? How can it be automated so I'm not clicking through the UI? 1. Write the test first. I actually do this very rarely because I find it hard to express the test results ahead of time. It's only when I write the actual code that I think, ok, this needs to be tested, that needs to be tested. Also, when dealing with new technologies, I often don't know what the format of the data is until I get the hardware or API working -- what does the card scanner actually give me, what does the JSON actually look like? 2. Step through the code. I do this almost all the time to make sure that I'm understanding correctly the tech with which I'm interfacing. 3. Write the test after writing the code. For certain things, I definitely do this. Once the baseline code is working, I can then throw different scenarios at it. Useful scenarios that represent anticipated use cases, not just mindless contract testing or the like. 4. Debug the tests. 5. Try out the code via the UI. Funny thing is, that often reveals things I didn't consider. 6. Put the app in front of someone else. Not so funny is seeing how other people go about using the app, and the bugs that are revealed in that process. Not just algorithmic bugs, but also UX bugs -- if the user experience sucks, I consider that a bug. 7. Put the app in front of select customers. Very revealing and is the best way to discover that the spec itself is buggy. So debugging is not just about code. It's about the user experience, whether the spec accurately captured the user's needs, and understanding how stuff is used in the wild. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Oh, Marc! That was far too serious for Sunday...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
What are your methods? One does not simply debug it | CommitStrip[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
Oh, Marc! That was far too serious for Sunday...
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
Kornfeld Eliyahu Peter wrote:
That was far too serious for Sunday...
I know. :) But it got me thinking! Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
What are your methods? One does not simply debug it | CommitStrip[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
What are your methods? One does not simply debug it | CommitStrip[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
You don't work for HP do you?
-
What are your methods? One does not simply debug it | CommitStrip[^]
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
I test as I go. I'd rather debug 10-50 lines than get 100's of lines in to find I must have been smoking the wacky taccy with code that had no hope of ever working. When people bring me code they want help debugging, I usually gut the code to something smaller and gives proof of concept instead of dealing with all the bells and whistles they coded before finding if the core code was going to work in the first place.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
