Clean Code Principles And Patterns Python Edition (Completed)

Clean Code Principles And Patterns
1: About the Author
2: Introduction
3: Architectural Principles and Patterns
   3.1: Software Hierarchy
   3.2: Single Responsibility Principle
   3.3: Uniform Naming Principle
   3.4: Encapsulation Principle
   3.5: Service Aggregation Principle
   3.6: High Cohesion, Low Coupling Principle
   3.7: Library Composition Principle
   3.8: Avoid Duplication Principle
   3.9: Externalized Service Configuration Principle
      3.9.1: Environment Variables
      3.9.2: Kubernetes ConfigMaps
      3.9.3: Kubernetes Secrets
   3.10: Service Substitution Principle
   3.11: Inter-Service Communication Methods
      3.11.1: Synchronous Communication Method
      3.11.2: Asynchronous Communication Method
      3.11.3: Shared Data Communication Method
   3.12: Strategic Domain-Driven Design Principle
      3.12.1: Design Example 1: Mobile Telecom Network Analytics Software System
      3.12.2: Design Example 2: Banking Software System
   3.13: Autopilot Microservices Principle
      3.13.1: Stateless Microservices Principle
      3.13.2: Resilient Microservices Principle
      3.13.3: Horizontally Autoscaling Microservices Principle
      3.13.4: Highly-Available Microservices Principle
      3.13.5: Observable Microservices Principle
   3.14: Software Versioning Principles
      3.14.1: Use Semantic Versioning Principle
      3.14.2: Avoid Using 0.x Versions Principle
      3.14.3: Don’t Increase Major Version Principle
      3.14.4: Implement Security Patches and Bug Corrections to All Major Versions Principle
      3.14.5: Avoid Using Non-LTS Versions in Production Principle
   3.15: Git Version Control Principle
      3.15.1: Feature Branch
      3.15.2: Feature Toggle
   3.16: Architectural Patterns
      3.16.1: Event Sourcing Pattern
      3.16.2: Command Query Responsibility Segregation (CQRS) Pattern
      3.16.3: Distributed Transaction Patterns
         3.16.3.1: Saga Orchestration Pattern
         3.16.3.2: Saga Choreography Pattern
   3.17: Preferred Technology Stacks Principle
4: Object-Oriented Design Principles
   4.1: Object-Oriented Programming Concepts
      4.1.1: Classes/Objects
      4.1.2: Encapsulation
      4.1.3: Abstraction
      4.1.4: Inheritance
      4.1.5: Interface
         4.1.5.1: Interface evolution
      4.1.6: Polymorphism
   4.2: Programming Paradigms
      4.2.1: Imperative Programming
      4.2.2: Functional Programming
   4.3: Multi-Paradigm Programming Principle
   4.4: Why is Object-Oriented Programming Hard?
   4.5: SOLID Principles
      4.5.1: Single Responsibility Principle
      4.5.2: Open-Closed Principle
      4.5.3: Liskov’s Substitution Principle
      4.5.4: Interface Segregation and Multiple Inheritance Principle
      4.5.5: Program Against Interfaces Principle (Generalized Dependency Inversion Principle)
   4.6: Clean Microservice Design Principle
      4.6.1: Real-Life Example
   4.7: Vertical Slice Design Principle
   4.8: Class Organization Principle
   4.9: Uniform Naming Principle
      4.9.1: Naming Interfaces and Classes
      4.9.2: Naming Functions
         4.9.2.1: Preposition in Function Name
         4.9.2.2: Naming Method Pairs
         4.9.2.3: Naming Boolean Functions (Predicates)
         4.9.2.4: Naming Builder Methods
         4.9.2.5: Naming Methods with Implicit Verbs
         4.9.2.6: Naming Lifecycle Methods
         4.9.2.7: Naming Function Parameters
   4.10: Encapsulation Principle
      4.10.1: Immutable Objects
      4.10.2: Don’t Leak Modifiable Internal State Outside an Object Principle
      4.10.3: Don’t Assign From a Method Parameter to a Modifiable Attribute
   4.11: Prefer Composition Over Inheritance Principle
   4.12: Tactical Domain-Driven Design Principle
      4.12.1: Tactical DDD Concepts
         4.12.1.1: Entities
         4.12.1.2: Value Objects
         4.12.1.3: Aggregates
         4.12.1.4: Aggregate Roots
      4.12.2: Actors
         4.12.2.1: Factories
         4.12.2.2: Repositories
         4.12.2.3: Services
         4.12.2.4: Events
         4.12.2.5: Event Storming
      4.12.3: Domain-Driven Design Example: Data Exporter Microservice
      4.12.4: Domain-Driven Design Example 2: Anomaly Detection Microservice
   4.13: Design Patterns
      4.13.1: Design Patterns for Creating Objects
         4.13.1.1: Factory Pattern
         4.13.1.2: Abstract Factory Pattern
         4.13.1.3: Static Factory Method Pattern
         4.13.1.4: Builder Pattern
         4.13.1.5: Singleton Pattern
         4.13.1.6: Prototype Pattern
         4.13.1.7: Object Pool Pattern
      4.13.2: Structural Design Patterns
         4.13.2.1: Composite Pattern
         4.13.2.2: Facade Pattern
         4.13.2.3: Bridge Pattern
         4.13.2.4: Strategy Pattern
         4.13.2.5: Adapter Pattern
         4.13.2.6: Proxy Pattern
         4.13.2.7: Decorator Pattern
         4.13.2.8: Flyweight Pattern
      4.13.3: Behavioral Design Patterns
         4.13.3.1: Chain of Responsibility Pattern
         4.13.3.2: Observer Pattern
         4.13.3.3: Command/Action Pattern
         4.13.3.4: Iterator Pattern
         4.13.3.5: State Pattern
         4.13.3.6: Mediator Pattern
         4.13.3.7: Template Method Pattern
         4.13.3.8: Memento Pattern
         4.13.3.9: Visitor Pattern
         4.13.3.10: Null Object Pattern
   4.14: Don’t Ask, Tell Principle
   4.15: Law of Demeter
   4.16: Avoid Primitive Obsession Principle
   4.17: Dependency Injection (DI) Principle
   4.18: Avoid Code Duplication Principle
   4.19: Inheritance in Cascading Style Sheets (CSS)
5: Coding Principles
   5.1: Uniform Variable Naming Principle
      5.1.1: Naming Integer Variables
      5.1.2: Naming Floating-Point Number Variables
      5.1.3: Naming Boolean Variables
      5.1.4: Naming String Variables
      5.1.5: Naming Enum Variables
      5.1.6: Naming Collection (List and Set) Variables
      5.1.7: Naming Dictionary Variables
      5.1.8: Naming Pair and Tuple Variables
      5.1.9: Naming Object Variables
      5.1.10: Naming Optional Variables
      5.1.11: Naming Function Variables (Callbacks)
      5.1.12: Naming Class Attributes
      5.1.13: General Naming Rules
         5.1.13.1: Use Short, Common Names
         5.1.13.2: Pick One Term And Use It Consistently
         5.1.13.3: Avoid Obscure Abbreviations
         5.1.13.4: Avoid Too Short Or Meaningless Names
   5.2: Uniform Source Code Repository Structure Principle
   5.3: Domain-Based Source Code Structure Principle
   5.4: Avoid Comments Principle
      5.4.1: Name Things Properly
      5.4.2: Single Return Of Named Value At The End Of Function
      5.4.3: Return Type Aliasing
      5.4.4: Extract Constant for Boolean Expression
      5.4.5: Extract Named Constant or Enumerated Type
      5.4.6: Extract Function
      5.4.7: Avoid Comments for Regular Expression
      5.4.8: Avoiding Comments in Bash Shell Scripts
   5.5: Function Single Return Principle
   5.6: Use Type Annotations for Production Code Principle
      5.6.1: Function Arguments Might Be Given in Wrong Order
      5.6.2: Function Argument Might Be Given with Wrong Type
      5.6.3: Function Return Value Type Might Be Misunderstood
      5.6.4: Refactoring Code Is More Difficult
      5.6.5: Forced to Write Public API Comments
      5.6.6: Type Errors Are Not Found in Testing
   5.7: Refactoring Principle
      5.7.1: Rename
      5.7.2: Extract Method
      5.7.3: Extract Class
      5.7.4: Extract Constant
      5.7.5: Replace Conditionals with Polymorphism
      5.7.6: Introduce Parameter Object
      5.7.7: Invert If-Statement
      5.7.8: Creating Rich Object
   5.8: Static Code Analysis Principle
      5.8.1: Common Static Code Analysis Issues
   5.9: Error/Exception Handling Principle
      5.9.1: Returning Errors
         5.9.1.1: Returning Failure Indicator
         5.9.1.2: Returning an Optional Value
         5.9.1.3: Returning an Error Object
         5.9.1.4: Adapt to Wanted Error Handling Mechanism
         5.9.1.5: Functional Exception Handling
   5.10: Avoid Off-By-One Errors Principle
   5.11: Be Critical When Googling or Using Generative AI Principle
   5.12: Make One Change At A Time Principle
   5.13: Use Appropriate Data Structure Principle
      5.13.1: List
      5.13.2: Dictionary
      5.13.3: Tuple
      5.13.4: Set
      5.13.5: String
      5.13.6: Bytearray
      5.13.7: Counter
      5.13.8: OrderedDict
      5.13.9: Deque (Double Ended Queue)
      5.13.10: Customized Built-In Collections
      5.13.11: Stack (LIFO Queue)
      5.13.12: Queue (FIFO Queue)
      5.13.13: Priority Queue
      5.13.14: Synchronized Queues (LIFO/FIFO)
   5.14: Optimization Principle
      5.14.1: Optimization Patterns
         5.14.1.1: Optimize Busy Loops Only Pattern
         5.14.1.2: Remove Unnecessary Functionality Pattern
         5.14.1.3: Object Pool Pattern
         5.14.1.4: Use Optimal Data Structures Pattern
         5.14.1.5: Algorithm Complexity Reduction Pattern
         5.14.1.6: Cache Function Results Pattern
         5.14.1.7: Buffer File I/O Pattern
         5.14.1.8: Share Identical Objects a.k.a Flyweight Pattern
