Effective Code Review and Software Design Principles for Go Backend Development

As a member of the company’s Golang sub‑committee, the author has reviewed countless pull requests and observed that many engineers lack solid code‑review habits and fundamental design thinking. The article begins by emphasizing that code is the concrete manifestation of design ideas and that reviewing code should be a dialogue that bridges theory and practice.

Why code review matters : The author argues that merely knowing a design principle is insufficient; engineers must apply it in real code. Leaders who do not write code can still guide reviews by offering concrete alternatives, ensuring the team internalizes best practices.

Root causes of bad code : The article lists several typical problems, such as duplicated implementations caused by poor protocol design, early decisions that become obsolete, premature optimization, lack of rigorous reasoning, over‑use of inheritance, and absence of any design at all. Each issue is illustrated with short Go snippets.

Example of duplicated code :

// 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))})
    }
    // ... request construction omitted for brevity
}

The author notes that when multiple developers copy such logic, any change to the underlying protocol forces edits in every copy, leading to bugs and maintenance overhead.

Early decisions that become ineffective :

// 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 {
    info, err := s.Get(key)
    if err != nil { return err }
    // ... complex merging logic omitted
    return nil
}

When the isMerge branch grows beyond 50 lines, the function becomes hard to read, forcing reviewers to jump between high‑level flow and low‑level details.

Design principles :

KISS (Keep It Simple Stupid) : Simplicity is not just about short code but about a concise, complete mental model of the problem.

Composition over inheritance : Use small, composable components (e.g., Go’s http.Request struct) instead of deep inheritance trees, which are hard to evolve.

Transparency and visibility : Write code that can be mentally simulated; avoid hidden side effects and excessive logging.

Economy (thrift) principle : Do not write large programs unless absolutely necessary; keep modules small and replaceable.

Logging discipline : Emit logs only when they provide actionable information; otherwise stay silent.

The article also references the classic "Unix Programming Art" book, extracting timeless engineering axioms such as the importance of community knowledge, the need for clear documentation, and the value of building software that can be reasoned about without excessive mental effort.

Finally, the author provides concrete actionable items for Go developers: enforce strict formatting, limit files to 800 lines, functions to 80 lines, nesting depth to four levels, and adopt early‑return patterns to reduce cognitive load. These guidelines aim to improve code readability, facilitate effective reviews, and ultimately raise the overall quality of backend services.