Standards Checklists and Best Practices - amitbhilagude/userfullinks GitHub Wiki

Architectural Principles: Set some team-level architectural principal while designing any solution e.g. as below.
1. Design for Simplicity
  1. Simple solutions avoid lot much complexity for better maintainable solutions e.g. Polling mechanism over Signal R
2. Build for Flexibility
  1. Build solutions that can extend easily with future requirements
3. Loose Coupling
  1. Decouple architecture which will help to reduce dependency.
4. Focus on Core IP over generic functionality
  1. Focus on building business uses cases instead of building a generic framework e.g. Logging as it will be readily available as open source.
5. Prefer PaaS based Solution
6. Azure First
7. Design for multi-tenancy
  1. Will help to isolate workload and solve the noisy neighbor problem
8. "Just Enough" Architecture
  1. Build architecture that will give clear boundaries and guidance to the team and start building the solutions. 9 Documentation is Key
  2. Document all solutions, design decisions, and reasons for change for future reference.
Code Quality Analysis
1. Sonarqube will be used for Code Quality Analysis
2. Sonarqube support many languages for code quality analysis. You can enable it based on the requirement e.g. C#, Javascript
3. Quality Profile. You can define set of standard rule for each Quality profile.
  1. Bug: Code that passes compilation but may cause issues at runtime
    1. E.g. "=+" should not be used instead of "+=". Sonarqube will raise an issue when there is space between two operators
  2. CodeSmell: Code that may cause maintainability issues, go against coding standards or may be difficult to understand
    1. E.g. "async" and "await" should not be used as identifiers to avoid any confusion.
  3. Vulnerability: Code that may cause security Vulnerability.
    1. "HttpOnly" should be set on cookies. The HttpOnly cookie attribute tells the browser to prevent client-side scripts from reading cookies with the attribute, and its use can go a long way to defending against Cross-Site Scripting (XSS) attacks. Thus, as a precaution, the attribute should be set by default on all cookies set server-side, such as session-id cookies.
  4. Security hotspot: Code that is sensitive from a security perspective as it may introduce vulnerabilities depending on the context and usage.
    1. E.g. Username and password hard-coded in a code
4. Azure DevOps Integration
  1. Service Connection
  2. Use of DevOps Tasks in Build Pipeline
    1. Prepare Analysis for Sonarqube: Create Project if not exist
    2. Run Code Analysis
    3. Publish Quality gates
5. Code Analysis during Development
6. Sonarlint
Code Review Guidelines
1. Pull Request Process
  1. Create a Feature branch from the master/main branch which is a short-lived branch.
  2. Push all changes in the feature branch and create a pull request.
  3. Pull Requests should review by at least 2 individuals and pass all quality gates.
  4. Comments should be resolved and let the reviewer close them and approve the pull request.
2. Design guidelines
  1. Design Guidelines should follow Microsoft Framework Design Guidelines
3. Quality Standards
  1. Should pass all quality gates
4. Assemblies
  1. Create a different assembly only if it is getting deployed separately.
5. Namespace
  1. Namespace should follow CompanayName.ServiceName.FeatureName
  2. Do not use generic names for namespaces such as “General”, “Helpers” or “Core”. This implies poorly-organised code with ill-defined responsibilities.
  3. Avoid namespaces that only have one or two classes.
6. Classes
  1. Avoid big classes as well as small tiny classes e.g. Try split into multiple classed if lines of code > 500
  2. Avoid Utility class
  3. Dispose unmanaged classes well. e.g. If you have used IDisposable then dispose it with dispose or using
  4. Method should not be more than 30 lines
  5. Avoid using Regions else create separate class or method required.
7. Exception Handelling
  1. Use exception handling base practices as per https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/ms229005(v=vs.100)
8. Unit testing
  1. mandate Unit testing code
C# Coding Standards
1. Assembly
  1. Code should split into multiple Assemblies only when these assemblies need to be deployed separately.
2. Namespaces
  1. Namespace should follow ProductName\CountryName.ServiceName.FeatureName
  2. Don't use Generic namespace like Helpers, Generata, Data, or Utilities
  3. Don't create a namespace that contains only a few classes.
3. Use the following standards published by Microsoft
4. Common tools used for .Net code: ReSharper, StyleCop, Sonarqube
Development Principles
1. Follows SOLID Principal
2. OOPS principal Encapsulations, inheritance, Polymorphism, and Abstractions
3. Unit Test case automation
4. Defensive Programming
  1. Never trust user input
  2. Do not assume that external services will be available – even between different calls
  3. Do not assume the consistent performance of external services
  4. Consider how to achieve a graceful shutdown of services in unexpected circumstances
  5. Always verify key functionality with test coverage
Secure Coding Development
1. Every pull request goes to the Blackduck, CheckMarx, and Sonarqube scans.
2. Corporate security mandatory training is created based on your roles from developer to Architect, which needs to be completed yearly.
3. Every team has a Security champion who allocates his main task to validate the backlog and add input from a security perspective.
4. Developer needs to follow are standards of OWASP attack guidelines
5. Mandatory pen testing needs to be performed for every product.
6. Infrastructure-level security will be considered for every layer.
ADO Agile Process
1. State: New, Approved, Committed, Done
2. Definition of Ready(DoR)
  1. User Story is clear
  2. User Story is testable
  3. Is the User Story is feasible
  4. User Story Acceptance Criteria defined
  5. User Story dependencies identified
  6. User Story sized by Development Team
  7. User Story is mapped with Well architected pillars
  8. A person who will accept the User Story is identified
  9. Team has a good idea of what it will mean to Demo the User Story
3. Definition of Done(DoD)
  1. Code committed
  2. Quality gates passed
  3. Test cases passed
  4. Review done
  5. Passed in Dev, Test, and UAT environment
  6. Relevant document is produced
  7. Story has no pending tasks.
Testing Strategy
1. Types
  1. Unit Testing automation
    1. xUnit and Jasmin\Karma
  2. Profiling in Visual Studio with some benchmarks about response time 2. Visual Studio Diagnostic Tool
  3. Build Verification Testing 3. Build with Quality gates 4. Some API endpoint health status
  4. Smoke Testing
    1. Some basic test cases are automated using Codeseptjs UI Testing framework.
    2. API Automation is done using Postman and Newman.
  5. Functional Testing
    1. All functionality is automated using cosespetjs and Newman.
  6. Integration Test
    1. Involved in multiple systems with multiple teams. so this is done when other teams release the feature
  7. Regresssin Testing
    1. Run overnight where it tests the end-to-end flow.
  8. Performance \ Load Testing
    1. Another team performs it. Load Runner tool
  9. Security / Pen Testing
    1. OWASP ZAP (Zed Attack Proxy)
API
1. Async API. Pluralsight sample Link
  1. if there is Async then await must be there
  2. All methods should suffix with Async
  3. Best practice is the Use of IAsyncResultFilter middleware to convert Entity Model into Outer Model. Automapper is used in this middleware to map this property.
2. Dependency Injection
  1. Is the correct Lifetime of dependency Injection registered e.g. Singleton, Scoped, and Transit
  2. nested dependency injection is correct e.g. Scoped referred the Singletone then any impact?
  3. Did you organise dependency correctly? e.g. You may separate out all registration in separate file and dependency injection abstract package
  4. Any advanced DI requirement which is not possible with .net nuget package then use autofac nuget package
Domain Driven Design.
1. Did we have modelling create to highlight the relationship
  1. https://learn.microsoft.com/en-us/visualstudio/modeling/modeling-sdk-for-visual-studio-domain-specific-languages?view=vs-2022