In the mobile banking development process, there are few difficulties that sometimes don't refer to code writing. The problems often occur in the process of implementing various engineering practices to work simultaneously over the project. That’s why today we’ll consider important practices for the successful development and release of the project.
Banking app audit is a complicated and multilayer process. You have to face various tasks and provide the best performance of the app. However, there are many documents and manuals with basic statements and points for the app. Let’s review the key parameters that are necessary for the high-quality performance of any banking app.
1. Code quality
To check the code quality, it’s important to stick to the following steps. Of course, the standards of the source code, best practices, and agreements are necessary. For example, SwiftLint to match Code Style in iOS development. It allows regulating various parameters of the configuration, in particular, the list of the rules to be included/excluded; subdirectories or files to be included/excluded, etc. To check these standards, you should include the statistic code and style analyzers. They should include an extended list of the rules or customized rules. It’s important to provide the integration of the reports about the results of the analyzers in CI/CD, the tendency of their changes.
If the analysis is unsuccessful, the code delivery process should be canceled. It’s recommended to add a local check before the commit via git hook.
To check the code quality we also recommend using the code quality metrics. For example, cyclomatic complexity, coupling, class hierarchy, code duplication, method cohesion. To define which metric will be appropriate for your project, you need to determine the current level for these metrics.
2. Code review
The practice of the obligatory code review for Pull/Merge Request should be carried out on the basis of a specially created checklist. The standards adopted on the project are checked, as well as the correctness of business logic implementation.
In the process of reviewing the source code, it is also necessary to check the availability and quality of unit testing. You should select the modules working with business logic and set the required level of test coverage. Then add a quality gate by matching the coverage with the target values.
3. Unit testing
The development of unit testing is necessary to release the project successfully. We have already described on our blog how to implement and configure them. Ideally, you should use the TDD approach (test-driven development).
You should implement any convenient tool that will allow you to assess the test coverage and determine which parts of the app should be included in the coverage. To do this, you can use and plugin for the IDE.
Snapshot testing is also recommended to be used. It allows saving a snapshot of the data structure and compare new shots with the previous ones. Snapshot tests are the key quality and allow spending fewer resources on regression testing. With them, you may be sure that the user interface won’t change at some point. Snapshot testing is used when testing React components.
4. Technical debt
It is recommended to write your own rule for the static analyzer that will determine the number of to-do comments in the code. The tasks of technical debt should be transferred to the general backlog of the project so that the project manager can see the number and status of tasks), tag them, assess and determine how many tasks should be considered the minimum required for a new iteration.
5. Automation
For changes implemented in the sprint, the regression testing process should be automated. It is recommended to track regression defects and create automated and manual test cases to run before each release.
For automated tests, the same code standards that are applied to the main code should be applied. They should be included in the CI / CD process. If an error occurs, the tested branch cannot be merged with the original one – this prevents code with errors from getting into the release.
In general, it is recommended to use a pyramid approach to test automation. If there is a shift in the project towards one of the types of tests, you should think about a strategy in which it will be possible to implement the remaining tests.
6. Architecture
Of course, a high-quality product should contain a single architecture style with a clear separation of the application layers, adhere to the principles of Clean Architecture. It is also recommended to finish the code migrating from legacy and get rid of this module and the linking code. This significantly affects the perception of the codebase in terms of defining the architectural approach and consistency.
It is important to involve developers in the discussion of global architectural solutions affecting mobile banking. The meetings should be permanent and contain a clear plan of what to be discussed.
Before assessing and starting the project realization the components of their interaction from the point of view of the architecture should be worked out. You can include the stages of technical solutions research that can form the basis of implementation, writing the ROS, scaling to the entire code base, and the planning stage. It consists of creating a draft diagram of the interaction of the designed component with the system. After successful integration and scaling, the draft should become a ready-to-use diagram that should be listed in the project documentation.
7. Process and role allocation
In addition to the core roles of Team Lead, Tech Lead, and developers other sprint roles should be implemented in the Core team. For example, researcher, bug fixer, backlog, communicator, document creator, security champion. At the same time, each team member should have their own clearly formulated task for the sprint. This approach allows determining more transparently the KPI of each team member.
Besides, it is recommended to calculate the bus factor. It determines the number of team members, who may leave their job and the project won't be released by other members. The lower the bus factor, the more specific knowledge these members possess. It means that they can't be replaced by other employees. To increase this indicator it is recommended to choose of the following methods.
- reduce the project complexity;
- project knowledge management: documenting the development process or using a cross-learning approach.
In this regard, it's important to create in every project a training program consisting of typical tasks. They should include fixing current bugs in the code, creating modules, and working with lists. The documentation should also include sections on working with CI, security, and source code review. This document can help new employees in the onboarding process. It will indicate which code parts are recommended to study in more detail and which tasks to fulfill first hand. You should also hold meetings with all team members, including business analysts. The technical requirements should be discussed at these meetings.
8. Security
Security is the most important aspect of the mobile banking audit. Read about it in our previous article!
Conclusion
The experience in developing mobile banking applications allowed our team become experts in this area. We constantly use and improve these engineering practices to create high-quality apps of high complexity, including enterprise projects with high requirements for application reliability and performance, a large amount of code, a long service life, and scalability. So, send us a request, and we will contact you and discuss your project!
