共计 23223 个字符，预计需要花费 59 分钟才能阅读完成。
前言
作为公司代码委员会 golang 分会的理事，我 review 了很多代码，看了很多他人的 review 评论。发现不少同学 code review 与写出好代码的程度有待进步。在这里，想分享一下我的一些理念和思路。
为什么技术人员包含 leader 都要做 code review
谚语曰:‘Talk Is Cheap, Show Me The Code’。知易行难，知行合一难。嘴里要讲进去总是轻松，把他人讲过的话记住，组织一下语言，再讲进去，很容易。绝知此事要躬行。设计理念你可能一人传虚; 万人传实了一些，认为本人把握了，然而你会做么？有能力去思考、改良本人以后的实际形式和实际中的代码细节么？不客气地说，很多人仅仅是晓得并且认同了某个设计理念，进而产生了一种虚伪的安心感—本人的技术并不差。然而，他基本没有去实际这些设计理念，甚至基本实际不了这些设计理念，从后果来说，他懂不懂这些情理 / 理念，有什么差异？变成了自欺欺人。
代码，是设计理念落地的中央，是技术的出现和基本。同学们能够在 review 过程中做到落地沟通，不再是空对空的探讨，能够在理论问题中产生思考的碰撞，互相学习，大家都把握团队里积攒进去最好的实际形式！当然，如果 leader 没工夫写代码，仅仅是 review 代码，指出其他同学某些实际形式不好，要给出好的实际的意见，即便没亲手写代码，也是对最佳实际要有很多思考。
为什么同学们要在 review 中思考和总结最佳实际
我这里先给一个我本人的总结：所谓架构师，就是把握大量设计理念和准则、落地到各种语言及附带工具链（生态）下的实际办法、垂直行业模型了解，定制零碎模型设计和工程实际标准细则。进而管制 30+ 万行代码我的项目的开发便利性、可维护性、可测试性、经营品质。
厉害的技术人，次要能够分为上面几个方向：
- 奇技淫巧
把握很多技巧，以及发现技巧一系列思路，比方很多编程大赛，比的就是这个。然而，这个对工程，用途如同并不是很大。 - 畛域奠基
比方约翰 * 卡马克，他发明出了古代计算机图形高效渲染的方法论。不管如果没有他，前面会不会有人创造，他就是第一个创造了。1999 年，卡马克登上了美国时代杂志评比进去的科技领域 50 大影响力人物榜单，并且名列第 10 位。然而，相似的殿堂级地位，没有几个，不够大家分，没咱们的事儿。 - 实践钻研
八十年代李开复博士保持采纳隐含马尔可夫模型的框架，胜利地开发了世界上第一个大词汇量间断语音识别系统 Sphinx。我辈工程师，如同善于这个的很少。 - 产品胜利
小龙哥是标杆。 - 最佳实际
这个是大家都能够做到，依照下面架构师的定义。在这条路上走得好，就能为任何公司组建技术团队，组织建设高质量的零碎。
从下面的探讨中，能够看出，咱们一般工程师的进化之路，就是一直打磨最佳实际方法论、落地细节。
代码变坏的本源
在探讨什么代码是好代码之前，咱们先探讨什么是不好的。计算机是人造的学科，咱们本人制作了很多问题，进而去思考解法。
反复的代码
// 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)),
})
}
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,
} 因为最开始协定设计得不好，第一个应用接口的人，没有相似下面这个函数的代码，本人实现了一个嵌入逻辑代码的填写申请构造构造体的代码，一开始，挺好的。但当有第二个人，第三个人干了相似的事件，咱们将无奈再重构这个协定，必须做到麻烦的向前兼容。而且每个同学，都要了解一遍下面这个协定怎么填，了解有问题，就触发 bug。或者，如果某个谬误的了解，普遍存在，咱们就得找到所有这些反复的片段，都批改一遍。
当你要读一个数据，发现两个中央有，不晓得该抉择哪个。当你要实现一个性能，发现两个 rpc 接口、两个函数能做到，你不晓得选哪一个。你有面临过这样的’人生难题’么？其实怎么选并不重要了，你写的这个代码曾经在走向 shit 的路线上迈出了松软的一步。
然而，A little copying is better than a little dependency。这里提一嘴，不开展。
这里，我必须额定说一句。大家应用 trpc。感觉本人被激励’每个服务搞一个 git’。那，你这个服务里拜访 db 的代码，rpc 的代码，各种能够复用的代码，是用的大家都复用的 git 下的代码么？每次都反复写一遍，db 字段细节改了，每个应用过 db 的 server 对应的 git 都改一遍？这个通用 git 曾经写好的接口应该不晓得哪些 git 下的代码因为本人不向前兼容的批改而永远放弃了向前不兼容的批改？
晚期无效的决策不再无效
很多时候，咱们第一版代码写进去，是没有太大的问题的。比方，上面这个代码
// 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}
incOnlyModify := update(info, &key, clear, subtract,
increment, policy, adv, shareKey, importQQGroupID)
stat := statAndUpdateAccessInfo(info)
if !incOnlyModify {
if stat.groupNumber > model.FilePrivilegeGroupMax {
return errors.Errorf(errors.PrivilegeGroupLimit,
"group num %d larger than limit %d",
stat.groupNumber, model.FilePrivilegeGroupMax)
}
}
if !isMerge {if key.DomainID == uint64(access.SPECIAL_FOLDER_DOMAIN_ID) &&
len(info.AccessInfos) > model.FilePrivilegeMaxFolderNum {
return errors.Errorf(errors.PrivilegeFolderLimit,
"folder owner num %d larger than limit %d",
len(info.AccessInfos), model.FilePrivilegeMaxFolderNum)
}
if len(info.AccessInfos) > model.FilePrivilegeMaxNum {
return errors.Errorf(errors.PrivilegeUserLimit,
"file owner num %d larger than limit %d",
len(info.AccessInfos), model.FilePrivilegeMaxNum)
}
}
pbDataSt := infoToData(info, &key)
var updateBuf []byte
if updateBuf, err = proto.Marshal(pbDataSt); err != nil {
return errors.Wrapf(err, errors.MarshalPBError,
"FilePrivilegeStore.Update Marshal data error, key[%v]", key)
}
if err = s.setCKV(generateKey(&key), updateBuf); err != nil {return errors.Wrapf(err, errors.Code(err),
"FilePrivilegeStore.Update setCKV error, key[%v]", key)
}
return nil
} 当初看，这个代码挺好的，长度没超过 80 行，逻辑比价清晰。然而当 isMerge 这里判断逻辑，如果退出更多的逻辑，把部分行数撑到 50 行以上，这个函数，滋味就坏了。呈现两个问题：
1）函数内代码不在一个逻辑档次上，浏览代码，原本在浏览着顶层逻辑，忽然就掉入了长达 50 行的 isMerge 的逻辑解决细节，还没看完，读者曾经忘了后面的代码讲了什么，须要来回看，挑战本人大脑的 cache 尺寸。
2）代码有问题后，再新加代码的同学，是改还是不改前人写好的代码呢？出 bug 谁来背？这是一个灵魂拷问。
过早的优化
这个大家听了很多了，这里不赘述。
对合理性没有奢求
‘两种写法都 ok，你轻易挑一种吧’，‘我这样也没什么吧’，这是我常常听到的话。
// Get 获取 IP
func (i *IPGetter) Get(cardName string) string {i.l.RLock()
ip, found := i.m[cardName]
i.l.RUnlock()
if found {return ip}
i.l.Lock()
var err error
ip, err = getNetIP(cardName)
if err == nil {i.m[cardName] = ip
}
i.l.Unlock()
return ip
}
i.l.Unlock()能够放在以后的地位，也能够放在 i.l.Lock()上面，做成 defer。两种在最后结构的时候，如同都行。这个时候，很多同学态度就变得不坚定。实际上，这里必须是 defer 的。i.l.Lock()
defer i.l.Unlock()
var err error
ip, err = getNetIP(cardName)
if err != nil {return "127.0.0.1"}
i.m[cardName] = ip
return ip 这样的批改，是极有可能产生的，它还是要变成 defer，那，为什么不一开始就是 defer，进入最正当的状态？不一开始就进入最正当的状态，在后续合作中，其他同学很可能犯错！
总是面向对象 / 总喜爱封装
我是软件工程科班出身。学的第一门编程语言是 c++。教材是这本。过后本人读完教材，初入程序设计之门，对于外面讲的’封装’，惊为天人，如许美好的设计啊，面向对象，如许智慧的设计啊。然而，这些年来，我看到了大牛’云风’对于’毕业生应用 mysql api 就喜爱搞个 class 封装再用’的讥嘲；看到了各种莫名其妙的 class 定义；领会到了常常要去看一个莫名其妙的继承树，必须要把整个继承树整体读明确能力确认一个细小的逻辑分支；屡次领会到了我须要辛苦地压抑住本人的抵触情绪，去细度一个自作聪明的被封装的代码，确认我的 bug。除了 UI 类场景，我认为少用继承、多用组合。
template<class _PKG_TYPE>
class CSuperAction : public CSuperActionBase {
public:
typedef _PKG_TYPE pkg_type;
typedef CSuperAction<pkg_type> this_type;
...
} 这是 sspp 的代码。CSuperAction 和 CSuperActionBase，一会儿 super，一会儿 base，Super 和 SuperBase 是在怎么的两个抽象层次上，不通读代码，没人能读明确。我想确认任何细节，都要把多个档次的代码都通读了，有什么封装性可言？
好，你说是作者没有把 class name 获得好。那，问题是，你能获得好么？一个刚入职的 T1.2 的同学能把 class name、class 树设计得好么？即便是对简略的业务模型，也须要无数次’坏’的对象形象实际，能力造就出一个具备合格的 class 形象能力的同学，这对于大型却涣散的团队合作，不是破坏性的？曾经有了一套继承树，想要增加性能就只能在这个继承树里增加，以前的继承树不再适宜新的需要，这个继承树上所有的 class，以及应用它们的中央，你都去改？不，是个正常人都会放弃，开始堆屎山。
封装，就是我能够不关怀实现。然而，做一个稳固的零碎，每一层设计都可能出问题。abi，总有适合的用法和不适合的用法，真的存在咱们能齐全不关怀封装的局部是怎么实现的？不，你不能。bug 和性能问题，经常就呈现在，你用了谬误的用法去应用一个封装好的函数。即便是 android、ios 的 api，golang、java 现成的 api，咱们经常都要去探索实现，能力把 api 用好。
那，咱们是不是该一上来，就做一个透明性很强的函数，才更为正当？使用者想晓得细节，进来吧，我的实现很易读，你看看就明确，应用时不会迷路！对于逻辑简单的函数，咱们还要强调函数外部工作形式’能够让读者在大脑里设想出现残缺过程’的可现性，让使用者轻松读懂，有把握，应用时，不迷路！
基本没有设计
这个最可怕，所有需要，上手就是一顿撸，’ 设计是什么货色？我一个文件 5w 行，一个函数 5k 行，干不完需要？’ 从第一行代码开始，就是无设计的，随便地踩着满地的泥坑，对于旁人的眼光没有感觉，一个人独舞，产出的代码，实现了需要，覆灭了接手本人代码的人。这个就不举例了，每个同学应该都能在本人的我的项目类发现这种代码。
必须形而上的思考
经常，同学们听演讲，公开课，就喜爱听一些细枝末节的’干活’。这没有问题。然而，你干了几年活，学习了多少干货知识点？构建起本人的技术思考’面’，进入平面的’工程思维’，把技术细节和零碎要满足的需要在思考上连接起来了么？当听一个需要的时候，你能思考到本人的 code package 该怎么组织，函数该怎么组织了么？
那，技术点要怎么和需要连接起来呢？答案很简略，你须要在工夫里总结，总结出一些明确的准则、思维过程。思考怎么去总结，特地像是在思考哲学问题。从一些琐碎的细节中，由具体情况回升到一些准则、公理。同时，大家在承受准则时，不应该是承受和记住准则自身，而应该是构造准则，让这个准则在本人这里从新推理一遍，本人齐全把握这个准则的适用范围。
再进一步具体地说，对于工程最佳实际的形而上的思考过程，就是：
把工程实际中遇到的问题，从问题类型和解法类型，两个角度去归类，总结出一些无限实用的准则，就从点到了面。把诸多总结出的准则，组合利用到本人的我的项目代码中，就是把多个面联合起来构建了一套平面的最佳实际的计划。当你这套计划能适应 30w+ 行代码的我的项目，超过 30 人的我的项目，你就架构师入门了！当你这个我的项目，是多端，多语言，代码量超过 300w 行，参加人数超过 300 人，代码品质仍然很高，代码仍然在高效地自我迭代，每天打消掉过期的代码，填充高质量的替换旧代码和新生的代码。
祝贺你，你曾经是一个很高级的架构师了！再进一步，你对某个业务模型有独到或者全面的了解，构建了一套行业第一的解决方案，联合方才高质量实现的能力，实现了这么一个我的项目。没啥好说的，你曾经是专家工程师了。级别再高，我就不理解了，不在这里探讨。
那么，咱们要重头开始积攒思考和总结？不，有一本书叫做《unix 编程艺术》，我在不同的期间别离读了 3 遍，等一会，我讲一些外面提到的，我感觉在腾讯尤其值得拿出来说的准则。这些准则，正好就能作为 code review 时大家断定代码品质的原则。但，在那之前，我得讲一下另外一个很重要的话题，模型设计。
model 设计
没读过 oauth2.0 RFC，就去设计第三方受权登陆的人，终归还要再创造一个撇脚的 oauth。
2012 年我刚毕业，我和一个去了广州联通公司的华南理工毕业生聊天。过后他说他工作很不开心，因为工作里不常常写代码，而且认为本人有 ACM 比赛金牌级的算法熟练度 + 对 CPP 代码的相熟，写下一个个指针操作内存，什么程序写不进去，什么事件做不好。过后我感觉，挺有情理，编程工具在手，我什么事件做不了？
当初，我会通知他，简单如 linux 操作系统、Chromium 引擎、windows office，你做不了。起因是，他基本没进入软件工程的工程世界。不是会搬砖就能修出港珠澳大桥。然而，这么答复并不好，举证用的论据离咱们太边远了。见微知著。我当初会答复，你做不了，简略如一个权限零碎，你晓得怎么做么？沉积一堆逻辑档次一维开展的 if else？简略如一个共享文件治理，你晓得怎么做么？沉积一堆逻辑档次一维开展的 ife lse？你联通有上万台服务器，你要怎么写一个治理平台？沉积一堆逻辑档次一维开展的 ife lse？
上来就是干，能实现下面提到的三个看似简略的需要？想一想，亚马逊、阿里云折腾了多少年，最初才找到了容器 +Kubernetes 的大杀器。这里，须要谷歌多少年在 BORG 零碎上的实际，提出了优良的服务编排畛域模型。权限畛域，有 RBAC、DAC、MAC 等等模型，到了业务，又会有细节的不同。如 Domain Driven Design 说的，没有良好的畛域思考和模型形象，逻辑复杂度就是 n^2 指数级的，你得写多少 ifelse，得思考多少可能的 if 门路，来 cover 所有的不合符预期的状况。你必须要有 Domain 思考摸索、model 拆解 / 形象 / 构建的能力。
有人问过我，要怎么无效地取得这个能力？这个问题我没能答复，就像是在问我，怎么能力取得 MIT 博士的学术能力？我无法回答。惟一答复就是，进入某个畛域，就是首先去看前人的思考，站在前人的肩膀上，再用上本人的通识能力，去进一步思考。至于怎么建设好的通识思考能力，可能得去常青藤读个书吧：）或者，就在工程实际中思考和锤炼本人的这个能力！
同时，基于 model 设计的代码，能更好地适应产品经理一直变更的需要。比如说，一个 calendar(日历)利用，简略来想，不要太简略！以’userid_date’为 key 记录一个用户的每日安顿不就实现了么？只往前走一步，设计了一个工作，下限分发给 100w 集体，创立这么一个工作，是往 100w 集体上面增加一条记录？你得改掉之前的设计，换 db。再往前走一步，要拉出某个用户和某个人一起要参加的所有事务，是把两个人的所有工作来做 join？如同还行。如果是和 100 集体一起参加的所有工作呢？100 集体的工作来 join？不事实了吧。
好，你引入一个群组 id，那么，你最开始的’userid_date’为 key 的设计，是不是又要批改和做数据迁徙了？常常来一个需要，你就得把零碎颠覆重来，或者基本就只能回绝用户的需要，这样的战斗力，还好意思叫本人工程师？你一开始就应该思考本人面对的业务畛域，思考本人的日历利用可能的模型边界，把可能要做的能力都拿进来思考，构建一个 model，设计一套通用的 store 层接口，基于通用接口的逻辑代码。当产品一直倒退，就是不停往模型里填内容，而不是颠覆重来。
这，思考模型边界，构建模型细节，就是两个很重要的能力，也是绝大多数腾讯产品经理不具备的能力，你得具备，对整个团队都是极其无益的。你面对产品经理时，就听取他们出于对用户体验负责思考出的需要点，到你本人这里，用一个残缺的模型去涵盖这些系统的点。
model 设计，是形而上思考中的一个方面，一个特地重要的方面。接下来，咱们来剽窃剽窃 unix 操作系统构建的实际为咱们提出的前人实践经验和’公理’总结。在本人的 coding/code review 中，站在伟人的肩膀下来思考。不反复地发现经典力学，而是往相对论挺进。
UNIX 设计哲学
不懂 Unix 的人注定最终还要反复创造一个撇脚的 Unix。–Henry Spenncer, 1987.11
上面这一段话太经典，我必须要摘抄一遍(自《UNIX 编程艺术》)：“工程和设计的每个分支都有本人的技术文化。在大多数工程畛域中，就一个业余人员的素养组成来说，有些不成文的行业素养具备与规范手册及教科书等同重要的位置(并且随着业余人员教训的与日俱增，这些教训经常会比书本更重要)。资深工程师们在工作中会积攒大量的隐性常识，他们用相似禅宗’教外别传’的形式，通过现身说法传授给后辈。软件工程算是此规定的一个例外：技术改革如此之快，软件环境突飞猛进，软件技术文化暂如朝露。
然而，例外之中也有例外。确有极少数软件技术被证实经久耐用，足以演进为强势的技术文化、有显明特色的艺术和世代相传的设计哲学。“
接下来，我用我的了解，解说一下几个咱们经常做不到的准则。
Keep It Simple Stuped!
KISS 准则，大家应该是如雷贯耳了。然而，你真的在恪守？什么是 Simple？简略？golang 语言次要设计者之一的 Rob Pike 说’大道至简’，这个’简’和简略是一个意思么？
首先，简略不是面对一个问题，咱们印入眼帘第一映像的解法为简略。我说一句，感受一下。” 把一个事件做进去容易，把事件用最简略无效的办法做进去，是一个很难的事件。” 比方，做一个三方受权，oauth2.0 很简略，所有概念和细节都是紧凑、齐备、易用的。
你感觉要设计到 oauth2.0 这个成果很容易么？要做到简略，就要对本人解决的问题有全面的理解，而后须要一直积攒思考，能力做到从各个角度和层级去意识这个问题，打磨出一个艰深、紧凑、齐备的设计，就像 ios 的交互设计。简略不是容易做到的，须要大家在一直的工夫和 code review 过程中去积攒思考，pk 中触发思考，交换中总结思考，能力做得愈发地好，靠近’大道至简’。
两张经典的模型图，简略又全面，感受一下，没看懂，能够立刻自行 google 学习一下：RBAC:
logging:
准则 3 组合准则: 设计时思考拼接组合
对于 OOP，对于继承，我后面曾经说过了。那咱们怎么组织本人的模块？对，用组合的形式来达到。linux 操作系统离咱们这么近，它是怎么架构起来的？往小里说，咱们一个串联一个业务申请的数据汇合，如果应用 BaseSession，XXXSession inherit BaseSession 的设计，其实，这个继承树，很难适应层出不穷的变动。然而如果应用组合，就能够拆解出 UserSignature 等等各种可能须要的部件，在须要的时候组合应用，一直增加新的部件而没有对老的继承树的记忆这个心智累赘。
应用组合，其实就是要让你明确分明本人当初所领有的是哪个部件。如果部件过于多，其实实现组合最终成品这个步骤，就会有较高的心智累赘，每个部件开展来，目不暇接，目迷五色。比方 QT 这个通用 UI 框架，看它的 Class 列表，有 1000 多个。如果不必继承树把它组织起来，平铺开展，组合出一个页面，将会变得心智累赘高到无奈接受。OOP 在’须要有数元素同时展示进去’这种复杂度极高的场景，无效的管制了复杂度。’ 那么，古尔丹，代价是什么呢？’ 代价就是，一开始做出这个自上而下的设计，牵一发而动全身，每次调整都变得异样艰难。
理论我的项目中，各种职业级别不同的同学一起合作批改一个 server 的代码，就会呈现，职级低的同学改哪里都改不对，基本没能力进行批改，高级别的同学能批改对，也不违心大规模批改，整个我的项目变得愈发不合理。对整个继承树没有齐全意识的同学都没有资格进行任何一个对继承树有调整的批改，合作变得举步维艰。代码的批改，都变成了依赖一个高级架构师高强度监控继承体系的变动，低级别同学们束手束脚的后果。组合，就很好的解决了这个问题，把问题一直细分，每个同学都能够很好地攻克本人须要攻克的点，实现一个 package。产品逻辑代码，只须要去组合各个 package，就能达到成果。
这是 golang 规范库里 http request 的定义，它就是 Http 申请所有个性汇合进去的后果。其中通用 / 异变 / 多种实现的局部，通过 duck interface 形象，比方 Body io.ReadCloser。你想晓得哪些细节，就从组合成 request 的部件动手，要批改，只须要批改对应部件。[这段代码后，比照.NET 的 HTTP 基于 OOP 的形象]
// A Request represents an HTTP request received by a server
// or to be sent by a client.
//
// The field semantics differ slightly between client and server
// usage. In addition to the notes on the fields below, see the
// documentation for Request.Write and RoundTripper.
type Request struct {// Method specifies the HTTP method (GET, POST, PUT, etc.).
// For client requests, an empty string means GET.
//
// Go's HTTP client does not support sending a request with
// the CONNECT method. See the documentation on Transport for
// details.
Method string
// URL specifies either the URI being requested (for server
// requests) or the URL to access (for client requests).
//
// For server requests, the URL is parsed from the URI
// supplied on the Request-Line as stored in RequestURI. For
// most requests, fields other than Path and RawQuery will be
// empty. (See RFC 7230, Section 5.3)
//
// For client requests, the URL's Host specifies the server to
// connect to, while the Request's Host field optionally
// specifies the Host header value to send in the HTTP
// request.
URL *url.URL
// The protocol version for incoming server requests.
//
// For client requests, these fields are ignored. The HTTP
// client code always uses either HTTP/1.1 or HTTP/2.
// See the docs on Transport for details.
Proto string // "HTTP/1.0"
ProtoMajor int // 1
ProtoMinor int // 0
// Header contains the request header fields either received
// by the server or to be sent by the client.
//
// If a server received a request with header lines,
//
// Host: example.com
// accept-encoding: gzip, deflate
// Accept-Language: en-us
// fOO: Bar
// foo: two
//
// then
//
// Header = map[string][]string{// "Accept-Encoding": {"gzip, deflate"},
// "Accept-Language": {"en-us"},
// "Foo": {"Bar", "two"},
// }
//
// For incoming requests, the Host header is promoted to the
// Request.Host field and removed from the Header map.
//
// HTTP defines that header names are case-insensitive. The
// request parser implements this by using CanonicalHeaderKey,
// making the first character and any characters following a
// hyphen uppercase and the rest lowercase.
//
// For client requests, certain headers such as Content-Length
// and Connection are automatically written when needed and
// values in Header may be ignored. See the documentation
// for the Request.Write method.
Header Header
// Body is the request's body.
//
// For client requests, a nil body means the request has no
// body, such as a GET request. The HTTP Client's Transport
// is responsible for calling the Close method.
//
// For server requests, the Request Body is always non-nil
// but will return EOF immediately when no body is present.
// The Server will close the request body. The ServeHTTP
// Handler does not need to.
Body io.ReadCloser
// GetBody defines an optional func to return a new copy of
// Body. It is used for client requests when a redirect requires
// reading the body more than once. Use of GetBody still
// requires setting Body.
//
// For server requests, it is unused.
GetBody func() (io.ReadCloser, error)
// ContentLength records the length of the associated content.
// The value -1 indicates that the length is unknown.
// Values >= 0 indicate that the given number of bytes may
// be read from Body.
//
// For client requests, a value of 0 with a non-nil Body is
// also treated as unknown.
ContentLength int64
// TransferEncoding lists the transfer encodings from outermost to
// innermost. An empty list denotes the "identity" encoding.
// TransferEncoding can usually be ignored; chunked encoding is
// automatically added and removed as necessary when sending and
// receiving requests.
TransferEncoding []string
// Close indicates whether to close the connection after
// replying to this request (for servers) or after sending this
// request and reading its response (for clients).
//
// For server requests, the HTTP server handles this automatically
// and this field is not needed by Handlers.
//
// For client requests, setting this field prevents re-use of
// TCP connections between requests to the same hosts, as if
// Transport.DisableKeepAlives were set.
Close bool
// For server requests, Host specifies the host on which the
// URL is sought. For HTTP/1 (per RFC 7230, section 5.4), this
// is either the value of the "Host" header or the host name
// given in the URL itself. For HTTP/2, it is the value of the
// ":authority" pseudo-header field.
// It may be of the form "host:port". For international domain
// names, Host may be in Punycode or Unicode form. Use
// golang.org/x/net/idna to convert it to either format if
// needed.
// To prevent DNS rebinding attacks, server Handlers should
// validate that the Host header has a value for which the
// Handler considers itself authoritative. The included
// ServeMux supports patterns registered to particular host
// names and thus protects its registered Handlers.
//
// For client requests, Host optionally overrides the Host
// header to send. If empty, the Request.Write method uses
// the value of URL.Host. Host may contain an international
// domain name.
Host string
// Form contains the parsed form data, including both the URL
// field's query parameters and the PATCH, POST, or PUT form data.
// This field is only available after ParseForm is called.
// The HTTP client ignores Form and uses Body instead.
Form url.Values
// PostForm contains the parsed form data from PATCH, POST
// or PUT body parameters.
//
// This field is only available after ParseForm is called.
// The HTTP client ignores PostForm and uses Body instead.
PostForm url.Values
// MultipartForm is the parsed multipart form, including file uploads.
// This field is only available after ParseMultipartForm is called.
// The HTTP client ignores MultipartForm and uses Body instead.
MultipartForm *multipart.Form
// Trailer specifies additional headers that are sent after the request
// body.
//
// For server requests, the Trailer map initially contains only the
// trailer keys, with nil values. (The client declares which trailers it
// will later send.) While the handler is reading from Body, it must
// not reference Trailer. After reading from Body returns EOF, Trailer
// can be read again and will contain non-nil values, if they were sent
// by the client.
//
// For client requests, Trailer must be initialized to a map containing
// the trailer keys to later send. The values may be nil or their final
// values. The ContentLength must be 0 or -1, to send a chunked request.
// After the HTTP request is sent the map values can be updated while
// the request body is read. Once the body returns EOF, the caller must
// not mutate Trailer.
//
// Few HTTP clients, servers, or proxies support HTTP trailers.
Trailer Header
// RemoteAddr allows HTTP servers and other software to record
// the network address that sent the request, usually for
// logging. This field is not filled in by ReadRequest and
// has no defined format. The HTTP server in this package
// sets RemoteAddr to an "IP:port" address before invoking a
// handler.
// This field is ignored by the HTTP client.
RemoteAddr string
// RequestURI is the unmodified request-target of the
// Request-Line (RFC 7230, Section 3.1.1) as sent by the client
// to a server. Usually the URL field should be used instead.
// It is an error to set this field in an HTTP client request.
RequestURI string
// TLS allows HTTP servers and other software to record
// information about the TLS connection on which the request
// was received. This field is not filled in by ReadRequest.
// The HTTP server in this package sets the field for
// TLS-enabled connections before invoking a handler;
// otherwise it leaves the field nil.
// This field is ignored by the HTTP client.
TLS *tls.ConnectionState
// Cancel is an optional channel whose closure indicates that the client
// request should be regarded as canceled. Not all implementations of
// RoundTripper may support Cancel.
//
// For server requests, this field is not applicable.
//
// Deprecated: Set the Request's context with NewRequestWithContext
// instead. If a Request's Cancel field and context are both
// set, it is undefined whether Cancel is respected.
Cancel <-chan struct{}
// Response is the redirect response which caused this request
// to be created. This field is only populated during client
// redirects.
Response *Response
// ctx is either the client or server context. It should only
// be modified via copying the whole Request using WithContext.
// It is unexported to prevent people from using Context wrong
// and mutating the contexts held by callers of the same request.
ctx context.Context
} 看看.NET 里对于 web 服务的形象，仅仅看到末端，不去看残缺个继承树的残缺图景，我根本无法晓得我关怀的某个细节在什么地位。进而，我要往整个 http 服务体系里批改任何性能，都无奈抛开对整体残缺设计的了解和相熟，还极容易没有知觉地破坏者整体的设计。
说到组合，还有一个关系很严密的词，叫插件化。大家都用 vscode 用得很开心，它比 visual studio 胜利在哪里？如果 vscode 通过增加一堆插件达到 visual studio 具备的能力，那么它将变成另一个和 visual studio 差不多的货色，叫做 vs studio 吧。大家应该发现问题了，咱们很多时候其实并不需要 visual studio 的大多数性能，而且心愿灵便定制化一些比拟小众的能力，用一些小众的插件。甚至，咱们心愿抉择不同实现的同类型插件。这就是组合的力量，各种不同的组合，它简略，却又满足了各种需要，灵便多变，要实现一个插件，不须要当时把握一个宏大的体系。体现在代码上，也是一样的情理。至多后端开发畛域，组合，比 OOP，’ 香’很多。
准则 6 悭吝准则: 除非确无它法, 不要编写宏大的程序
可能有些同学会感觉，把程序写得宏大一些才好拿得出手去评 T11、T12。leader 们一看评审计划就容易感觉：很大，很好，很全面。然而，咱们真的须要写这么大的程序么？
我又要说了 ” 那么，古尔丹，代价是什么呢？”。代价是代码越多，越难保护，难调整。C 语言之父 Ken Thompson 说 ” 删除一行代码，给我带来的成就感要比增加一行要大 ”。咱们对于代码，要悭吝。能把零碎做小，就不要做大。腾讯不乏 200w+ 行的客户端，很大，很牛。然而，同学们自问，当初还调整得动架构么。手 Q 的同学们，看看本人代码，已经叹气过么。能小做的事件就小做，寻求通用化，通过 duck interface(甚至多过程，用于隔离能力的多线程)把模块、能力隔离开，时刻想着删减代码量，能力放弃代码的可维护性和面对将来的需要、架构，调整本身的生机。客户端代码，UI 渲染模块能够简单吊炸天，非 UI 局部应该谋求最简略，能力接口化，可替换、重组合能力强。
落地到大家的代码，review 时，就应该最关注外围 struct 定义，构建起一个齐备的模型，外围 interface，明确形象 model 对外部的依赖，明确形象 model 对外提供的能力。其余代码，就是要用最简略、平平无奇的代码实现模型外部细节。
准则 7 透明性准则: 设计要可见，以便审查和调试
首先，定义一下，什么是透明性和可显性。
“ 如果没有明朗的角落和暗藏的深度，软件系统就是通明的。透明性是一种被动的品质。如果实际上能预测到程序行为的全副或大部分状况，并能建设简略的心理模型，这个程序就是通明的，因为能够看透机器到底在干什么。
如果软件系统所蕴含的性能是为了帮忙人们对软件建设正确的’做什么、怎么做’的心理模型而设计，这个软件系统就是可显的。因而，举例来说，对用户而言，良好的文档有助于进步可显性；对程序员而言，良好的变量和函数名有助于进步可显性。可显性是一种被动品质。在软件中要达到这一点，仅仅做到不艰涩是不够的，还必须要尽力做到有帮忙。”
咱们要写好程序，缩小 bug，就要加强本人对代码的控制力。你始终做到，了解本人调用的函数 / 复用的代码大略是怎么实现的。不然，你可能就会在单线程状态机的 server 里调用有 IO 阻塞的函数，让本人的 server 吞吐量间接掉到底。进而，为了保障大家能对本人代码能做到有控制力，所有人写的函数，就必须具备很高的透明性。而不是写一些看了一阵看不明确的函数 / 代码，后果被迫应用你代码的人，间接放弃了对掌控力的追取，甚至放弃复用你的代码，重整旗鼓，走向了’制作反复代码’的深渊。
透明性其实绝对容易做到的，大家无意识地锤炼一两个月，就能做得很好。可显性就不容易了。有一个景象是，你写的每一个函数都不超过 80 行，每一行我都能看懂，然而你层层调用，很多函数调用，组合起来怎么就实现了某个性能，看两遍，还是看不懂。第三遍可能能力大略看懂。大略看懂了，但太简单，很难在大脑里构建起你实现这个性能的整体流程。后果就是，阅读者基本做不到对你的代码有好的掌控力。
可显性的规范很简略，大家看一段代码，懂不懂，一下就明确了。然而，如何做好可显性？那就是要谋求正当的函数分组，正当的函数上下级档次，同一档次的代码才会呈现在同一个函数里，谋求通俗易懂的函数分组分层形式，是通往可显性的路线。
当然，简单如 linux 操作系统，office 文档，问题自身就很简单，拆解、分层、组合得再正当，都难建设心理模型。这个时候，就须要齐备的文档了。齐备的文档还须要呈现在离代码最近的中央，让人’晓得这里简单的逻辑有文档’，而不是其实文档，然而阅读者不晓得。再看看下面 golang 规范库里的 http.Request，感触到它在可显性上的致力了么？对，就去学它。
准则 10 艰深准则: 接口设计防止别树一帜
设计程序过于别树一帜的话，可能会晋升他人了解的难度。
个别，咱们这么定义一个’点’，应用 x 示意横坐标，用 y 示意纵坐标：
type Point struct {
X float64
Y float64
} 你就是要不同、精准：
type Point struct {
VerticalOrdinate float64
HorizontalOrdinate float64
} 很好，你用词很精准，个别人还批驳不了你。然而，少数人读你的 VerticalOrdinate 就是没有读 X 了解来得快，来得容易懂、不便。你是在刻意制作合作老本。
下面的例子常见，但还不是最小立异准则最想阐明的问题。想想一下，一个程序里，你把用’+‘这个符号示意数组增加元素，而不是数学’加’，‘result := 1+2’–> ‘result = []int{1, 2}‘而不是’result=3’，那么，你这个别树一帜，对程序的破坏性，几乎无奈设想。“最小立异准则的另一面是防止表象想死而理论却略有不同。这会极其危险，因为表象类似往往导致人们产生谬误的假设。所以最好让不同事物有显著区别，而不要看起来简直截然不同。”– Henry Spencer。
你实现一个 db.Add()函数却做着 db.AddOrUpdate()的操作，有人应用了你的接口，谬误地把数据笼罩了。
准则 11 沉默准则: 如果一个程序没什么好说的，就缄默
这个准则，应该是大家最常常毁坏的准则之一。一段简短的代码里插入了各种’log(“cmd xxx enter”)’,‘log(“req data ” + req.String())’，十分胆怯本人信息打印得不够。胆怯本人不晓得程序执行胜利了，总要最初’log(“success”)’。然而，我问一下大家，你们真的急躁看过他人写的代码打的一堆日志么？不是本人须要哪个，就在一堆日志里，再打印一个日志进去一个带有非凡标记的日志’log(“this_is_my_log_”+ xxxxx)’？后果，第一个作者打印的日志，在代码交接给其他人或者在跟他人合作的时候，这个日志基本没有价值，反而晋升了大家看日志的难度。
一个服务一跑起来，就疯狂打日志，申请解决失常也打一堆日志。滚滚而来的日志，把谬误日志吞没在外面。谬误日志失去了成果，简略地 tail 查看日志，目迷五色，看不出任何问题，这不就成了’为了捕捉问题’而让本人’根本无法捕捉问题’了么？
沉默是金。除了简略的 stat log，如果你的程序’发声’了，那么它抛出的信息就肯定要无效！打印一个 log(‘process fail’)也是毫无价值，到底什么 fail 了？是哪个用户带着什么参数在哪个环节怎么 fail 了？如果发声，就要把必要信息给全。不然就是不发声，示意本人好好地 work 着呢。不发声就是最好的音讯，当初我的 work 一切正常！
“ 设计良好的程序将用户的注意力视为无限的贵重资源，只有在必要时才要求应用。” 程序员本人的主力，也是贵重的资源！只有有必要的时候，日志才跑来揭示程序员’我有问题，来看看’，而且，必须要给到足够的信息，让一把讲明确当初产生了什么。而不是程序员还须要很多辅助伎俩来搞明确到底产生了什么。
每当我公布程序，我抽查一个机器，看它的日志。发现只有每分钟内部接入、外部 rpc 的个数 / 延时散布日志的时候，我就情绪很愉悦。我晓得，这一分钟，它的成功率又是 100%，没任何问题！
准则 12 补救准则: 出现异常时，马上退出并给出足够错误信息
其实这个问题很简略，如果出现异常，异样并不会因为咱们尝试覆盖它，它就不存在了。所以，程序谬误和逻辑谬误要严格辨别看待。这是一个态度问题。
‘异样是互联网服务器的常态’。逻辑谬误通过 metrics 统计，咱们做好告警剖析。对于程序谬误，咱们就必须要严格做到在问题最早呈现的地位就把必要的信息收集起来，高调地告知开发和维护者’我出现异常了，请立刻修复我!’。能够是间接就没有被捕捉的 panic 了。也能够在一个最上层的地位对立做好 recover 机制，然而在 recover 的时候肯定要能取得精确异样地位的精确异样信息。不能有两头 catch 机制，catch 之后失落很多信息再往上传递。
很多 Java 开发的同学，不辨别程序谬误和逻辑谬误，要么都很宽容，要么都很严格，对代码的可维护性是毁灭性的毁坏。” 我的程序没有程序谬误，如果有，我过后就解决了。” 只有这样，能力放弃程序代码品质的绝对稳固，在火苗呈现时点燃火灾是最好的点燃火灾的形式。当然，更无效的形式是全面自动化测试的预防：）
具体实际点
后面提了好多思考方向的问题。大的准则问题和方向。我这里，再来给大家简略列举几个细节执行点吧。毕竟，大家要上手，是从执行开始，而后才是总结思考，能把我的思考形式抄过去。上面是针对 golang 语言的，其余语言略有不同。以及，我一时也想不全我所执行的 所有细则，这就是我强调’准则’的重要性，准则是可枚举的。
- 对于代码格局标准，100% 严格执行，重大容不得一点沙。
- 文件绝不能超过 800 行，超过，肯定要思考怎么拆文件。工程思维，就在于拆文件的时候积攒。
- 函数对决不能超过 80 行，超过，肯定要思考怎么拆函数，思考函数分组，档次。工程思维，就在于拆文件的时候积攒。
- 代码嵌套档次不能超过 4 层，超过了就得改。多想想能不能 early return。工程思维，就在于拆文件的时候积攒。
if !needContinue {doA()
return
} else {doB()
return
}
if !needContinue {doA()
return
}
doB()
return 上面这个就是 early return，把两端代码从逻辑上解耦了。
从目录、package、文件、struct、function 一层层下来，信息肯定不能呈现冗余。比方 file.FileProperty 这种定义。只有每个’定语’只呈现在一个地位，才为’做好逻辑、定义分组 / 分层’提供了可能性。
多用多级目录来组织代码所承载的信息，即便某一些两头目录只有一个子目录。
随着代码的扩大，老的代码违反了一些设计准则，应该立刻原地部分重构，维持住代码品质不滑坡。比方: 拆文件；拆函数；用 Session 来保留一个简单的流程型函数的所有信息；从新调整目录构造。
基于上一点思考，咱们应该尽量让我的项目的代码有肯定的组织、档次关系。我集体的以后实际是除了特地通用的代码，都放在一个 git 里。特地通用、批改少的代码，逐步独立出 git，作为子 git 连贯到以后我的项目 git，让 goland 的 Refactor 个性、各种 Refactor 工具能帮忙咱们疾速、平安部分重构。
本人的我的项目代码，应该有一个内生的层级和逻辑关系。flat 平铺开展是十分不利于代码复用的。怎么复用、怎么组织复用，必定会变成’人生难题’。T4-T7 的同学基本无力解决这种难题。
如果被 review 的代码尽管简短，然而你看了一眼却发现不咋懂，那就肯定有问题。本人看不出来，就找高级别的同学交换。这是你和别 review 代码的同学成长的时刻。
日志要少打。要打日志就要把要害索引信息带上。必要的日志必须打。
有疑难就立刻问，不要怕问错。让代码作者给出解释。不要怕问出极低问题。
不要说’倡议’，提问题，就是刚，你 pk 不过我，就得改！
请踊跃应用 trpc。总是要和老板站在一起！只有和老板达成的对于代码品质建设的共识，能力在团队里更好地做好代码品质建设。
毁灭反复！毁灭反复！毁灭反复！
骨干开发
最初，我来为’骨干开发’多说一句话。情理很简略，只有每次被 review 代码不到 500 行，reviewer 能力疾速地看完，而且简直不会看漏。超过 500 行，reviewer 就不能认真看，只能大略浏览了。而且，让你调整 500 行代码内的逻辑比调整 3000 行甚至更多的代码，容易很多，升高不仅仅是 6 倍，而是一到两个数量级。有问题，在刚呈现的时候就调整了，不会给被 revew 的人带来大的批改累赘。
对于 CI(continuous integration)，还有很多好的材料和书籍，大家应该及时去学习学习。
《unix 编程艺术》
倡议大家把这本书找进去读一读。特地是，T7 及更高级别的同学。你们曾经积攒了大量的代码实际，亟需对’工程性’做思考总结。很多工程方法论都过期了，这本书的内容，是例外中的例外。它所表白出的内容没有因为软件技术的一直更替而过期。
佛教禅宗讲’不立文字’(不立文字，教外别传，直指人心，见性成佛)，很多情理和感悟是不能用文字传播的，文字的表达能力，不能表白。大家经常因为 ” 本人据说过、晓得某个情理 ” 而产生一种安心感，认为 ” 我懂了这个情理 ”，然而本人却不能在实践中做到。知易行难，晓得却做不到，在工程实际里，就和’不懂这个情理’没有任何区别了。
已经，我面试过一个别的公司的总监，讲得如同一套一套，代码拉进去遛一遛，基本就没做到，仅仅会一人传虚; 万人传实。他在工程实际上的摸索前路能够说曾经根本断绝了。我只能祝君能做好向上治理，走本人的纯治理路线吧。请不要再说本人对技术有谋求，是个技术人了！
所以，大家不仅仅是看看我这篇文章，而是在实践中去一直践行和积攒本人的’教外别传’吧。
起源：腾讯技术工程
欢送关注我的微信公众号「码农解围」，分享 Python、Java、大数据、机器学习、人工智能等技术，关注码农技术晋升•职场解围•思维跃迁，20 万 + 码农成长充电第一站，陪有幻想的你一起成长
