- Requirement Gathering
- SRS
- PRD
- Software Application Basic Features
- Project Dependencies
- Cache Policy
- Programming Standards
- Database Guidelines
Applications should have
- Gamification: Better User engagement
- Shopify: Business to grow
- Internationlisation: Globalisation of the application
- Localisation: Better UX
- Chat: Easy communication
Key-value pair like a hash map with O(1) complexity.
Performance optimisation to improve UX by bettering the speed of the server response time to the client.
Cache data which is being fetching at regular intervals and frequently which changes rarely
Redis
- HTTP GET Requests
- Database fetching queries
- Tokens
- Rate Limiter
- Chat module
With reference to Naming convention standard
snake_case
- column_name (SQL)
camelCase
- Variables
- Function
- Methods
- Properties
- Packages
- nameSpaces
- collectionName (NoSQL)
- fieldName (NoSQL)
PascalCase
- ClassName
- Interface
- TableName (SQL)
UPPER_CASE
- Constants
kebab-case
- CSS Identifiers
Choose them wisely
Keeping the publishing date in mind, we need to consider the following factors
- Maintainers: More the maintainers => Deprecation prevention
- Releases: Shorter the frequency and at regular intervals shows => Stable
- Size: Smaller => Less heap memory consumption
- Issues: Less open issues with low severities => Safe and Secured
- Starts: More the better => Shows the popularity
- Major version released => Matured
- Building your own package is feasible and benefically considering the reinvention
- Check Roadmap
- Check support => regular issues fixes
- project dependencies maintenance (periodically updated, especially semver) to
- avoid breaking changes
- avoid deprecation
- receive support from maintainers
- project dependencies auditing to avoid and fix security vulnerabilities
- Design Patterns
- Correct Requirements (Specs & UAT)
- Modularity
- Multi Programming Paradigm supported programming languages
- FP
- OOP
- Implement SOLID principles for FP / OOP
- Implement SQL databases if ACID properties are required
- Implement NoSQL databases if BASE properties are required
- Source code should
- be less (unnecessary functions and variables must be avoided)
- by modular (re-usablity)
- be understandable (short, simple and meaninful naming conventions)
- be formatted
- have informative logs
- have error logs, especially where the error is suppressed and silent
- be documented using developer comments
- Development Environment
- Environment
- Strict (application should crash even in cases of warning)
- Verbose logging (nothing must be silent / suppressed instead should be logged to have it fixed)
- Development Practice: TAD -> TDD
- Global .gitignore
- .env file to maintain environment specific values
- server hot reloading on file change feature must be present
- interepreted environment (only during development-like environments) for saving time
- compiled build (only for production-like environments)
.envimplementation -> Simpler environment setuplinterimplementation -> Better coding standards- linter with strict rules (specially for dynamic typed languages and especially for loosely typed languages)
- avoiding code complexity
- improve code quality
- preventing obselete LOC / unwanted pieces of code
- implement
formatterfor better code readability and comprehension - write
testsfor better code quality - coding
- Add // @todo comment wherever needed, especially for unused or commented code blocks
- Repeative code blocks must be moved into a util function or a class method
- Repeative if-else code blocks can be looped (subjective to the code block)
- Neagtive cases must be checked at the beginning of the code to stop further execution
- Require / Importing of files should be absoulte paths relative to root directory of the codebase (depends on the programming language)
- variable names should be prefixed is, can, should, etc when evaluating and storing a boolean expression to it
- Failsafe try-catch or some error suppressing library should be written for unknown property access of an object (like JSON)
- Prevent Memory leaks by avoiding pass by reference and using pass by value while using immutables instead of mutables (more like FP) but do use it otherwise in OOP when you are sure of it
- engineering
CI-> Risk Mitigated Deployments (Tests + Code quality check)CD-> Easy deployments (Dockerize + Kubernetes)Ansible-> Dynamic Development EnvironmentProject dependencies AuditReport-> Security vulnerabilities fixesProject dependencies UpdationPeriodically -> Prevent deprecation or breaking change upgrade
- SVN
- commit hooks must be present to prevent invalid commits (poor message, lint / prettier check, etc).
- Unwanted loops
- break, return and throw in case of negative cases
- continue to skip the ones not required
- Logs
- Use debug logs for development which can be disabled in higher environments
- Avoid logging complex data structure
- Avoid logging big data structure
- Unwanted queries
- Unwanted business logic code
- Remove unused variables and save the risk GC pausing the main thread.
- Execute asynchronours operations in parallel which are not inter-dependent
- Execute independent asynchronous operations in the background (worker thread, message queue, cron, etc) with logging
- Database (SQL / NoSQL)
- Queries
- Filtering: columns / fields are indexed (composite / compound index also works if applicable)
- Selection / Projection: Unwanted columns / fields to be removed
- SQL
- Missing join query as in 2 related tables queries are executed separately.
- Table join column is indexed and hopefully an integer
- Queries
- Caching like AWS CloudFront for frontend application builds and public assets (loogs, images, etc.)
- Total Nodes in Redis Cluster = n (shards) * (replication factor) + 1 (master)
- Insert / Update -> SQL
- Background -> Related data save from RDS to NoSQL
- Fetch -> NoSQL fallback to SQL
- AmazonElastiCache -> AutoScaling Redis
- Keeping Read and Write database separate.
- Read database -> Clusters
- CDN AWS CloudFront for
- Public Assets
- Frontend Application Builds
- Logs archive to AWS S3
- Back SQL Database like AWS Aurora backup to Cloud Storage
- Issues resolution TAT
- SLO (Service Level Objectives)
- Uptime / Downtime
- Recovery Point Objective (RPO)
- The Recovery Time Objective (RTO)
- Version Retention Objective (VRO)
- Geographic Redundancy Objective (GRO)
- Latency
- Packet loss
- SLI (Service Level Indicators)
- MTBF
- MTTR
- MTTA
- MTTF