Architecture

The AccuRev integration for Vim is design with a layered MVC-based software architecture. Like any good architecture, every major functional domain from constructing queries, formatting raw content, handling user input, and managing concurrent buffers is represented as a separate layer. Each layer has a positional relationship with other layers dictating a formal flow of data (see pic).

Does a vim script really need an “architecture” ? Absolutely. Does it need to be multiple layers deep? This one does. When building any application facing public consumption especially of open-source stature, you must have an intuitive, predictable, and repeatable structure capable of instant interrogation. Furthermore, with a programming environment that does not have a formal test suite available, resolving unexpected behavior can only be done practically with well defined layers. Vim has an event-driven, functional programming environment with multiple levels of variable/function scoping. Adding logical layers was natural and easily followed by good naming conventions and positional layout within the script. I used folding extensively to organize sections and sub-sections within the script (see pic).

Designing the architecture did not happen overnight. It took about 6 complete refactoring efforts over the course of 6 weeks (part-time) to evolve into the current state. The plugin initially started off with key mappings to functions and making direct system calls to the AccuRev CLI. Eventually I needed a separate layer for parsing output. Then I wanted a place to custom format the output (view). As I started getting sopisticated with buffer management, I needed a place to deal with creating/searching/removing buffers. Eventually, I had enough “places” that some organization was necessary — so naming conventions to the rescue. The most recent struggle that cropped up with a script growing significant in size was testing… coming from OO worlds of Java and Ruby each with a wealth of mature libraries… not having something as basic as a unit test framework was brutal. Shear pain. With global, script, buffer, and local scoped variables, tracing a problem was (and still can) take 10min – 30min depending on the nature of the problem — debugging events and multi-buffer situations just plain sucks; fixing a formatting problem is trivial because I can pinpoint the exact function, by naming convention, where to investigate. Overall, the final architecture is very mature and seems to have a place for everything (so far).