Why Engineers and Leaders Must Do Code Review and How to Apply Effective Practices

Code is the concrete place where design ideas become reality, so a thorough code review turns abstract discussion into practical improvement and shared learning for both developers and team leaders.

Leaders who do not write code still need to understand and critique implementations, while developers benefit from feedback that forces them to reflect on design principles and avoid self‑deception.

The article classifies excellent engineers into five categories—"奇技淫巧" (skillful tricks), "领域奠基" (foundational domain work), "理论研究" (theoretical research), "产品成功" (product success), and "最佳实践" (best practice)—and argues that progressing toward the last category is essential for building high‑quality systems.

Common sources of bad code include lack of design, duplicated logic, excessive nesting, and unclear responsibilities. Without a clear model, even simple requirements can lead to tangled, unmaintainable code.

Example of duplicated code that illustrates poor protocol design:

// 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))})
}
// ... build request body ...
}

When such code is copied across the codebase, any change requires a painful, error‑prone update of every occurrence.

Another example shows a function that exceeds reasonable length and mixes multiple concerns:

// 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 }
// long block of business logic …
// ... marshal and store ...
return nil
}

The article recommends breaking such functions into smaller units, limiting functions to 80 lines, files to 800 lines, and nesting depth to four levels, using early returns and defer for lock handling.

Key practical guidelines include:

Enforce strict code formatting.

Never let a file exceed 800 lines; split when necessary.

Keep functions under 80 lines and avoid deep nesting.

Prefer early returns to reduce cognitive load.

Organize code hierarchically: packages → directories → files → structs → functions.

Immediately refactor code that violates design principles.

Log only essential information with clear identifiers.

Ask questions directly; avoid vague “suggestions”.

Model‑driven design is emphasized as a way to accommodate evolving product requirements without constant rewrites. The author cites classic works such as “The Art of Unix Programming” and “Software Engineering at Google” as essential reading for cultivating an engineering mindset.

Overall, the piece blends philosophical reflection with concrete Golang examples, urging engineers to adopt disciplined, principle‑driven practices that keep codebases clean, maintainable, and scalable.