You need a Code Audit if you are facing one of these scenarios:
The Source Code Audit.
$2950
$0
ONLY THIS MONTH
Schedule Free Code Audit
Your codebase was not reviewed for more than 2 years
Enhancing the performance and responsiveness of your application
Planning to build a new feature for your app
Looking for a new development team
Fixing software bugs before selling your app
Scaling your application
Improving your application’s maintainability
Assessing an app that you want to buy
Finding security vulnerabilities in your codebase and wondering how to get them fixed
Not doing a code audit regularly sets your business up to fail.
Take a code audit to filter defects during the review of requirements for an update of your application
It also guides the technical development of your app when scaling and adding new features. As a result, you save time and money and don’t risk breaking your app.
After a JetRuby systems architect carefully audits your code, you will receive a detailed report outlining:
Our core recommendations for your code.
A list of your code’s vulnerabilities and their locations
Our estimate to upgrade your code using industry-standard best practices
Abbreviated Example of Source Code Audit
1. Used technologies
Programming Language: Ruby 2.7.0
Framework: Rails 6.1.4.1 gems (is not used directly, the Gemfile explicitly contains the Rails libraries that are needed)
Search Engine: Solr (open-source search engine from Apache)
DB: MySQL
Background Processing: DelayedJob
Scheduler: Cron
...
2. Code quality and security
2.1 Rubocop
The standard tool used for code style and code quality checks in Ruby is rubocop. The project contains a config file for rubocop, but it was added in 2016 and was not updated since 2019. We made some minimal changes to this config to make rubocop run. With these changes rubocop reports:
• 2028 issues in total
• 633 issues can not be fixed automatically
Most issues (autofixable) are related to the code styling and can safely be applied or disabled in the config. On the other hand, non-autofixable issues need investigation, for they may reveal actual code issues.
...
2.2 Rails Best Practices
Another tool we used is called Rails Best Practices. It reports 423 warnings. Some of the warnings are related to the code style and are not too important, while the others are. The rails_best_practices report file is attached to the current document.
...
2.3 Brakeman
Brakeman reports possible security vulnerabilities. At the moment of writing it reports
== Overview ==
• Controllers: 68
• Models: 45
• Templates: 237
• Errors: 3
• Security Warnings: 27
== Warning Types ==
• Cross-Site Request Forgery: 1
• Cross-Site Scripting: 8
• File Access: 2
• Mass Assignment: 7
• Redirect: 1
• SQL Injection: 8
This is a pretty good result for the project of this age. There are no critical issues reported by brakeman. Non-critical issues/warnings should be fixed though. In general, security issues should always be prioritized.
The complete brakeman report is attached to this document.
...
3. The quality review of implementation
3.1 Common code & architecture review
The entire business logic of the application is implemented in models and controllers. The project almost doesn’t use the methods to organize the code, such as ServiceObjects or other ways of encapsulating business logic and organizing code with the help of design patterns.
Cyclomatic complexity is a measure of the number of paths through a particular piece of code. High cyclomatic complexity usually leads to difficulty in testing and a significant deterioration in the comprehensibility of the codebase.
...
3.2 Data structures and data consistency
The application contains 307 tables. These tables are highly interrelated.
The application uses optimization techniques such as splitting data into tables so that it could be easily filtered with table joins and indexes.
DB Schema contains a lot of indexes that should speed up a search (Now, there is no way to test how these indexes are really used by a DB planner).
Most of the tables are using Integer type for IDs, while since Rails 5.1 the Rails Core Team is advocating to use bigint (Update on Basecamp 3 being stuck in read-only as of Nov 8, 9:22am CST). For an application like this, it’s quite easy to reach the default integer max value, which could lead to an unexpected outage or switch the whole system to a read-only state.
...
3.3 Environment
Based on the information about the environment files, all environments are highly similar by configuration. This is a good indicator and reduces the chance of errors due to different environment settings.
...
3.4 Testing
The application didn’t have automated tests at all. That leads to problems with code refactoring and adaptation to new requirements. In addition, the codebase is quite large and has a lot of interconnections, which means the team will never know how any change will affect the whole system. So to prove that everything works, the business will need to invest more money in manual testing.
Tests are often used as documentation for developers to understand how the whole system works. So if there are no tests, it’s also necessary to create and support comprehensive technical documentation.
- Hard-to-impossible refactoring
- Slower feature development
- Slower onboarding of developers
- Slower Time To Market
- More expenses on technical documentation
...
3.5 Other
README project doesn’t contain helpful links such as API documentation, other documentation, third-party services used, as well as the development process accepted by the team, such as branching or/and deployment rules.
Bundler Audit results are perfect. That means that all the gems in the project don’t have known vulnerabilities or don’t use insecure connections.
...
4. Possible issues & bottlenecks
4.1 Issues
Rubocop (ruby static code analyzer) with a default config resulted in 628 files inspected, 39155 offenses detected, 32120 offenses auto-correctable.
...
4.2 Bottlenecks
A big part of business logic on controllers with many filters will be a problem during the initial test suite setup. The team will need to understand every aspect of the specific part to write down even the most straightforward test examples.
The lack of code isolation (e.g., using PORO classes) deprives the team of the ability to write unit tests on isolated logic. It is easier to test the interaction of parts of the system with each other afterward.
...
5. Conclusion
The app follows Rails Way, which was very popular about ten years ago. But it is written without using development approaches that guarantee quality and make it easy to maintain. Such a codebase is complicated to work with and develop. Any change in requirements and new functionality is complicated to build in. And reusing existing logic is virtually impossible. Most controllers in an application depart from the REST standards for this very reason. Because of this, they become extremely large. On the implementation side, testing is just one of the first steps needed to refactor the application. Refactoring, in the long run, Refactoring will increase the development speed and Time To Market for new functionality while increasing the system's fault tolerance.
In the Gemfile of the project, there is also no bug tracker such as Sentry or its alternatives. This leads to the difficulty of catching bugs in the production environment.
Our teams should cooperate closely to start automated tests development because of the reasons above; this will increase the time required for high quality and complete coverage of the application by automated test scenarios.
...
