How does Poll Everywhere get code from the fingertips of our engineers into our customers hands at PollEverywhere.com? Through lots of steps that make sure we’re shipping a quality product.
Are you working on something big that’s green field? Are multiple people involved in a project? Never underestimate the power of taking some time up front for laying down a design. It can be as simple as sketching out an API in a gist with your pair bear, playing around with what it should look like calling the code in an rspec test, or creating a user-flow diagram to show complex interactions in detail. A little work up front can save tons of work later, especially when people start asking the question, “how is that suppose to work again?”
During our weekly planning meeting, engineers and non-engineers figure out what they’re going to build for the week.
To pair or not to pair? That depends on the team sizes and the people involved. There is no “one way” to write code at Poll Everywhere.
Where does all of that code go after it’s written? If 20 engineers are working on one project, how do they save all of their files without overwriting each other’s work?
Developers don’t just save a file and they’re done with it, they have to save it somewhere that all other engineers have access to. This central area is called a Source Code Repository. To prevent engineers from clobbering each others work they have to make a “commit” to the repository. Every commit is saved with a comment from a developer describing what they changed, a date and time, the email address of the developer, and a unique fingerprint that represents all of the source code in that project at that point in time.
At Poll Everywhere, engineers use a popular source code repository called git. We use GitHub to host our code and follow common git conventions.
Git allows engineers to give these fingerprints names. Often you’ll hear engineers talking about “branches”. Yes, like a tree, engineers can “fork” code from any given point in time, build a new feature in that branch independently of any other developer’s branch, then merge it back into the “master” branch when it’s all done.
The master branch is a very special branch in all of our projects. It represents the code that is currently in production.
Some of our work is done through pull requests. It’s used by people unfamiliar with a code repository or those who simply want a code review or are required to perform a sign-off because of a significant change.
However you choose to do it, all significant code changes should be looked at by more than one pair of eyes before it’s merged to master. Whether through pair programming, pull request, or another type of sign-off, this will produce better software.
What constitutes a “significant change”? The following types of changes constitute a significant change to our application code that should result in a mandatory code review by at least on other experienced engineer:
Any server-side application code that can create, read, update, delete, or control access to customer data from data stores such as authorization logic & policies, models, or controllers.
Example in-scope applications: