On the Sprintly code side of things, we’ve been working on some larger, foundational changes to the application that will allow us to deliver more resilient code faster. I’m pretty excited about it, and I’d like to share it with you.
You may have noticed that we recently switched from hashbang urls (i.e.
#!) to more standard urls with slashes. One of the chief benefits of this was it offered a bit more consistency around navigation events and back buttons around the app. It also offers us a degree of flexibility in possibly breaking out (or adding) functionality to Sprintly that is decoupled from the main application. That is to say, while
/product/1/reports/ now lives alongside
/product/1/timelines/, this change allows for a future wherein those could live on different servers or run separate code.
We’re also working on componentizing portions of our application. This will result in a uikit powered by Facebook’s React library. One of the central goals here is that developers (those here at Sprintly and those who use Sprintly) will be able to easily create web applications that look and feel like the Sprintly product.
While the portions of the app we’re refactoring are foundational, this isn’t a ground up rewrite of our app. We’re still actively investing in the health of the code, having closed out 87 bugs fixes just this month.
As you can see, the focus here is around improving the quality of the app on both the short-term and long-term time scales. We’re doing this by breaking out layers of the application to increase maintainability, performance and speed of development. It’s my personal goal that our technically inclined users are able to build their own views into ticket data and have it look just as beautiful as Sprintly does.
Justin Abrahms, Director of Product Engineering