221–230 of 246 posts
When you think you understand something write a test and test your belief. If the test passes then both your knowledge and the code base are better for it. If the test fails then rewrite the test to the failure and write another test. Again you will know more and the code base will be better. Good luck.
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…
We've used image comparison tool, which produces pixel-wise diff with the expected image, exactly to verify these kind of things(we've been developing the rendering tool). In addition to this unit tests, combined with the coverage tools, allows you to find potential problems/crashes etc in your code. Different levels of testing are for different things, unit tests just one of the pieces in the equation. Your point is…
From a web developer's mind: the coll thing is that the tool can be further developed and taken to new directions. For example implement the capability to take snapshots of pages and see if they've changed in layout and notify the user of changes (pretty awesome for scrapping).
I totally agree, unit testing is such a small cog in the wheel of software quality that it is truly a shame how something like this takes all the scene.
1) Read docs for how to USE the library if they exist
2) Review example code that describe how a person would use the library to accomplish tasks.
3) In order to start diving in, find a specific example that does something interesting, then hop in from there. Read the code within the methods / functions the user calls, then the functions / methods called inside those, etc.
4) As you dig deeper you may start finding that you understand, or you'll start building up your own hypotheses like "If I change X to Y in this function then something different should happen when I call it". Try it out, and see if your hypothesis is correct.
After a few iterations of doing something like this you'll probably start getting an idea of how the code is structured and where you'd need to go in order to make the changes you'd like to make, or add the features you want to add.
Well, I'm not very good at this either but here's what I do. I usually work on modular projects where there are hundreds of files in the project. I usually skip directly to locating the file where I've to make amends (using a lot of grep. grep for function and object definitions, grep for usage patterns, grep for checking how to implement something). Thus, I learn about the codebase as I go along. Sure, this is not t…
If this is your modus operandi your life will be much improved with Ack. It's specifically designed for searching codebases.
Programming with unit tests really helps. And it points out where certain parts are too entangled and bound to implementation.
> What tools and techniques do you use for exploring and learning an unknown code base?
When you think you understand something write a test and test your belief. If the test passes then both your knowledge and the code base are better for it. If the test fails then rewrite the test to the failure and write another test. Again you will know more and the code base will be better. Good luck.
What if you wrote a test that passes at the time of writing because of how something is implemented at that time but its not actually an invariant?
I wrote some simple bash scripts around git which allow me to very quickly identify the most frequently-edited files, the most recently-edited files, the largest files, etc. https://github.com/gilesbowkett/rewind it's for assessing a project on day one, when you join, especially for "rescue mission" consulting. it's most useful for large projects. the idea is, you need to know as much as possible right away. so you r…
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…
Adobes WebKit repository with layout tests: https://github.com/adobe/webkit/tree/master/LayoutTests
Example URLs from that repository:
https://github.com/adobe/webkit/blob/master/LayoutTests/css3...
https://github.com/adobe/webkit/blob/master/LayoutTests/css3...
https://github.com/adobe/webkit/blob/master/LayoutTests/css3...
Other browsers will have similar strategies.
I think this is essential for something with the complexity of a browser engine.
