The code was complex, but what it needed to do was relatively simple. It took me longer than it probably should have, but I eventually figured out where the problem was occurring. One of my early assignments was to fix a bug in some of our shared code between Lucidchart and Lucidpress. I was REALLY nervous and did not want to break anything. We had real users using the software who would actually see the bugs. Lucid Software was my first programming job and the first time I was working on an application where bugs had a real impact. "Well, Jim is a really smart guy and he wrote this he probably did this for a good reason." Coding ApproachĬhange as little as possible by adding a special case to only change anything if a very specific code path is followed. "I don’t want to break anything else, I shouldn’t change it too much." "This was probably written for a good reason, I shouldn’t change it too much." Also occurs in seasoned veterans who are looking to put in a quick fix and move on. Most likely a young developer who is new to the code base. Phase 1: The No Risk Fix Source: xkcd Usual Suspects I’ve broken that process into three phases, each based on a different response to the question "Who the h#%$ wrote this?". The way you respond to this dilemma has to do with your development as a coder. As you scan the problematic code for the umpteenth time, you wonder how this even made it into the code base in the first place. "Who the h*&% wrote this?" you mutter under your breath. You know the problem is in there somewhere, but the code is spaghetti-an impossible-to-read, jumbled mess of logic that does who knows what and has zero comments. After hours or even days of tirelessly trying to narrow in on the cause of some small bug, you finally close in on a particular section.
0 kommentar(er)
