Principles and Practices for Effective Code Review and Software Architecture

As a member of the company's Go language sub‑committee, the author reflects on many code reviews and identifies a gap between knowing design principles and actually applying them, urging engineers to improve both their code and their review practices.

Why technical staff and leaders must do code review – Code is the concrete manifestation of design ideas; reviewing it turns abstract concepts into practical, shared knowledge, and even leaders who only review can still influence best practices.

Root causes of bad code – Repeated code due to poor protocol design, early decisions that become obsolete, premature optimization, lack of rigorous reasoning about design, over‑use of inheritance, and absence of any design discipline lead to fragile, hard‑to‑maintain systems.

Key principles – The author enumerates several timeless rules such as KISS (Keep It Simple Stupid), composition over inheritance, frugality (avoid large programs unless unavoidable), transparency, minimalism in APIs, proper logging, and immediate, informative error handling. Each principle is illustrated with Go code examples wrapped in ... blocks.

// BatchGetQQTinyWithAdmin retrieves tiny IDs for QQ UINs.
func BatchGetQQTinyWithAdmin(ctx context.Context, adminUin uint64, friendUin []uint64) (adminTiny uint64, sig []byte, frdTiny map[uint64]uint64, err error) {
    // ... implementation ...
}

Other examples demonstrate early returns, proper use of defer for locks, and clear API design (e.g., a simple Point struct versus an overly verbose version).

Model design – Emphasizes the importance of understanding domain models (e.g., RBAC, calendar scheduling) before coding, to avoid costly redesigns when requirements evolve.

UNIX design philosophy – Quotes classic wisdom, stresses simplicity, composability, and the need for transparent, well‑documented code, and shows the Go http.Request struct as a model of compositional design.

type Request struct {
    Method string
    URL *url.URL
    // ... many fields omitted for brevity ...
    Header Header
    Body io.ReadCloser
    // ...
}

Concrete practice points – Enforce strict code formatting, limit file size to 800 lines, function length to 80 lines, nesting depth to four levels, and use early returns to reduce cognitive load.

if !needContinue {
    doA()
    return
}

doB()
return

Mainline development – Keeping review size under 500 lines improves thoroughness and reduces the cost of changes; continuous integration and learning resources are recommended.

The article concludes with references to classic works such as "The Art of Unix Programming" and "Software Engineering at Google", encouraging readers to internalize these principles through practice.