chore: cleanup orphaned content files

2026-08-30 17:57:21 +08:00 · 2026-05-14 07:40:39 +00:00
parent 3db5d4a5ec
commit 7a58ab1c7a
13 changed files with 0 additions and 161 deletions
@@ -1,17 +0,0 @@
-# Avoid Hasty Abstractions
-
-Creating abstractions is an important part of software development, but creating too many abstractions or creating them too early can lead to unnecessary complexity and make the code harder to understand and maintain.
-
-Here are some ways to avoid hasty abstractions in system architecture:
-
- Understand the problem that needs to be solved before creating an abstraction.
- Start with a simple solution and only create an abstraction when it becomes clear that the solution is becoming too complex.
- Use code refactoring techniques to simplify the code before creating an abstraction.
- Avoid creating abstractions for the sake of creating abstractions.
- Use established design patterns and practices when creating abstractions, but do not force them into the code.
- Use automated testing to ensure that the abstraction does not introduce new bugs or break existing functionality.
- Create abstraction in a way that it's easy to test, debug, and reason about.
-
-Learn more from the following links:
-
- [@article@AHA Programming](https://kentcdodds.com/blog/aha-programming)
@@ -1,10 +0,0 @@
-# Class Invariants
-
-A class invariant is a set of conditions that must be true for any object of a class, at any point in time. In object-oriented programming (OOP), class invariants are used to define the valid states of an object and to ensure that the object always remains in a valid state.
-
-Class invariants are typically defined in the constructor of a class and are enforced through the use of private methods and data members that are used to validate the state of the object. They are also checked in the class's methods before and after any operation that can change the state of the object.
-
-Learn more from the following links:
-
- [@article@Overview of Class invariant](https://en.wikipedia.org/wiki/Class_invariant)
- [@article@The concept of class invariant in object-oriented programming](https://arxiv.org/abs/2109.06557)
@@ -1,19 +0,0 @@
-# Clean Code Principles
-
-Clean code is code that is easy to read, understand, and maintain. It follows a set of principles that are designed to make the code more readable, testable, and less error-prone. Some of the key principles of clean code include:
-
- Clarity: The code should be easy to read and understand.
- Simplicity: The code should be as simple as possible, avoiding unnecessary complexity.
- Comments: Comments should be used sparingly and only when necessary to explain complex or non-obvious code.
- Naming: Variables, functions, and classes should have meaningful and descriptive names.
- Formatting: The code should be consistently formatted to improve readability.
- Functionality: The code should be organized into small, single-purpose functions and classes.
- Error handling: The code should handle errors in a consistent and predictable way.
- Testing: The code should be testable and have a high test coverage.
- Reusability: The code should be designed to be reusable and modular.
- Performance: The code should be designed to be efficient and performant.
-
-Learn more from the following links:
-
- [@article@Introduction to Clean Code & Software Design Principles](https://workat.tech/machine-coding/tutorial/introduction-clean-code-software-design-principles-nwu4qqc63e09)
- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh)
@@ -1,9 +0,0 @@
-# Code by Actor
-
-"Code by Actor" is a software development technique that encourages developers to organize their code around the actors or entities that interact with it. Actors can be users, systems, or processes that perform a specific role or function within the application. This approach helps to create a clear separation of concerns, making the code more modular, reusable, and easier to understand.
-
-Learn more from the following links:
-
- [@article@Actor Model Architecture](https://awesome-architecture.com/actor-model-architecture/actor-model-architecture/)
- [@article@Inversion of Control](https://stackoverflow.com/a/72826245)
- [@feed@Explore top posts about General Programming](https://app.daily.dev/tags/general-programming?ref=roadmapsh)
@@ -1,9 +0,0 @@
-# Commands Queries
-
-The Command and Query Responsibility Segregation (CQRS) pattern is a technique used in enterprise application development to separate the responsibilities of handling command (write) operations and query (read) operations for performing actions that change the state of the system, such as creating, updating, or deleting data. These operations are handled by Command Handlers, which are responsible for validating the data and executing the appropriate business logic.
-
-Queries are used for retrieving data from the system, such as reading data from a database or a cache. These operations are handled by Query Handlers, which are responsible for executing the appropriate query and returning the data to the caller.
-
-Learn more from the following links:
-
- [@article@Get Started with CQRS Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs)
@@ -1,3 +0,0 @@
-# Keep it Small
-
-You should design and implement small, focused components that serve a specific purpose, rather than large, monolithic components that try to do everything. This can help to improve the maintainability and scalability of the system by making it easier to understand, test, and modify individual components.
@@ -1,17 +0,0 @@
-# Keep Tests Independent
-
-Keeping tests independent helps ensures that the tests are reliable, repeatable, and easy to maintain. When tests are independent, a change in one test will not affect the results of other tests.
-
-Here are some ways to keep tests independent in system architecture:
-
- Use dependency injection to decouple the test code from the application code. This allows the tests to be run without the need to instantiate the application objects directly.
- Use mocks or stubs to isolate the test from external dependencies such as databases, APIs, or other services.
- Use test data that is self-contained and does not rely on external data or state.
- Use a test framework that supports running tests in parallel, so that the tests can be run independently of each other.
- Use test-driven development (TDD), which involves writing tests before writing the application code. This ensures that the tests are independent and that the code is written with testability in mind.
- Avoid global state and shared mutable state as it may cause unexpected results.
-
-Learn more from the following links:
-
- [@article@Keeping Tests Valuable](https://www.checklyhq.com/learn/headless/valuable-tests/)
- [@feed@Explore top posts about Testing](https://app.daily.dev/tags/testing?ref=roadmapsh)
@@ -1,7 +0,0 @@
-# Meaningful Names
-
-You should follow the practice of giving clear and descriptive names to different components of a system, such as variables, functions, and classes. This can help to make the system more understandable and maintainable by clearly communicating the purpose of each component and its intended usage.
-
-Learn more from the following links:
-
- [@article@A Guide for Naming Things in Programming](https://levelup.gitconnected.com/a-guide-for-naming-things-in-programming-2dc2d74879f8)
@@ -1,10 +0,0 @@
-# Message Queues Streams
-
-Message queues and streams are architectural patterns that are used to decouple different components of a system and enable asynchronous communication between them.
-
-Message Queues: A message queue is a software component that allows multiple systems or applications to communicate with each other by passing messages between them. Messages are stored in a queue, and each message is processed by a single consumer. This pattern is useful for systems where there is a high degree of variability in the rate of message production and consumption, and where the sender and receiver do not need to be active at the same time. Examples of message queue systems are Apache Kafka, RabbitMQ, and Amazon SQS.
-
-Learn more from the following links:
-
- [@article@System Design — Message Queues](https://medium.com/must-know-computer-science/system-design-message-queues-245612428a22)
- [@article@Overview of Message Queue pattern](https://badia-kharroubi.gitbooks.io/microservices-architecture/content/patterns/communication-patterns/message-queue-pattern.html)
@@ -1,9 +0,0 @@
-# Scope Visibility
-
-Scope visibility refers to the accessibility or visibility of variables, functions, and other elements in a program, depending on the context in which they are defined. In object-oriented programming (OOP), scope visibility is controlled through the use of access modifiers, such as "public," "private," and "protected."
-
- Public: A public element can be accessed from anywhere in the program, both within the class and outside of it.
- Private: A private element can only be accessed within the class in which it is defined. It is not accessible to other classes, even if they inherit from the class.
- Protected: A protected element can only be accessed within the class and its subclasses.
-
-There are variations of scope visibility based on the programming language, but these are the most common.
@@ -1,19 +0,0 @@
-# Software Design Principles
-
-There are many software design principles that aim to guide the development of software in a way that makes it easy to understand, maintain, and extend. Some of the most common design principles include:
-
- SOLID principles (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle)
- DRY (Don't Repeat Yourself)
- YAGNI (You Ain't Gonna Need It)
- KISS (Keep It Simple, Stupid)
- LoD (Law of Demeter)
- Composition over Inheritance
- Encapsulate What Varies
- Hollywood Principle
- Program Against Abstractions
-
-By following these design principles, software can be developed in a way that is easy to understand, maintain, and extend, and that is less prone to bugs.
-
-Learn more from the following resources:
-
- [@video@Software Design Principles For Beginners](https://www.youtube.com/watch?v=60EqoRcanpo)
@@ -1,16 +0,0 @@
-# Use Cases
-
-Use Cases are a pattern used in enterprise application development to represent the functional requirements of a system. They describe the interactions between the system and its users, and the steps that are required to accomplish a specific goal. Use cases are a way to capture the requirements of the system in a way that is easily understood by both the development team and the stakeholders.
-
-A use case is a description of a sequence of actions that a system performs in response to a request from a user, in order to achieve a specific goal. A use case typically includes:
-
- The actor (user) who initiates the action
- The goal that the actor wants to achieve
- The steps required to achieve the goal, including any alternative paths or error conditions
- The expected outcome of the interaction
-
-Use cases are often used to drive the design and development of the system, as they provide a clear and detailed understanding of the requirements.
-
-Learn more from the following links:
-
- [@article@Use Case Patterns](https://caminao.blog/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/)
@@ -1,16 +0,0 @@
-# Use Meaningful Names
-
-Using meaningful names is important for making the code clear, readable, and easy to understand. Meaningful names can help to convey the intent and function of variables, functions, classes, and other elements of the code.
-
-Here are some ways to use meaningful names in system architecture:
-
- Use descriptive and meaningful names for variables, functions, classes, and other elements of the code.
- Use consistent naming conventions throughout the codebase, such as camelCase for variables and PascalCase for functions and classes.
- Use abbreviations and acronyms sparingly and only if they are widely understood.
- Use meaningful prefixes or suffixes to indicate the type or purpose of a variable or function, such as "is" or "get" for boolean variables or "list" for array variables
- Avoid using single letter variable names or generic names, such as "temp" or "x" that do not convey any meaning.
- Avoid using overly long or complex names that make the code harder to read.
-
-Learn more from the following links:
-
- [@article@How to Write Meaningful Variable Names?](https://workat.tech/machine-coding/tutorial/writing-meaningful-variable-names-clean-code-za4m83tiesy0)