3 ms·

> I've never seen anyone dig through VCS history to gain a better understanding of code. One of my favourite interview questions: A bug is found where giv

> I've never seen anyone dig through VCS history to gain a better understanding of code. One of my favourite interview questions: A bug is found where given a specific series of user interactions an error is raised. You search for this error in code and you find that the error is raised in a very old module which was written in a different style from the main codebase by a developer who has long since left the company. From a quick look around you see that this code is very complex, and probably quite important. It's obvious that it will take quite a bit of time to understand what's going on simply by just reading the code in the module where this error is raised. Your job is to fix the bug. How do you approach this problem? At my company digging through VCS (and our ticketing system) in order to gain a better understanding of code is a very common. Edit: I think if you're leaving commented out code for history's sake, you're Doing It Wrong. I disagree with the GP's idealism as much as you do, however. My beef with it is that if you're checking in commented code, you're obviously not reviewing your own diffs. It means you're likely to commit minor changes which were made for debugging purposes. // comment this, just to get this stupid module out of my way. //ensureNobodyDies();

ssmoot 12y ago
Ticketing system sure. If you have the full history you'd get the original requirements hopefully, and revisions or issues along the way. VCS. Maybe it's just a Web vs Other development thing. The history of an Action in Rails is going to be someone using mass-assignment unsafely. Or a dozen stylistic tweaks. Or implementing a pattern. Or removing it. It's about the worst possible way I can imagine to attempt to understand requirements. What I do find helpful is "git blame", and just talking to the person who implemented it. And if they aren't available, then hopefully someone who was there at the time, and involved with the feature, is. At least I have a time-frame. As a last resort, if no one has any clue what's going on? Scrolling through VCS diffs would be an act of desperation perhaps. But I'd much rather look for tests. Automated or a Manual Test Plan. A Specification. Or just use common sense. At the end of the day it's most likely that I'm tasked with this issue because the original implementation was a scheduling compromise, or the original developer just couldn't think of how to make it simple, so they made it complex. Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) Then it's absolutely the only sane way to implement it and you just need to try harder to understand. Duh.
- benjamincburns 12y ago
  > Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) I appreciate your humility, and I largely agree with your approach. You'd probably do quite well in my interview. With respect to actual complexity rarely being justified, I'm presently a team lead for a system which involves fairly precise modeling of some very piecewise real world processes under very tight performance constraints. There are so many things we just can't generalize, either because there's no clean abstraction, or because abstraction comes with too much inefficiency. We try to keep our processes from smelling too much like old stale spaghetti, but unfortunately some things are just simply complex, and sometimes in the face of such complexity the most elegant and/or performant solution can make purists cringe.

ssmoot 12y ago

Ticketing system sure. If you have the full history you'd get the original requirements hopefully, and revisions or issues along the way. VCS. Maybe it's just a Web vs Other development thing. The history of an Action in Rails is going to be someone using mass-assignment unsafely. Or a dozen stylistic tweaks. Or implementing a pattern. Or removing it. It's about the worst possible way I can imagine to attempt to understand requirements. What I do find helpful is "git blame", and just talking to the person who implemented it. And if they aren't available, then hopefully someone who was there at the time, and involved with the feature, is. At least I have a time-frame. As a last resort, if no one has any clue what's going on? Scrolling through VCS diffs would be an act of desperation perhaps. But I'd much rather look for tests. Automated or a Manual Test Plan. A Specification. Or just use common sense. At the end of the day it's most likely that I'm tasked with this issue because the original implementation was a scheduling compromise, or the original developer just couldn't think of how to make it simple, so they made it complex. Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) Then it's absolutely the only sane way to implement it and you just need to try harder to understand. Duh.

benjamincburns 12y ago
> Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) I appreciate your humility, and I largely agree with your approach. You'd probably do quite well in my interview. With respect to actual complexity rarely being justified, I'm presently a team lead for a system which involves fairly precise modeling of some very piecewise real world processes under very tight performance constraints. There are so many things we just can't generalize, either because there's no clean abstraction, or because abstraction comes with too much inefficiency. We try to keep our processes from smelling too much like old stale spaghetti, but unfortunately some things are just simply complex, and sometimes in the face of such complexity the most elegant and/or performant solution can make purists cringe.