Start by finding out from the user, the proposed name, purpose and meaning of the new resource.
Namespaced or not?
Expected arity.
Relationship to other resources (ownership/peer/selection-based links?).
Try to get a full list of the current aspects of the resource that need to be configured and the "direction of travel" for extensions to those in future.
Avoid booleans, in favour of enums that can be extended later. If in doubt, use Enabled/Disabled in place of a bool.
NO fooBarEnabled: true | false
YES fooBar: Enabled | Disabled
Follow naming schemes laid out there:
관련 스킬
lowerCamel for field names
UpperCamel for enum values
Place a lot of weight on future maintenance and extension.
Many Calico resources (such as FelixConfiguration and NetworkPolicy are poor examples, they use large "bag" structs).
Group aspects of the object into sub-structs
Make use of the union pattern for controlling alternation with efficient kubebuilder annotations instead of requiring custom inter-field validation.
Consider ergonomics of using the new resource with kubectl; propose suitable kubebuilder annotations to print useful columns.
Consider including a status sub-resource if the resource will naturally be operated upon by a kubernetes controller.
When designing policy-related structs or similar, it's generally better to have separate structs for "ingress" and "egress" rule types, even if they are identical right now. Over time they tend to diverge.
Avoid custom int-or-string fields in most cases. It's OK to use existing types but it's generally better to use unions.
Review the naming and structure critically for consistency. Pay attention to suffix and prefix usage. Fields representing similar concepts should "read as siblings".
Union pattern
This is a common pattern in Kubernetes APIs that allows extension over time. It avoids bloating a parent struct with many fields that are mutually exclusive. For example, the various flavours of port/protocol match in a network policy rule may be expressed like this: