Member Avatar for overwraith

I recently lost a job, pretty much because my previous employer expected miracles from an entry level coder. I was tasked with reading years worth of code developed in a sloppy manner (by another coder) in a production environment where I quite literally could not debug without disrupting somebody. There were no test servers implemented. You have probably all realized that it is a lot harder to read code than to write it. (gripe over, now comes the question...)

The question is, in C#/Visual Studio how would one debug in a manner which is non-intrusive to the business environment (Remember, this is "Production") ? Does attaching to process, and attaching to a specific browser only debug for that particular browser? (there are so many features in Visual Studio it's hard to know exactly what is possible some of the time). Are there any other techniques I could use next time around to develop in a full production environment when creating a test server in the short run is impractical?

Also how does one cut through the bs- code and get the the heart of the matter when analyzing a project which is literally hundreds of files? Perhaps there is a project file system structure that could be explained for general web projects?

If you are faced with a previous coder who took all sorts of rabbit trails in his code, ex technologies which are not ever used how do you quickly learn about those technologies in time to be effective? I perhaps focus a little bit too much on reading in books, and quite frankly they take too long.

Let's squeeze one more question in, is it possible to be a "free-lance" coder, how does that work exactly? Is it practical?

All questions are mostly associated with C#, JavaScript, ASP.NET, etc web projects.

  • 5 Contributors
  • 8 Replies
  • 516 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by jwenting

Recommended Answers

All 8 Replies

Member Avatar for DaveAmour

Did they have Source Control?

commented: It would have been nice wouldn't it have been? +3
Member Avatar for jwenting

you NEVER debug production code.
Rather you analyse the log files (those should of course exist and be designed to have useful information), then try to recreate the scenario on another machine (which should be as close to the production environment in all respects as you can get it, including data, ideally a mirror image).
THERE you can attach a debugger.

commented: Good idea, but I don't think there was actually much logging. +3
Member Avatar for pritaeas

If you are faced with a previous coder who took all sorts of rabbit trails in his code

You can use tools like ReSharper to help you identify code issues quickly. They analyze the codebase, tell you possibly issues and what code isn't even used. Next to that running your application on your machine with a profiler quickly helps you identify core (and troublesome) methods.

develop in a full production environment

If you work somewhere where they do this, you're in the wrong place.

Edited by pritaeas
commented: You are absolutely right, probably best I am not employed there anymore. lol +3
Member Avatar for daliahernandez

Add more Try/Catch Blocks to the code.
Put in more check for null variables and lists
Put in more error handling. Do a divide and conquer strategy for this situation. Determine where the errors reside and start putting in error handling, logging and general plumbing to facilitate better code.

commented: Good ideas, however do I insert breakpoints while the code is running, or would that cause undue stress on the users? +3
Member Avatar for overwraith

Calm down everybody, I know you don't debug in a production environment, but the previous programmer did not. I quite literally could not get anything done to remedy the situation because the production environment was so complex. I was trying to get everything moved to a test server just when the axe fell. So I am thinking to myself, if it is necessary to debug in production because the dick before me decided he didn't need a test server is there anything I can do about it in the short term if debugging in produciton does become necessary?

Also, they had no source control. I can't help smiling a death's head grin right now.

Edited by overwraith
Member Avatar for DaveAmour

So did you have a copy of the code at all? What kind of code was it?

If you have a copy then you can debug on a dev machine. If you don't have a copy then how will you fix any errors even if you find them?

I feel I can help here but I need more information.

Member Avatar for DaveAmour

Actually I once debugged a production server because we could not replicate the error. It only happended on production.

We had 8 servers in a farm so I just took one out the farm, installed pdb files, installed VS on the server, debugged, fixed the problem, reversed everything and put it back in the farm.

Rule are meant to be broken if there is a good enough reason!

Member Avatar for jwenting

at that moment it effectively was no longer a production machine, at least for the duration of your activities :)

But yes, there may be situations where it's impossible to get something solved without doing things outside of normal procedures. And you'd best cross your fingers that the environment you're working in is such that there are ways to quickly set up such exceptions as they always happen at times when there's no time to follow normal procedures...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.