Fundamentals 9 min read

Essential Coding Habits Every Engineer Should Master

The article outlines practical coding habits—thorough input validation, comprehensive logging, careful RPC handling, batch processing, cautious SQL execution, safe extensions, disciplined refactoring, minimal dependencies, data consistency, and avoiding over‑engineering—to help engineers write reliable, maintainable code.

Senior Tony
Senior Tony
Senior Tony
Essential Coding Habits Every Engineer Should Master

Validate All Input Parameters

Treat every incoming parameter as potentially malicious (“All input is evil”). Perform layered validation: non‑null checks, length limits, format verification, and full business‑rule validation. In an e‑commerce order flow, verify user status, product availability, stock levels, and coupon eligibility before processing.

Comprehensive Logging

Log key business and branch logic in development, testing, and production environments. Detailed logs are essential for rapid troubleshooting, even when using log aggregation tools such as ELK or SkyWalking. Skipping logs saves time now but incurs greater cost during incident resolution.

RPC Calls Must Account for Network Unreliability

Unlike in‑process calls, RPC traverses an unreliable network. Design for three failure modes:

Request never reaches the provider – implement fallback or circuit‑breaker.

Provider receives the request but fails to return a response – set appropriate timeouts and retry policies.

Determine timeout and retry counts based on request type (read vs. write), business criticality, and concurrency level.

Avoid Single‑Item Calls Inside Large Loops

Do not invoke a single‑item RPC or SQL statement repeatedly in a high‑iteration loop. This creates performance bottlenecks and excessive log volume. Replace with batch APIs or bulk SQL operations (e.g., INSERT … VALUES … or SELECT … WHERE id IN (…)).

Test Complex SQL on Read‑Only Replicas

Before running heavy multi‑table queries on production, execute them on a read‑only replica, examine the EXPLAIN plan, and ensure no full‑table scans ( type=ALL). Avoid running such queries on the primary master to prevent service disruption.

Extend Rather Than Modify Core Workflows

When adding features to a middle‑platform service, prefer extensions or new modules over direct changes to existing core processes, especially if you lack complete domain knowledge. This reduces the risk of unintended side effects on other business lines.

Refactor, Don’t Rewrite

Refactoring improves structure and maintainability without discarding existing code. Only rewrite when the codebase is so tangled that refactoring would be less efficient than building a clean replacement.

Introduce New Dependencies Only When Necessary

Adopt a “simple and reliable” mindset: add Redis, Elasticsearch, asynchronous MQ, or design patterns only if they solve a concrete problem. Unnecessary dependencies increase system complexity and operational overhead.

Ensure Data Consistency Across Multiple Sources

In architectures with multiple data stores (e.g., MySQL master‑slave, MySQL + Redis, MySQL + Elasticsearch), designate a primary source of truth. Synchronize secondary stores from the primary and implement eventual‑consistency strategies such as change data capture (CDC) or scheduled reconciliation jobs.

Avoid Over‑Engineering

Build systems that meet current requirements; avoid speculative features or premature scaling that add unnecessary complexity and maintenance burden.

RPCBatch ProcessingData ConsistencyloggingSQL Optimizationinput validationsimplicitycoding habits
Senior Tony
Written by

Senior Tony

Former senior tech manager at Meituan, ex‑tech director at New Oriental, with experience at JD.com and Qunar; specializes in Java interview coaching and regularly shares hardcore technical content. Runs a video channel of the same name.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.