TL;DR: By following best industry practices like linting, unit testing, static code analysis and continuous monitoring of the software.
Modern Software Development
The software development process has changed a lot in last few years. Many of the modern tools & frameworks has built-in support to ensure that the code is clean, maintainable and readable. But any developer can make mistakes while coding a feature on mind and that's totally fine. We all have gone through that stage & we learnt through making mistakes.
In this article I am going to share some of the basic to advanced levels of checks which I learnt through working on Enterprise software applications. These are some of the best practices that you can follow or explore.
1. Code Linting
One of the basic setup that gives many advantages in long run is code linting. It leaves very minimal space to a developer to write unconventional or unreadable code. You can also ensure the rules of your coding conventions that your team might have agreed upon.
My team uses TSLint on our Angular project (that comes by default with the framework) to have standard clean coding conventions. The typical TSLint config of our project might look something like below image.
2. Unit Testing
The biggest layer in the testing pyramid which tells us to test every unit of your code. If you spend enough time writing meaningful & good quality unit testing logic, it will give you sweet fruitful results that can lead to bug free development experience.
We use Istanbul tool's code coverage thresholds with lines rule of > 85%. We also make sure that any new code addition through merge requests should also match up to the expectations. (How? Read the next parts.)
Istanbuls config file:
3. Husky hooks
Husky 🐶 is one of the best git hook tool that you can add to your project. It gives you ability to fail first i.e., fail in your development environment. You can add many kind of hooks some of them which we use are
- Checking commit messages to follow specific format set by team
- Checking lint/format issues
- Running unit test cases when pushing code to remote repository
Hooks configurations:
4. CI/CD Pipeline
On every merge request, a CI/CD pipeline triggers to check code's overall linting, formatting & running unit test cases. This ensures the integrity is maintained while adding a new component/feature. There are other pipelines scheduled like deployment on merge, weekly sonarqube checks (read more below), monthly vulnerblity test through Veeracode etc.
The Jenkins pipeline runs through groovy scripts and send out the result reports to team's mailing list.
5. Static Code analysis
The Sonarqube platform gives a continuous static code analysis quality assurance. Any technical or non technical person can go through various reports of Sonarqube like app security, code smells, tech debts, etc and get a overview of the current state of code.
It also helps to detect the missed Test coverages, Duplications, Cyclomatic complexity on the go. The weekly Sonarqube pipeline helps us to have quality gate which needs to be cleared before going to production live.
6. [Optional] In depth Security Scan
Well this might be optional for many but for the enterprise level scaled applications, it needs to be shielded with all levels of securities in place.
Veracode security inspections is a must to have for us. We have monthly pipeline which uploads zipped version of code and runs the scan in veracode platform.
We also use BlackDuck, WhiteHat for more in-depth testing of our applications that determines every layer is covered with all the best protocols that are followed.
That's all folks, thanks for reading. Do leave your comments below :)
Top comments (11)
This is a nice overview, thanks ! 👏
Two additional things we do are (1) code reviews and (2) code quality retrospectives. In the latter, the dev team can discuss findings that slipped through. It's also a great way to discuss code quality in general.
Do you run Sonarqube only once per week? Our static analyzer (Teamscale, shameless plug 😉) scans every commit and runs independently from the build, in order to deliver fast feedback.
Hey Daniel,
Thanks for appreciating.
I agree, code reviews are good way of practicing inspections on new additions. We do that with predefined list of rules to be checked by anyone from team. We also have sonarqube scan for each merge request. But code retrospective is something new which I need to read about.
Thanks again for sharing your static analyzer. :)
Thx for this! This is really what I wanted. Helped A LOT.
Can I translate in Korean this post? If you don't mind, I wanna share this awesome post in Korean. Surely, There will be a link directing to this original post.
Hey there,
That's good idea, Yes you can translate it to Korean and share the url here later. :)
Translation in Korean is here. glad you like that.
Pretty sure I read somewhere that TSLint is deprecated and they encouraged people to just use plain esLint with typescript.
Yes, it's recommended to use ESLint. But we had already setup the project using TSLint and to migrate it, we faced many issues & it was slowing down the productivity of team. So it was decided that we will keep TSLint for now and once ESLint is stable enough to match our expectations, we will move on.
Nicely written Somesh.
Thanks Bhargava. :)
You mixed different unrelated things.
Good attempt though.
Good continuation.
Yep it's mixed tools to achieve one goal.
Thanks :)