6: Testing Principles
   6.1: Functional Testing Principles
      6.1.1: Unit Testing Principle
         6.1.1.1: Test-Driven Development (TDD)
         6.1.1.2: Unit Specification-Driven Development (USDD)
         6.1.1.3: Naming Conventions
         6.1.1.4: Mocking
         6.1.1.5: Web UI Component Unit Testing
      6.1.2: Software Component Integration Testing Principle
         6.1.2.1: Web UI Integration Testing
         6.1.2.2: Setting Up Integration Testing Environment
      6.1.3: Complete Example with BDD, ATDD, DDD, OOD and TDD
      6.1.4: End-to-End (E2E) Testing Principle
   6.2: Non-Functional Testing Principle
      6.2.1: Performance Testing
      6.2.2: Data Volume Testing
      6.2.3: Stability Testing
      6.2.4: Reliability Testing
      6.2.5: Stress and Scalability Testing
      6.2.6: Security Testing
      6.2.7: Other Non-Functional Testing
         6.2.7.1: Visual Testing
7: Security Principles
   7.1: Shift Security to Left Principle
   7.2: Have a Product Security Lead Principle
   7.3: Use Threat Modelling Process Principle
      7.3.1: Decompose Application
      7.3.2: Determine and Rank Threats
         7.3.2.1: STRIDE Threat Examples
      7.3.3: Determine Countermeasures and Mitigation
      7.3.4: Threat Modeling Example using STRIDE
         7.3.4.1: Decompose Application
         7.3.4.2: Determine and Rank Threats
      7.3.5: Determine Countermeasures and Mitigation
      7.3.6: Threat Modeling Example Using ASF
   7.4: Security Features
      7.4.1: Authentication and Authorization
         7.4.1.1: OpenID Connect Authentication and Authorization in Frontend
         7.4.1.2: OAuth2 Authorization in Backend
      7.4.2: Password Policy
      7.4.3: Cryptography
         7.4.3.1: Encryption Key Lifetime and Rotation
      7.4.4: Denial-of-service (DoS) Prevention
      7.4.5: Database Security
      7.4.6: SQL Injection Prevention
      7.4.7: OS Command Injection Prevention
      7.4.8: Security Configuration
      7.4.9: Automatic Vulnerability Scanning
      7.4.10: Integrity
      7.4.11: Error Handling
      7.4.12: Logging
      7.4.13: Audit Logging
      7.4.14: Input Validation
         7.4.14.1: Validating Numbers
         7.4.14.2: Validating Strings
         7.4.14.3: Validating Timestamps
         7.4.14.4: Validating Arrays
         7.4.14.5: Validating Objects
         7.4.14.6: Validating Files Uploaded to Server
