Backend Development 40 min read

Principles and Practices of Code Review: Insights from a Tencent Backend Engineer

This article shares a Tencent backend engineer's extensive experience with code review, outlining why engineers and leaders should practice it, identifying common pitfalls such as duplicated code and premature optimization, and presenting concrete principles, model design advice, and Go code examples to improve software quality.

Continuous Delivery 2.0
Continuous Delivery 2.0
Continuous Delivery 2.0
Principles and Practices of Code Review: Insights from a Tencent Backend Engineer

In the software industry, Code Review is widely regarded as a valuable engineering practice, yet many teams either ignore it or treat it as a mere formality without real impact.

The author, a Tencent PCG backend developer and a member of the Golang code committee, reflects on his experiences reviewing countless code submissions and offers his philosophy and practical guidance.

Why technical staff, including leaders, should perform code reviews

‘Talk is cheap, show me the code.’ Knowledge without practice is insufficient; engineers must actively apply design principles to code, enabling concrete discussions and mutual learning during reviews.

Leaders who do not write code must still provide solid best‑practice advice when reviewing, demonstrating an understanding of optimal implementations.

Why developers should think about and summarize best practices during reviews

The author categorizes technical expertise into several directions, such as “奇技淫巧” (clever tricks), “领域奠基” (foundational domain knowledge), “理论研究” (theoretical research), “产品成功” (product success), and “最佳实践” (best practices), emphasizing that continuous refinement of best‑practice methodology is essential for high‑quality systems.

Root causes of code degradation

Repeated code, early decisions that become hard to refactor, and premature optimization are common issues. The article includes real Go examples illustrating these problems:

// BatchGetQQTinyWithAdmin 获取QQ uin的tinyID, 需要主uin的tiny和登录态
// friendUins 可以是空列表, 只要admin uin的tiny
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)),
        })
    }
    // ... omitted for brevity ...
}

When similar logic is duplicated across services, maintaining forward compatibility becomes painful, and developers must repeatedly understand and modify the same protocol handling code.

Another example shows a function that grew beyond reasonable size, leading to readability and maintenance problems:

// Update 增量更新
func (s *FilePrivilegeStore) Update(key def.PrivilegeKey,
    clear, isMerge bool, subtract []*access.AccessInfo, increment []*access.AccessInfo,
    policy *uint32, adv *access.AdvPolicy, shareKey string, importQQGroupID uint64) error {
    // ... lengthy implementation ...
}

Key issues include deep nesting, mixing high‑level and low‑level logic, and difficulty in tracing bugs.

Principles for better code

KISS – Keep It Simple and Stupid: simplicity requires deep understanding of the problem domain.

Composition over inheritance: favor assembling small, reusable components rather than deep class hierarchies.

Economy of code: avoid unnecessary bloat; smaller programs are easier to maintain.

Transparency: make design and implementation visible for review and debugging.

Conventional interfaces: avoid overly clever or unconventional APIs that hinder collaboration.

Silence is golden: log only essential information.

Fail fast with clear error reporting.

The article also discusses model‑driven design, the importance of aligning code with business requirements, and the need for continuous refactoring as projects grow.

Practical recommendations for Go developers include strict formatting, limiting files to 800 lines, functions to 80 lines, and nesting depth to four levels, as well as using early returns to simplify control flow:

if !needContinue {
    doA()
    return
}
// ...

Finally, the author promotes the book “The Art of Unix Programming” and a limited‑time video course on continuous deployment with Golang, encouraging readers to deepen their engineering mindset.

backendgolangsoftware engineeringcode reviewBest Practices
Continuous Delivery 2.0
Written by

Continuous Delivery 2.0

Tech and case studies on organizational management, team management, and engineering efficiency

0 followers
Reader feedback

How this landed with the community

login 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.