The golden rule of coding at SwipeSense:
“Don’t write code so a machine will understand it. Write code so the next engineer will understand it.”
That next engineer may just be you in a year, so be kind to yourself and others. Follow conventions where they exist. Seek to define conventions where they don’t exist. This article seeks to define conventions that exist across repos.
Coding at SwipeSense - What to focus on in general
There are a lot of attributes that “good code” embody. But to simplify, we can focus on three things:
Maintainability - Write code that can easily be added to. This goes hand-in-hand with our golden rule. Code at SwipeSense should be malleable and extensible. We are always building on our products and improving them, so keeping code well contained and modular will aid in that goal.
Scalability - Write code that stays performant at scale. What will happen if the input to what you’re writing (perhaps a db query, api response, sensor data submission) increases by 10x? 100x? 1000x? Horizontal scalability is an important concept here, but outside the scope of this article. Your code should work for SwipeSense of today and the much larger SwipeSense of tomorrow.
Security - This should go without saying. If you were an attacker with access to the source code, could you break it? Could you see data you’re not supposed to see? As engineers we are on the front line of protecting our customers' sensitive data.
When we write code at SwipeSense, we write it to be stable, elegant, and performant into the foreseeable future. We don’t want to go back to solve performance or security issues if we can do the work up front and avoid it. If we’re doing our job right, we will spend 95% of the time engineering novel products as opposed to maintaining legacy apps.
Configuration with .env
In most of our repos, environmental configurations are handled with .env files. This method is conventional for docker, serverless, create-react-app and other major open source projects. The build process for each specific language is ultimately in charge of applying these configurations to the final build, but this defines how these files should be set up and maintained.
.env - This is master .env file. It should define every possible environment variable that is utilized in the app as well as a sane default value. In this way, the code can assume that every variable will be defined in every environment. This avoids exceptions that raised when trying to access undefined environment variables. As far as “sane default” values go, in the case of an outside api key or something that will always have a different value for each environment, a blank string might just be the most reasonable sane default.
.env.{staging|production|beta|foobar} - These files define only overrides of the default values seen in .env. They don’t need to define everything as the .env method always applies specific files on top of the default .env.