| The most critical step is to get the lib in your workflow , preferably with (build-introspect-debug) capabilities. This increases the upfront time to start, but leads to much quicker "code understanding in my opinion. TL;DR; Start with the minimum exposed surface area of the project (API), dig through these functions first.
Definitely know the initialization sequences the library needs. This is my approach concerning JS projects or for dealing with other peoples code in general. First, I make a mental model of what I want to do. !important.
Then I write the smallest wrapper needed to start fledging out points where "separation-of-concern" happens. At this point I should have an idea of what the other persons libraries expose as API.
I also should have an idea of what can be done with a unmodified library, and what would need patching. Then comes monkey-patching the lib at individual function levels with a healthy dose of TODO markers and NotImplemented Method signatures. By this point I should have a good picture of what goes on in the library apart from what gets exposed and would probably have forked a branch by now. This strategy has been useful not just for JS projects but bigger codebases of java/scala libraries like Lucene Core/Solr or Play framework, Django in the python realm and to limited success with Research code releases like Stanford Core NLP. |