# Code Reuse Thinking Guide

> Use this before adding a new utility, service method, plugin pattern, or KSQL snippet.

---

## Search First

Search for existing code by:

- Entity/form ID and bill name
- Field key and DB column
- Operation key such as submit, audit, save, close, sync
- Helper class names and package names
- Error message text and error codes
- Similar plugin suffixes: `FormPlugin`, `BillPlugin`, `ListPlugin`, `OpPlugin`, `Validator`

---

## Reuse Decision

| Situation | Preferred action |
| --- | --- |
| Same behavior already exists | Reuse or extract only if duplication is meaningful |
| Similar behavior exists with platform nuance | Follow the local pattern and document the difference |
| Existing helper is unsafe or outdated | Avoid spreading it; propose a small replacement path |
| No reusable code exists | Add the narrowest helper near the owning module |

---

## Anti-Patterns

- Creating generic `Kingdee*Helper` classes without a clear owner.
- Copying a plugin and leaving stale form IDs, field keys, or messages.
- Adding reflection or dynamic field access when typed/platform helpers exist.
- Adding a shared abstraction for only two call sites with different lifecycle needs.

---

## Review Questions

- Is the new code closer to the domain owner than to a random common package?
- Does the helper hide metadata assumptions, or make them explicit?
- Can tests cover the helper without a full platform runtime?
- Will another AI session know when to use this helper from the naming and docs?