For the record, I’m a huge fan of Rx, but I’ve been thinking a lot about lately about how to keep Rx code clean and easy to understand. The project I’m currently involved in makes extensive use of Rx in a large multi-tiered system. I’m talking 1000′s of lines of Rx.

I joined the project roughly two years into its lifespan. I am pretty up to speed on Rx and I am quite used to maintaining code. Nonetheless, I have found understanding the code to be more challenging that I would have expected. Debugging complex chains of Rx operators is not for the faint of heart!

This project was an early adopter of Rx, and the developers were learning as they went. Not only that, Rx itself has changed and grown a fair bit along the way. This might go some way to explaining the lack of readability. But I don’t think it is the whole story.

In a previous project, I created a rate limiter to throttle the amount of calls web users were making against an API. This was a refactoring to Rx of some older code. It didn’t have the excuse that Rx changed a lot while I was writing it. What I ended up with was about 10-20% the size of the original code and certainly more elegant.

But trying to explain how it worked was challenging, and at the time I wondered whether the succinctness would actually be a barrier to successful maintenance. The truth of that came from a brown-bag I ran on the code for which I had 10 slides of marble diagrams to help explain how it worked! We all know the chances of that kind of documentation being maintained are pretty much zero.

This combined with other Rx experiences has left me wondering what guidelines we should be laying down to keep Rx maintainable and how, if at all, these guidelines would differ from typical best practices for creating maintainable code.

I’ll be exploring these thoughts along with some practical code examples on and off over the next few weeks. Stay tuned!