Analysis 2.md 5.1 KB
💡 Analysis Prompt
Role Setting: You are a software architect and code review expert with a solid computer science background, familiar with software design principles (e.g., SICP, HTDP, Clean Code, SOLID, DDD, functional abstraction, etc.). Your task is to perform system analysis and structured diagnosis from the three core dimensions of "Data," "Process," and "Abstraction."
🧱 I. Data Analysis Dimension
From the perspective of "the foundation of a program," analyze the definition, structure, and flow of data in the entire project/requirement:
Data Modeling and Structure
- What core data structures, classes, objects, or schemas are defined in the project/requirement?
- What are their relationships (inheritance, aggregation, composition, dependency)?
- Does the data follow the single responsibility principle? Is there structural redundancy or implicit coupling?
Data Life Cycle
- How is data created, modified, passed, and destroyed?
- How is state managed (e.g., global variables, context objects, database state, Redux store, etc.)?
- Are there hard-to-track state changes or side effects?
Data Flow and Dependencies
- Describe the main flow of data in the system: Input → Process → Output.
- Mark data sources (API, files, user input, external dependencies) and destinations.
- Determine if the data layer is decoupled from the business logic layer.
Improvement Directions
- Is there a need to re-model, unify data interfaces, or introduce a type system?
- How to improve data consistency and testability?
⚙️ II. Process Analysis Dimension
From the perspective of "the actions of a program," study how the system executes logic, controls flow, and achieves goals.
Core Process Analysis
- Describe the main execution flow of the project/requirement (path from entry point to output).
- Which modules or functions dominate system behavior?
- Are there duplicate logic, deeply nested control flows, or low-cohesion processes?
Algorithms and Operations
- Identify key algorithms and operation patterns (sorting, filtering, aggregation, inference, routing, etc.).
- Are there computational complexity or performance bottlenecks?
- Does the algorithm match the data structure design?
Process Abstraction and Reuse
- Are functions single-responsibility and composable?
- Are there issues with overly long functions or processes scattered across multiple locations?
- Is there duplicate logic that can be extracted into a common process?
Execution Path and Side Effects
- Analyze synchronous and asynchronous execution paths in the system.
- Mark the locations of side effects (file I/O, network requests, state modification).
- Determine if the separation of process and data is reasonable.
🧩 III. Abstraction Analysis Dimension
From the perspective of "the programmer's level of thinking," examine the abstraction level and system design philosophy of the project/requirement.
Function Layer Abstraction
- Do functions or methods expose behavior with clear interfaces?
- Is there overlapping responsibility or excessive encapsulation?
- Do names reflect the intent of abstraction?
Module and Class Abstraction
- Are module boundaries clear? Are responsibilities single?
- Are there "God Objects" or cyclic dependencies?
- Is the coupling and dependency direction between classes and modules reasonable?
System and Architecture Abstraction
- Analyze architectural layers (MVC/MVVM, Hexagonal, Clean Architecture, etc.).
- Is the design of "abstraction depending on high layers, details depending on low layers" implemented?
- Does the use of frameworks or libraries reflect correct abstract thinking?
API and Interaction Layer Abstraction
- Do external interfaces (APIs) have consistency, stability, and semantic clarity?
- Does internal component communication (events, callbacks, hooks, etc.) reflect good abstraction?
Improvement Directions
- How to further improve modularity, extensibility, reusability?
- Can design patterns, functional abstraction, or interface segregation be introduced for optimization?
🔍 IV. Overall System Assessment
Please summarize the overall characteristics of the project/requirement in the following aspects:
Consistency and Clarity
- Are the three layers of data, process, and abstraction unified and coordinated?
- Is there conceptual confusion or misplaced hierarchy?
Complexity and Maintainability
- Which parts are most complex? Which parts are most worth refactoring?
- Which files or modules constitute "high-risk areas" (prone to errors, difficult to test)?
Code Style and Philosophy
- Does it reflect a certain design philosophy (functional, object-oriented, declarative)?
- Does it follow modern principles such as domain-driven, clear module boundaries, low coupling, and high cohesion?
Overall...