4 ms·
Am I the only one reading this thinking "as written by someone who seldom dives into foreign code bases". After a few months you'll be familiar with it? Wow,
by shadowmint 12y ago
Am I the only one reading this thinking "as written by someone who seldom dives into foreign code bases".
After a few months you'll be familiar with it?
Wow, I'm lucky to get 8 hours on a new code base before I have to ship a bugfix. Months?? O_o luxury. Sip your pina colada as you write your immediately out dated documentation. Great advice.
No, that code base was probably written by several people some of whom knew what they were doing, some of whom were just 'getting the job done' and some of whom were idiots.
Probably, the only useful suggestion in that list is code reviews. Hack a fix in, get someone who seems clued up to review and suggest a better way.
Look for logging, thats the first thing I do; you're probably not the first person to be given this code to work with, and if you're lucky the last folk(s) made some debugging tools. If not, be a pro and leave some good ones behind when you go.
...not documentation.
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]
- davvolun 12y agoWow, I'm lucky to get 8 hours on a new code base before I have to ship a bugfix. << spotted your problem. If you're constantly working in completely unfamiliar code with at best an 8 hour lead time to get a fix in, you're being setup for failure. Yeah, sometimes you have to just get a fix fast, but spending your whole life coding like that is going to burn you out. I only have my own anecdotal evidence to go by, but I'm inclined to think your experience is not the only way.
- gizmo686 12y agoMost teams I have worked with deliberatly introduced new members to their code base by: A) Making sure they can compile it, and showing them where the various locations for documentation are. B) Giving them simple bugs to work on while they get familiar with the codebase. 8 hours is more than enough time for a competent developer to fix many simple bugs. You also have situations where the nature of the problem dictates that you fairly often need to make changes in unfamiliar code-bases. For example, at my previous job I was developing an Android fork. Android has a fair amount of its own code, but also includes a large number of external projects. It was a fairly common occurrence where I would have to fix a bug in one of those projects that I have never seen before (and will likely never see again).
- shadowmint 12y agoThe point is, if you need months to become familiar with a code base, something is seriously wrong. These 'here is some generic pointless advice; got some useful advice? Leave it in the comments!' posts are social media posturing and lazy writing. Certainly not everyone dives into different code bases every day / every week; but everyone does it sooner or later; and being immediately productive is hard. This article could have been an interesting collection of tips on how to do that... but the author couldn't be bothered researching the subject.