In VS Code you can also right click a symbol and click “browse references” which gives you a list of callers, etc. Not quite what you’re looking for, but you can hit
Ctrl+t and tag on it from there and walk the rabbit hole yourself. Not quite as good, but still a feature I use quite often myself.
Thoughts on the Current Codebase
Now on to the “state of the code”, as told according to the opinion of one highly-fallible engineer. Please be gentle I’m a little late to the party, but incoming brain dump.
The term “beta” is used and abused these days in all the wrong ways. When David says “beta”, I would say its smart to interpret it in the most literal sense possible. I take that to be that the major architectural pieces and algorithms are in place. It’s functional, but everything else is up for grabs still.
I do not expect that “beta” implies “nearly finished,”. Interpret it as closer to “minimum number of big features implemented” (not the same as “feature-complete”). I get the impression this is probably the “end of the beginning” or perhaps the “beginning of the middle”.
I’m going to comment on the current state of the code base through the lens of contribution accessibility. I think this reflects the level of maturity of a codebase well, since more mature code can devote more resources, all else equal, to finetuning, tweaking, and supporting community development efforts. I’ll break it up by crate for the crates I know about to some extent.
sn_api - Accessibility : 8/10
- In my opinion the best entry-point into the codebase. Very well-documented (as it should be, since its front-facing for users) and architecture is simple/easy to figure out at a glance. As a result, it’s simple to find ways to improve the code or fix bugs.
sn_node : Accessibility: 3.5/10
- Not for the faint-of-heart. You really need to get your hands dirty to figure out what’s going on. It generally feels like a construction zone still, and there are lots of
TODO comments to be seen.
- You better be up-to-date on the current state of the net algorithms to some degree before looking at this. The architecture is not tightly coupled, which is nice and flexible, but also makes it tedious at times to figure out call-chains unless you have an idea of where it might be going next already from prior knowledge.
- This is especially if you aren’t familiar with this kind of heavy indirection in code. I imagine it’s even harder to grok if you’re used to traditional object-oriented programming in the context of something like web-dev.
- Related to the above, the architecture isn’t the most straightforward, and it’s been changing a lot until recently (4500 line patch to remove some message wrapping logic was the last big one, which occurred only last week). According to David, this should calm down now, but historically it’s proved to be a challenge. That said, I still see lots of room for improvement in architecture, so I’m not sure how much that’ll hold true beyond the next test net.
- Quick, rather technical example: mutably borrowing the whole
Node for every node operation, regardless of whether it needs the whole thing or not, defeats the performance gains entirely of our
async/await calls. This can’t be fixed trivially with an
Arc<Mutex> because one message generates another message so you need to borrow the whole thing “just in case”.
- Documentation is spotty, as mentioned, which doesn’t ease things. That’s the least of it though, because of the general effort required to contribute to this (e.g. understanding network algorithms & architecture), you can probably follow a few call chains to piece together any missing docs.
sn_routing & qp2p: Accessibility: 6/10
- These are actually rather straightforward, but I’ve little experience contributing to them actively. The code looks clean enough and isn’t too hard to figure out. It suffers heaviest I think from the “how to contribute” problem outlined below.
- I don’t know about
ffi or some of the other stuff. I have a passing knowledge of
BRB after browsing a bit, but not enough to comment on thoroughly either, but it seems to be among the most experimental code still.
Biggest Barrier to Contributors: HOW can I help?
Even if you’re comfortable enough to understand existing code and work with it, knowing HOW to contribute is still difficult. I find it’s difficult to know at a glance, without a lot of effort, to figure out what what needs to be done, which tasks are currently being worked on already, and which are still up for grabs for somebody to step in and help.
Example: There’s no great place to figure out what bugs need squashing, what areas of code need more tests, etc. This speaks to the fact that devs still seem concerned heavily with making things work more so than making sure there are breadcrumbs to follow.
The GitHub issues don’t help a ton, and are a hit or miss. Sometimes stale issues stick around for a while. Sometimes the issues are sort of non-specific and just general reminders. Sometimes code efforts aren’t tracked by an issue at all until its time to PR, which makes it easy to accidentally waste time on something that will be superseded soon by a patch (which is why it’s a good idea to run things first on the dev forum right now I think).
The easiest contributions are new features (e.g. a new cli command or something), since there’s fewer conflicts with existing code, and they exist outside of ongoing efforts. That said, new features are not always the most immediately useful, and make it hard for the community to help meaningfully in terms of things that will be relevant in the semi-near-future (e.g. tests, bugfixes, and refactors). Any bugfix/refactor/etc. I’ve personally submitted is the result of stumbling across it in the code base while doing something else entirely. It’s not for a lack of things to do, but a lack of the bandwidth needed to painstakingly document and triage them.
The code base is settling down, but it’s still not easy to contribute. Things have historically moved fast, and, while it’s getting slower, this indicates to me that I can hardly call the code “mature” either. There are a lot of unimplemented things still, even if the last of the bare-minimum functional pieces is almost in (referring to rewards).
I hope this doesn’t come off the wrong way. I’m just reflecting a bit on some things I’ve experienced or seen others experience along the way, and what that might indicate about the current state of “done-ness”.