Developer Hygiene
Purpose
Section titled “Purpose”Developer hygiene reduces defects before CI and keeps collaboration predictable across teams and languages.
Nexa context
Section titled “Nexa context”Nexa services interact across React, Node.js, FastAPI, Kubernetes, Databricks, Snowflake, and cloud APIs. Small local inconsistencies become expensive when they cross service boundaries.
Standard
Section titled “Standard”-
MUST: Keep feature branches short-lived and focused on one coherent change.
-
MUST: Run the repository’s local format, lint, type-check, and unit-test commands before opening a PR.
-
MUST: Never commit credentials, tokens, private keys, generated secrets, or customer data.
-
MUST: Update tests and documentation in the same change as behavior.
-
MUST: Use meaningful commit messages and PR descriptions.
-
MUST: Treat warnings introduced by the change as defects unless explicitly accepted.
-
SHOULD: Prefer small PRs that can be reviewed in one sitting.
-
SHOULD: Use feature flags for incomplete behavior that must merge early.
-
SHOULD: Record non-obvious decisions in an ADR or code comment explaining why, not what.
Working model
Section titled “Working model”Before coding, sync with the target branch and confirm acceptance criteria. During coding, keep changes cohesive and test at the lowest useful level. Before the PR, inspect the diff as a reviewer would, remove debugging artifacts, and confirm migrations or configuration changes are reversible.
Evidence of compliance
Section titled “Evidence of compliance”Compliance is demonstrated through repository configuration, protected-branch settings, CI results, and review records. Teams should be able to show the evidence without reconstructing it manually.
Common failure modes
Section titled “Common failure modes”Common failures include mixing refactors with functional changes, relying on CI as the first local test, suppressing scanner findings without explanation, and leaving temporary configuration in shared environments.
Maturity path
Section titled “Maturity path”The initial standard favors consistency and auditable automation. Exceptions and advanced controls are introduced only after the baseline is adopted across repositories.