田野放空

Code CR Template#

Basic Section#

1. Coding style follows the Alibaba Java Development Manual.

2. For large and complex process programs, flowcharts and sequence diagrams must be provided.

   1. The CR student should briefly describe the project size and background at the beginning of the CR. For complex processes, the CR should check if the implementation logic matches the technical solution to reduce the gap between implementation and technical solution.

3. Is the business logic properly divided? Is there any coupling?

   1. Business logic involving domain logic should be split if it is obvious or coupled.

4. Is the code logic clear?

   1. The CR student needs to explain the main logic clearly.

5. Reasonable and effective comments.

   1. For complex code or logic that the CR has questions about, reasonable and effective comments are required.

6. Are there any redundant code?

   1. Unused or unreferenced code should be deleted.

7. Are there any potential NPE (NullPointerException)?

   1. NPE is a common bug in daily work.
   2. Context fields should be checked for null, getXX() operations, and unboxing of primitive types. Defensive judgment or Optional is needed.

8. Logging printing standards.

   1. Logging should use placeholders for printing, as string concatenation uses the append() method of StringBuilder, which has some performance loss.

      logger.info("are u ok : oid 1", oid);
      logger.info("are u ok : oid 1", oid);

9. Are there any Maven dependency conflicts?

   • Many runtime bugs are often caused by dependency conflicts. The CR suggests confirming if there are any changes in the pom.

10. Resource release.

    • Whether it is network IO or file IO, the logic of resource release needs to be checked by the CR.

11. Unified error codes.

    • Prohibit using unified error codes such as -1, 500, etc. It is best to define enums for easy problem tracing.

12. Exception handling.

    • Places where exceptions occur need to confirm whether further operations are needed: direct return, throwing exceptions, retry processing, recovery processing, circuit breaker processing, degradation processing, business closure.

Intermediate Section#

1. Is the database index design reasonable and effective?

   • The CR student needs to explain the reasons and effects of designing the index clearly.

2. Can the code use design patterns or is the use of design patterns excessive?

   • If/else statements are excessive or scene distribution class logic, it is recommended to use the strategy pattern.
   • It is not recommended to use complex inheritance abstraction logic for small requirements. Good design is the reasonable modeling of the model.
   • It is not recommended to introduce complex frameworks to solve simple problems. Some students are enthusiastic about using one framework to handle all architectures (such as DDD Cola). After all, the historical and complexity of the code cannot be evaluated. Good business framework scaffolding tends to solve problems with this kind of thinking, rather than blindly copying.

3. Is the middleware usage best practice?

   • For example, whether MQ consumption is correctly acked or needs to be retried or discarded.
   • For example, whether there is a large key design in Redis and whether it needs to be designed reasonably.
   • For example, whether the timeout setting for ES queries is reasonable.

4. Thread pool usage, whether the parameters are correct, and whether there is business isolation.

   • Whether to use the company's framework or the built-in parameterized thread pool construction method of JDK.
   • Whether the number of threads and queue size are configured reasonably.
   • Whether to configure an isolated thread pool for multiple businesses or callers.

5. If locks are used, whether the lock scope and granularity are appropriate.

   • The lock interval of distributed locks needs to be checked for any impact on others.

6. Transaction processing: whether transactions are needed and whether they are effective.

   • Whether persistence operations have not added transactions.
   • Whether internal calls within a class cause transactions to not take effect.

Advanced Section#

Performance Optimization#

1. Is caching added where needed?

   • For example, if the performance of the dependent external interface is poor, add appropriate caching to solve query problems.

2. Optimistic locking instead of pessimistic locking.

3. Use multithreading to accelerate multiple interface aggregations.

Consistency#

Idempotence#

1. Idempotence based on status.

   • Based on status, it means that calling this interface will cause a change in status. If the status has already changed, just return the previous result.

2. Idempotence based on a certain key.

   • Usually, a separate field is used to bind or a log table is used to record. If it exists, just return.

Retry#

1. Retry when the interface call fails.

   1. It is not recommended to retry for external interfaces with write operations. Let the external party initiate the request again if a retry is needed.
   2. Check if the provided interface supports idempotent return.