Skip to content
Sparkbit Development Guidelines
Share
Explore

icon picker
Sparkbit Development Guidelines

This document is under development and its content will enrich with every new update.

You can jump right in by choosing:

- A for an overall look

- A to learn all the details


You can also use the menu (above) or the document outline (right side of each page) for navigation.

To learn more about the reasoning behind this document, continue reading.


In Sparkbit we have defined a set of Guidelines describing how to create software in various technical stacks. The Guidelines contain rules in areas such as:
What tools and frameworks to use?
What architectural patterns to follow?
How to structure the code?
What naming and coding conventions to follow?
How to build and deploy software? (planned)
How to test software? (planned)
How to document software? (planned)
What other software development practices to follow?

Why do we have Sparkbit Development Guidelines?

Sparkbit is a software house, working:
on many different projects,
for many different clients,
in many different technical stacks.
It might seem that there is no value in having a standardized set of rules for completely independent projects. However we have learnt that having Development Guidelines has the following benefits:
Higher quality
We’ve completed a lot of projects, we experimented with various approaches, tools, practices etc. We’ve learned a lot of lessons. Now we can build on this past experience to create high quality software.
Increased speed of development
By using already proven techniques and conventions we avoid delaying projects by endless discussions on advantages or disadvantages of each approach. Trained developers who have experience with our rules can focus on project’s domain challenges and not on looking for best solutions for problems that we’ve already solved. They can deliver working software quickly and efficiently.
Team construction flexibility
When different projects in the same technical stack follow the same rules and conventions, it is relatively easy to switch developers between projects. For example a new team member can immediately understand the code structure, knows how to set up a development environment and where to find the API documentation and so can be productive from the first day.

Is following Sparkbit Development Guidelines the best way to create high quality software?

There are many ways to create great software. Sparkbit Development Guidelines describe the way in which we create software in Sparkbit. We do not claim this is the best way but it works very well for us and we choose to follow them.

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.