The front-end world is changing faster than the songs on the Top 100 Singles Chart. What was a hit yesterday can be forgotten tomorrow. The same thing can happen to technologies used by front-end developers.
But forget about that for a while. Instead, be aware of the fact that there are some strict standards that help programmers from SoftwareHut in all parts of the web development process, including bootstrapping, coding, deployment and testing.
Why am I telling you this? The inability to create good architecture, high-quality code and run proper tests causes a vast amount of crashes, leaks and instabilities. Have you ever seen a client who was angry because of a product breakdown? Multiply this by ten, and you will know how much angrier developers are. Well, at least they seem to be.
To avoid all this anger, we prefer doing things right from scratch.
Coding standards
General thoughts
If a team consists of at least a few developers, we don’t just merge code to the develop branch without reviewing it. Remember to define a flow that makes use of branches, tags and pull requests – testing and code reviewing will be easy then. This process is meant to prove that the code entering the master or release branch has been thoroughly reviewed and tested.
JavaScript
Our rule number one in writing JavaScript code: always utilise the latest version of the ECMAScript specification in the source code. After that, we generate ES5-compliant code that is recognised by all current browsers. Sometimes, this even includes the latest version of Internet Explorer.
If our developers are creating applications using ECMAScript 20XX or dialects like JSX, we encourage them to use proven, well-known practices. We apply the linting and code checking rules that you can find in the Airbnb JavaScript style guide. If you want to check our guide repository, it’s available here.
Configuring ESLint with the proper ruleset applied is another good practice in every bootstrapped front-end project. Combining IDE plugins and CI/CD integrations helps us to make sure that every single line of our code conforms to standards. Also, such a code will be easy for any developer from our team to understand.
Besides, every application should expose commands that perform automatic checking of code quality. This should be done simply, i.e. by invoking a particular PM task specified inside the package.json file.
The most common approach is to integrate the ESLint ruleset from Airbnb into the project using the following package.
(S)CSS
Complex projects don’t mean complex styles. If stylesheets are complicated, you may quickly lose control over them, which would cause distractions. As a result, the code may become unmaintainable. Because of this, we just love simplicity in architectures but not only in them. The simpler the code is, the better the application is and the better it runs. To achieve this, we use methodologies like BEM (http://getbem.com/naming/).
Forget about writing CSS directly. Those days are over. Nowadays, you can choose either SCSS or SASS dialect with proper configurations for use in your project. There are no in-house linting rules for stylesheets that developers must obey, yet consistent coding conventions should be applied to every project, along with various rules, i.e. selector nesting limits.
Applied technologies, tools and frameworks
Continuous integration and continuous delivery
Forget about uploading modified scripts via FTP. Those days are long gone. Nowadays, not a single line of good software – including web applications – is being created without an adequately set up process of delivery and deployment. For us developers from SoftwareHut, it doesn’t matter whether we are building a small website or an extensive web application – we always try to maintain these three qualities:
- Separation of development and deployment processes – each of them should have different environment variables and debugging levels, but at the same time, they should maintain the same application functionality
- Project versioning, configureability and the ability to easily deploy to different environments
- Explicit dependency management and ability to easily restore the dependency tree
Unit tests
Why should you write tests if you have testers aboard? For some of you, the answer may be obvious, but what the heck – yes, we have magnificent QA engineers among us, but they aren’t meant to clean messes deliberately left behind by programmers. Developers are solely responsible for the quality of what they produce. Nevertheless, unit tests help us to notice the moment when the code has been broken accidentally.
Don’t be shocked, but we don’t require full coverage while coding user interface controllers and other UI parts. This is unnecessary, because pure front-end with markup, styling and interaction is more like art than logic. But don’t worry. When it comes to complex logic, system integrations and services, the developers at SoftwareHut must have their backs covered.
Pull requests and code review
If a team consists of at least a few developers, we don’t just merge code to the develop branch without reviewing it. Remember to clearly define a flow that makes use of branches, tags and pull requests – testing and code reviewing will be easy then. This process is meant to prove that the code entering the master or release branch has been fully reviewed and tested.