8: API Design Principles
   8.1: Frontend Facing API Design Principles
      8.1.1: JSON-based RPC API Design Principle
      8.1.2: REST API Design Principle
         8.1.2.1: Creating a Resource
         8.1.2.2: Reading Resources
         8.1.2.3: Updating Resources
         8.1.2.4: Deleting Resources
         8.1.2.5: Executing Non-CRUD Actions on Resources
         8.1.2.6: Resource Composition
         8.1.2.7: HTTP Status Codes
         8.1.2.8: HATEOAS and HAL
         8.1.2.9: API Versioning
         8.1.2.10: Documentation
         8.1.2.11: Implementation Example
      8.1.3: GraphQL API Design
      8.1.4: Subscription-Based API Design
         8.1.4.1: Server-Sent Events (SSE)
         8.1.4.2: GraphQL Subscriptions
      8.1.5: WebSocket Example
   8.2: Inter-Microservice API Design Principles
      8.2.1: Synchronous API Design Principle
         8.2.1.1: gRPC-Based API Design Example
      8.2.2: Asynchronous API Design Principle
         8.2.2.1: Request-Only Asynchronous API Design
         8.2.2.2: Request-Response Asynchronous API Design
9: Databases And Database Principles
   9.1: Relational Databases
      9.1.1: Structure of Relational Database
      9.1.2: Use Object Relational Mapper (ORM) Principle
      9.1.3: Entity/Table Relationships
         9.1.3.1: One-To-One/Many Relationships
         9.1.3.2: Many-To-Many Relationships
         9.1.3.3: Sales Item Repository Example
      9.1.4: Use Parameterized SQL Statements Principle
      9.1.5: Normalization Rules
         9.1.5.1: First Normal Form (1NF)
         9.1.5.2: Second Normal Form (2NF)
         9.1.5.3: Third Normal Form (3NF)
   9.2: Document Databases
   9.3: Key-Value Database Principle
   9.4: Wide-Column Databases
   9.5: Search Engines
10: Concurrent Programming Principles
   10.1: Threading Principle
      10.1.1: Parallel Executors
   10.2: Thread Safety Principle
      10.2.1: Use Locking for Mutual Exclusion (Mutex)
      10.2.2: Atomic Variables
      10.2.3: Concurrent Collections
   10.3: Publish/Subscribe Shared State Change Principle
11: Teamwork Principles
   11.1: Use Agile Framework Principle
   11.2: Define the Done Principle
   11.3: You Write Code for Other People Principle
   11.4: Avoid Technical Debt Principle
   11.5: Software Component Documentation Principle
   11.6: Code Review Principle
      11.6.1: Focus on Object-Oriented Design
      11.6.2: Focus on Function Specification by Unit Tests
      11.6.3: Focus on Proper and Uniform Naming
      11.6.4: Don’t Focus on Premature Optimization
      11.6.5: Detect Possible Malicious Code
   11.7: Uniform Code Formatting Principle
   11.8: Highly Concurrent Development Principle
      11.8.1: Dedicated Microservices and Microlibraries
      11.8.2: Dedicated Domains
      11.8.3: Follow Open-Closed Principle
   11.9: Pair Programming Principle
   11.10: Well-Defined Development Team Roles Principle
      11.10.1: Product Owner
      11.10.2: Scrum Master
      11.10.3: Software Developer
      11.10.4: Test Automation Developer
      11.10.5: DevOps Engineer
      11.10.6: UI Designer
   11.11: Competence Transfer Principle
12: DevSecOps
   12.1: SecOps Lifecycle
   12.2: DevOps Lifecycle
      12.2.1: Plan
      12.2.2: Code
      12.2.3: Build and Test
      12.2.4: Release
         12.2.4.1: Example Dockerfile
         12.2.4.2: Example Kubernetes Deployment
         12.2.4.3: Example CI/CD Pipeline
      12.2.5: Deploy
      12.2.6: Operate
      12.2.7: Monitor
         12.2.7.1: Logging to Standard Input
         12.2.7.2: Distributed Tracing
         12.2.7.3: Metrics Collection
         12.2.7.4: Metrics Visualization
         12.2.7.5: Alerting
      12.2.8: Software System Alerts Dashboard Example
      12.2.9: Microservice Grafana Dashboard Example
         12.2.9.1: Logging
         12.2.9.2: OpenTelemetry Log Data Model
         12.2.9.3: PrometheusRule Example
13: Conclusion
14: Appendix A
15: Appendix B