Why Code Review Matters: Lessons from a Golang Committee Member

As a member of the company’s Golang code committee, I have reviewed many pieces of code and comments, noticing that many developers need to improve their code review skills and overall code quality. I share my thoughts and approaches here.

Why Technical Staff and Leaders Should Do Code Review

Talk is cheap; showing code is essential. Understanding design concepts is easy, but applying them in practice is hard. Code is where design ideas materialize, and reviews enable concrete communication, learning, and adoption of best practices across the team.

Why Reviewers Should Summarize Best Practices

An architect masters many design principles, applies them across languages and toolchains, and controls large codebases for maintainability and quality. Effective engineers fall into categories such as clever tricks, foundational work, theoretical research, product success, and best practices.

Root Causes of Bad Code

Repeated code, early decisions that become obsolete, premature optimization, lack of rigorous design, and overuse of inheritance lead to fragile systems. Examples include duplicated request structures and overly complex functions that hinder readability and maintenance.

// BatchGetQQTinyWithAdmin retrieves QQ tiny IDs
func BatchGetQQTinyWithAdmin(ctx context.Context, adminUin uint64, friendUin []uint64) (adminTiny uint64, sig []byte, frdTiny map[uint64]uint64, err error) {
    var friendAccountList []*basedef.AccountInfo
    for _, v := range friendUin {
        friendAccountList = append(friendAccountList, &basedef.AccountInfo{AccountType: proto.String(def.StrQQU), Userid: proto.String(fmt.Sprint(v))})
    }
    req := &cmd0xb91.ReqBody{Appid: proto.Uint32(model.DocAppID), CheckMethod: proto.String(CheckQQ), AdminAccount: &basedef.AccountInfo{AccountType: proto.String(def.StrQQU), Userid: proto.String(fmt.Sprint(adminUin))}, FriendAccountList: friendAccountList}
    // ...
}

When protocols are poorly designed, each new consumer rewrites similar logic, leading to duplicated, hard‑to‑maintain code.

Principles for Better Code

Keep It Simple Stupid (KISS) : Simplicity is not just the first solution that comes to mind; it requires deep understanding of the problem.

Composition Over Inheritance : Use composition to build flexible modules, reducing the cognitive load of deep inheritance trees.

Transparency : Code should be visible and understandable, enabling effective debugging and review.

Economy of Code : Write the smallest program that works; avoid unnecessary bloat.

Minimalist Interfaces : Design APIs that are clear and avoid surprising behavior.

Silent Failure Principle : Only log essential information; excessive logging obscures real issues.

Immediate Error Reporting : When an exception occurs, exit promptly and provide detailed error information.

Model Design and UNIX Philosophy

Good model design anticipates future requirements, reducing costly rewrites. The UNIX programming philosophy emphasizes simplicity, composability, and clear interfaces, which align with the principles above.

Practical Tips for Golang Developers

Enforce strict code formatting.

Keep files under 800 lines and functions under 80 lines.

Limit nesting depth to four levels.

Use early returns to simplify control flow.

Organize code hierarchically with clear package structures.

Continuously refactor as the codebase evolves.

Log sparingly but include necessary context.

Mainline Development

Reviewing changes under 500 lines ensures thorough inspection and reduces the risk of large, hard‑to‑fix defects.

Recommended Reading

Read "The Art of Unix Programming" and "Software Engineering at Google" for deeper insights into enduring engineering practices.