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.
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.
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.
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
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.