When developing using BDUF log files are often used to determine expected input and output. The log file is a valuable tool that can be used to determine the source of bugs and problems.
However, once you step into the world of Test Driven Development you should leave the log file in the past. Instead of depending on a log file, the test suite should test for boundry cases that would appear in a log file.
BDUF is walking (or crawling), but Agile development is running. When you want to run, leave the crutch behind.
Excepting hardware that fails, network servers that drop off the network, performance results, 'random' input from sensors etc. I'd never have anything to log ... I've never really used a log file to show my code faults up anyway.
ReplyDeleteThe best use I have for log files is for when users tell you they can't remember what they did, and watching UI 'button presses' in order to look at optimising the UI experience.
You're right on. I was discussing using logs to "verify the code is doing what you expect."
ReplyDeleteNice note on logging user actions to optimise the UI. I love the concept, but I can't say I've worked on many projects where the sponsor would actually pay someone to analyze the data. Still, I think it's a great idea.
I disagree with this sentiment. The power of logging, at least for me, is when the system is in production. I don't know about your production systems, but I've almost never had access to run my test suite or a debugger against a production server. Often, the log files are the only clues I get as to what is going on.
ReplyDelete1)I agree TDD is the way to go for application development
ReplyDelete2)Anybody who has ever had to support a production application wouldn't dare write this... you should really get a clue as to what's up.
You == Naive
Yes, ideally your software is 100% fully tested and nothing ever goes wrong and everything is just perfect.... Ahhh, what a happy place... Unfortunately that is not the world where I live and work and log files are a necessary evil. I think the key is not getting rid of logs in general, but tightening up the use of the log facility ... i.e. using the correct log levels in the right spots of the application so the logs are actually usable when something does go wrong.
ReplyDelete