Best Practices & Code Quality

For development process, please provide the best practices which you are currently following w.r.t below area, and how you have implemented these in automated fashion

Coding best practices

Flutter

• Packages, Libraries, source files should be in snake_case.
• import prefixes using lowercase_with_underscores.
• Use ??and ?. operators
• Use Cascades Operator
• Use debugPrint() for logging in to the console.
• Use const in widgets
• Reusability of code
• Bulk declaration
• Split widgets into sub Widgets.
• Use ListView.builder for a long list
• Use Const in Widgets
• Use async/await overusing futures callback
• Use interpolation to compose strings

GraphQL

• Use Consistent Naming in Your Schema
• Stick to Paginate Lists
• Rely on Unions and Interfaces
• Query only the data you need, where you need it
• Use fragments to encapsulate related sets of fields•Avoid excessive or illogical fragments
• Have a Plan for Error Handling
• Nested Object Queries
• Use Consistent Naming in Your Schema
• Stick to Paginate Lists
• Rely on Unions and Interfaces
• Query only the data you need, where you need it
• Use fragments to encapsulate related sets of fields
• Avoid excessive or illogical fragments
• Have a Plan for Error Handling
• Nested Object Queries

React

• example

PR Best practices

• Authors should provide the details view of code change in comments section before the review
  • What has changed
  • Why was the change necessary, possibly referencing a formal requirement
  • What are direct and indirect consequences of the change
• Logical commits. Each commit should be a single, coherent change.
• All commit messages are descriptive
• The list of commits are related and implement a complete story
• The work in the PR adds quantifiable value.
• Code complies with the defined standards
• The pull request is as small as practically possible
• Do not review for more than 60 minutes at a time
• Reviewers should provide the comment with hint of solution
• Branch should be always rebased with master
• Resolve any conflict before giving for review

Code Quality

SonarCloud

Unit testing & Coverage

React testing Lib, Husky hooks, SonarCloud

Branching and merging strategy

• The code on each branch will need to be fully tested and confidence guaranteed before it is merged to master. The automated tests must be comprehensive.
• Branches must be short lived. The core principle of Continuous Integration and Deployment is that of integrating code frequently. So, if you are doing development on long-lived feature branches then you are no longer integrating code with everybody else frequently enough. This means delayed feedback, big bang merges that can be risky and time consuming to resolve, reduced visibility and reduced confidence.
• Every PR will need to be up to date with the latest version of the master branch.
• Small, incremental changes should be implemented over big bang changes. Frequent small changes are less risky, easier to integrate with and easier to rollback.

Option List :

#	Option Title	Description	Pros & Cons
1	GitFlow	GitFlowuses two branches to record the history of the project. The master branch stores the official release history, and the develop branch serves as an integration branch for features. reference: Gitflow Workflow | Atlassian Git Tutorial	Pros: Workflow doesn’t add any new concepts or commands beyond what’s required for the Feature Branch Workflow. Does not involve focus on the CI pipeline and automated tests like Streamline. CI can create external dependencies and potentially fail e.g. due to automation code failure. Works well in terms of traditional release model, where releases are done in terms of months and weeks. Allows to scale the development since it simplifiesparallel processing and continuous development by isolating features and ensuring that you never have to freeze either your development or master branch for release preparation. Master branch remains clean and organised, updated only with code that has been thoroughly tested and refined. Aligned with Agile methodology Cons: GitFlow can slow things down when having to look at large pull requests if you are trying to iterate quickly between development phases. Larger features can spend days merging and resolving conflicts and force multiple testing cycles. The Project history is full of merge commits and makes it hard to see the actual work. Can be problematic in Continuous Integration or Continuous Delivery scenarios. s
2	Trunk-Based	In the trunk-based development model, there is a single branch with open access to it, i.e. themasterbranch. Trunk-based development is centred around the concept thatteams should remain in-sync with one another and the application should remain in a state that’s always ready for release with the latest features in place. reference:Trunk-based Development | Atlassian DevOps tech: Trunk-based development | Google Cloud	Pros: Allows you to iterate quickly and still maintain quality. DWorks well with Continuous Integration or Continuous Delivery scenarios. Can release more often, including multiple times per day. Much tighter loop for developers, business, and end-users. Master branch follows the evolution of the software project. DORA DevOps Research along with Google Cloud advocate trunk-based development Cons: Can cause issues if there isn’t good test coverage or confidence in system stability. Commits are merged directly to master branch, which involves risks. Master branch should be stable. Contention collision. If too many people are checking changes into the mainline, it will be in a constant state of churn. Potential of constantly breaking builds as developers end up tripping over each other. Problems separating mature code from immature code. Can take a long time for all tests to be run and passed prior to merge.

Recommendation:

• Trunk-based development strategy to be used
• Automated testing on pull requests will ensure code quality and confidence
• Code linting for maintaining code quality, preventing bugs early enough during commit and adhering to developmental best practices before a pull request is made.
• Naming conventions, pull requests and merging strategies as detailed below

Justification:

Trunk-based development ensures that teams can work quickly and produce high quality, comprehensively tested code. It ensures that branches are simple and the repository is kept clean and tidy.

Naming conventions will follow a set strategy, as detailed below. Having clear guidelines ensures that developers understand the meaning of branch names and commit messages, the repositories can be kept organised, and that the Systems teams can work quickly and easily to build CI/CD pipelines.