161–170 of 246 posts
The Ruby application server I looked at was for doing social network feeds. Posts/Likes/Comments go in, feeds come out.
I followed some common code paths for things such as posting a comment and getting a feed. I would write the stack trace down on paper as I went.
It also helped that I happen to know that this ruby server used wisper and sidekiq. This way I didn't overlook single lines of code such as 'publish: yada yada'
You first have to localize a region (function) you want to study, then you reach one of its execution with a breakpoint, or a conditional breakpoint.
Then, you inspect:
- the callstack: in which condition the function was call
- the parameters / local variables
- the subfunctions: in both tools, you can manually call any (reachable) function, try different parameter values and check the result. Pay attention through to the side effects!
This may or may not apply to you, since i work with Perl. Typically i'm in a situation where i'm supposed to improve on code written by developers with less time under their belt. As such my first steps are: 1. tidy/beautify all the code in accordance with a common standard 2. read though all of it, while making the code more clear (split up if/elsif/else christmas trees, make functions smaller, replace for loops wit…
That said, it probably does scale to the OP's 8k line code base.
Also, running the code through a formatter and refactoring it all right off the bat is a sure fire way to piss off everybody else working on the project.
In any case, my 2 cents for the OP is to not bother trying to learn the whole codebase, but instead focus on just the areas you want to enhance. For example, in the case of the new data source, find out how the existing data sources are implemented, and use them as examples for adding a new one.
Earlier quoted context omitted.
If i take longer than a week to do it, then other measures are called for, like, as you mention, subsets. However you seem to underestimate just how much functionality can be implemented in how little code with Perl.
Oh I wasn't talking about Perl specifically but about languages in general. I agree that Perl projects tend to stay small enough to be quickly understood and refactored. In fact I don't remember seeing a Perl script more than a few thousands line long. However, don't underestimate how hard it can be to understand your own Perl code when you've been away from it for 6 months :)
For anyone who cares about their craft and has a certain amount of experience with Perl this is entirely untrue. I'd rather people not repeat this tired old meme. :(
Thank you! :)
vvvv
Side rant: I just cannot believe people praising 'Unit Test'-ing. Fellow programmers, how exactly do you unit test a method / function which draws something on the canvas for example? You assert that it doesn't break the code?! I see some really talented people out there who write unit test as proof that their code works without issues, that it's awesome and it cooks eggs and bacon etc. They write such laughable test…
Your point is just for some tiny tiny scenarios of the software you are working on.
You don't need to think about 'how could I write a unit test', you need to think about how could you improve the quality of the code, and unit tests are just one of your tools available to solve this problem.
If you have access to logs from a production service / component, I find TextAnalyzer.net quite invaluable. I take an example 500 mb log dump - opened in TextAnalyzer.net and just scroll through the logs (often jumping, following code paths etc), while keeping the source code side by side. This allows me to understand the execution flow, and is typically faster than attaching a debugger. If it's a multi-threaded program, the debugger is hard to work with - and logs are your best friend. You are lucky if the log has thread information (like threadId etc)
This answer is going to be rather unortodox and might get downvoted but this is how I do it: I just skim throught all the sources, then somehow I am able to point approximate file and line of code where a specific question might be answered. This might sound "out there" but I realized during college I had the ability to recall the approximate location of specific information I needed from a textbox If I just skimmed…
I just crack open the source base with Emacs, and start writing stuff down. I use a large format (8x11 inch) notebook and start going through the abstractions file by file, filling up pages with summaries of things. I'll often copy out the major classes with a summary of their methods, and arrows to reflect class relationships. If there's a database involved, understanding what's being stored is usually pretty crucia…
Totally agree with the point of pen/paper. Something that compliments that approach is in-code annotation. Recently, I've recently been trying out https://github.com/bastibe/annotate.el which is pretty sweet. Check it out!
I just crack open the source base with Emacs, and start writing stuff down. I use a large format (8x11 inch) notebook and start going through the abstractions file by file, filling up pages with summaries of things. I'll often copy out the major classes with a summary of their methods, and arrows to reflect class relationships. If there's a database involved, understanding what's being stored is usually pretty crucia…
I've often been dropped into codebases where there is only a month to question the previous maintainer before all the business knowledge is lost as they move on to bigger and better things. So getting all the questions/queries down asap is the fastest step to get the undocumented business logic documented.
Even when you can't ask the questions I like to turn all the unknown unknowns into known unknowns. :)
I search for strings that appear in the frontend (or generated HTML source, or whatever), and then I use a search tool (git grep) to find where it comes from. And then I the same search tool again to trace my way backwards from there to where it's called, until I find the code that interests me.
And then I form a hypothesis how it works, and test it by patching the code in a small way, and observe the result.
Oh, and don't forget 'git grep'. Or ack, or ag, or your IDE's search feature.