如何做好软件的思考

如何做好软件这个问题太大，全面讨论可能需要很长时间。个人如何做好软件和公司如何做好软件，在难度上和方法上可能完全不同，本着思考胜于执行的原则，我近期对如何做好软件做了一些思考和总结，本篇侧重于讨论公司而非个人如何做好软件。

# 什么是好软件

彼得大师说：“没有度量，便没有管理”。在讨论如何做好软件之前，我们不妨先谈谈什么是好的软件？或者更聚焦一点，什么是好的代码？

坦白说，软件质量度量是一个业界难题，质量度量相关的学术文章超过1000篇，度量项高达200+，比较著名的有McCabe的圈复杂度，但时至今日，依然没有公认的软件质量评估的好方法。

## 基于形式的黑盒化度量

我们当然可以通过代码扫描，通过设置门禁，去看护质量，去统计数据，这是一种显式的度量，这些很有必要也很有效，但是它只是机械行事，捕捉破坏规则的代码。

基于形式的度量，虽有自动化成本低等优点，但过于死板，可能代码完全符合规范，但质量依然很差。所以，相比统计指标的评估，我们更需要基于内容的评估，因为软件的灵魂是设计，是内容而非形式。

## 基于内容的白盒化评估

Robert C.Martin提出一个评估质量的公式：WTF/min，他认为这是衡量代码质量的唯一有效标准。直白翻译过来就是Review代码的时候每分钟说握草的次数，配上那张Good Code/Bad Code的趣图，画面感十足。

WTF/min自然有点玩笑话的意味，但它其实提出了一个观点，即只有白盒化评估才能真正反映软件质量，这也就是我们经常讲的软件质量要讲良心。

基于内容的白盒化评估需要肉眼评审，很难自动化，效率低、操作难，但它的效果很好，实操中，建议采用黑盒+白盒的组合方式，避免质量评估僵化教条，流于形式。

# 影响软件质量的因素

我们假定整洁、高效、可读、可靠、可扩展、可维护的软件为好软件，基于此，讨论影响软件质量的因素。

按哲学理论，事物都分内因和外因。软件质量的内因被研究得比较多，比如设计、开发、测试等；软件质量的外因，比如文化，氛围，管理等却往往被忽视，其实这些才是影响公司软件质量的主因。

## 好软件关键靠人

首先，软件实施的关键要素是人。对于公司而言，首先要考虑的是，如何把软件高手吸引进来？

### 招聘，是提升软件质量至关重要的一环

吸引人的，无非钱和事，待遇好+事情有价值，这两点，大公司都能满足。

但顶尖软件人才不仅看钱和事，他们对文化氛围等软环境比较挑剔，公司不能因为对方挑剔就主动放弃金字塔尖的宝贵人才，而是应该千方百计把他们吸引过来，为他们创造条件，让他们以最佳姿势工作，发挥最大价值潜能。

### 坚持选拔制

显然，我们不能把想进公司的人都招进来，公司创业初期，受限于客观条件，招的人并非都是高手，寄希望于平凡人做非凡事，这能够理解。

但如果公司发展壮大，要引领潮流，需要提高门槛，加大对软件能力的考核力度，把真正优秀的开发人员甄别出来，选拔进来，并委以重任。

入职后再培养的成本太高了，培养人不是公司的主要职责。把一个不适合搞程序的人培养成软件高手，太难了，公司费力，员工别扭，效果不好，不值当。

所以，选拔比培养重要、有效，要坚持选拔制，许多公司面试环节很多轮考试做题，但如果面试环节松，招进来之后考证，这样其实成本很高。我主张考试认证前置，而非放到入职后，根本原因是考试跟实践有Gap，考试更适合筛选而非工作。

招聘环节更严，会有一个伤害，那就是会影响招聘进度或数量，但它同时有一个好处，那就是提高招聘质量，进而提高软件质量。

软件领域有一个八倍定律，即1个高手的战斗力相当于8个菜鸟，这丝毫不是什么夸张。

而且，如果一个人过五关斩六将面七轮进来之后，他会特别珍惜进入公司的工作机会，不容易流失。

## 营造基于信任的工程师文化

我们通常讲零信任设计和面向失败编程，但在技术文化上，这样可能并不一定合适。

我更赞同：信任并核查。

即经评估给员工一个初始信任值（比如100），犯错扣分，做对加分，分数越高自由越大，分数越低越约束越多，而不是假设每个人都是傻子，用最傻的那个人的标准要求所有人，这会让正常人觉得智商受到了某种程度的侮辱。

这样的处理方式甚至可以泛化，比如有公司把信任积分制用在报销管理，效果挺不错。

有时候某员工的一个代码错误，被泛化，被放大，然后被拿来限制根本不可能犯这种错误的软件老手，任性的增加各种条条框框，这样既不科学，也不人道，除了换来一点点心理安慰，并不起什么作用，但副作用却不容小觑。

我们要警惕这种情况。

可能很多人会觉得基于防范更好，似乎它更安全，但我觉得更多可能是惯性所致，全面转向可能不现实，但局部改变或许是值得尝试的，退一万步讲，讨论一下终究是有必要的。

## 重新审视安全与效率

人们常说：安全是红线，安全是木桶的底板，安全是0前面的1，我们听到太多安全生产重要性的言论，以至于，在我们脑海里安全成了一个谁碰谁死的确定问题，在这个问题上，我们甚至失去了独立思考的能力。

开车的安全性肯定低于走路，但为什么国家不禁止机动车？

安全跟效率，是一个此消彼长的关系，需要找平衡点，但实际情况是，我们经常过于强调安全而忽视对开发效率的影响，因为拿安全说事有点政治正确的味道，总容易碰触人敏感的神经，但仔细想来，好像并不是那么回事。

我曾经就安全与效率的问题请教过微信的技术主管，他经常因为故障被通报批评，但微信在安全与效率之间，宁愿牺牲一点安全性换取效率，尤其警惕借安全之名行损伤效率之实，不光微信这样，整个腾讯都如此，因为他们算过账，认为敏捷带来的好处要远大于故障带来的损伤。

阿里是另一个极端，对安全的强调无以复加，对故障的处罚令人窒息，以淘宝为例，每年6.18，双11，双12，春节，妇女节，两会等都要封版，可以提交新特征的时间窗口很小，迭代很慢，出了错，从上撸到下，领导如履薄冰，员工噤若寒蝉，大家都不敢动，这样到底好不好？相比微信的做法谁更好？说实话，我觉悟不够，我不知道。

不同行业对质量和效率的要求不一样，同处互联网行业的腾讯和阿里也有截然不同的做法。

### 分级，不搞一刀切

其实软件的很多方面，都可以考虑分级制度，不要搞一刀切。

不同业务有不同要求，所以最好的方法，就是分级，一切从实际出发，具体情况具体分析，不搞一刀切，一刀切是粗暴管理，是权力任性。

我们知道，多线程编程，数据竞争，要加锁，加大锁很爽很容易，但大锁往往影响效率，我们要合理设计锁的粒度，管理同此理，需要精细化。

这意味着，我们需要回归初心，回到问题的本质。软件所处的行业不同，对故障的容忍度不同。所以，应该为不同业务或者产品线制定不同的安全编码规范，而不是一上来就对语言做阉割（比如我们禁C++用异常，禁很多系统调用），少干些束人手脚的事情。

### 容许犯错、非责罚性复盘

容许犯错绝不是纵容放错，先撇清这个关系。

要容许犯错，提倡非责罚性复盘。

软件开发是精细生产，很难杜绝犯错，我们已经有很多制度规范去避免犯错，以及容错机制去纠正错误和控制故障影响，所以，我们讨论的是在严防死守下对待出错的政策。

很多公司都有复盘机制，复盘的出发点和归依应该总结经验教训，似乎为了之后把事情做得更好，但如果对错误责罚过度，很容易出现大家都不敢动的情况，不动固然能减少出错，但也影响迭代，相比故障带来的损伤，往往迭代迟缓更可怕，因为业务速度降下来，往往是致命的。

## 拥抱开源

优秀的开源项目是技术的宝库，汇集了软件领域的顶级认知和智慧，研究它、学习它对开阔技术视野和提升软件能力大有助益。

开源意味着项目有更多人参与，意味着更大范围博采众长，汇聚更多的奇思妙想，这样才能产生更强大的结果，因为开源代码接受社区全面彻底的检视，所以往往能获得更高的可靠性和安全性。

资浅的程序员容易被带偏，为什么会被带偏？本质上是资浅员工缺乏辨识力。为什么缺乏辨识力？可能是因为他没有见过更好的项目实践。

因为信息传递过程中必然会存在部分失真，假如老员工的代码是80分，如果新员工只是跟着老员工的写法依葫芦画瓢，写出来的代码可能就只有60分，再传承一两代，可能就不及格了。

只学习项目中老员工的写法，天花板就是老员工的技术水平，而参考借鉴优秀开源项目，天花板就是业界顶尖实践，天花板不一样，结果自然也不一样，所以，应尽可能把天花板拔高，这也是显而易见的道理。

但当前政治和商业环境下，大部分开源社区或基金会都或多或少受美国控制，在这样的情况下，大家借鉴或者使用开源技术需要充分评估。

## 兼容并包

要鼓励员工提出问题，我们经常会说提问题简单，重要的是解决问题，这话没毛病，但也不完全对，因为解决问题需要资源，提出问题的不一定有资源。提出问题有时候也很重要，比如数学上提出那些XX猜想的比证明的往往更重要。

我们不能苛求提出的问题完美无缺，只要讨论自由，哪怕说的不对，大家有思辨力，影响也不会太大，如果讨论不自由，再正确的真理，也会歪曲。

软件开发工作是一种纯脑力劳动，开发者的思想至关重要。每个人的想法都会不同，所以软件开发是很个性化的工作。有时候我们容易陷入“集团军作战”的诱惑，觉得只要堆人上去，事情就能干成。但是在软件开发领域，这不是绝对的。常见那种一个**灵魂人物独挑大梁**，质量数量都很优秀。

如果有这样的优秀人员出现，就应该吸纳他的优点，不要求他与别人保持一致。发挥他的长处，鼓励并尊重他的劳动，而不是磨灭他的热情。

如果没有这样的人员，组织内的员工更喜欢团队协作，那也没有任何问题，大家一起分工合作，彼此支援，鼓励互相支撑互相学习，也能很好地完成软件的开发。

组织应该有足够的灵活性和弹性，来容许各种性格和习惯的开发人员（当然道德败坏或者违反公司规定就不在此列了），兼容并包，海纳百川，有容乃大，才是组织应该追求的目标。

## 技术管理

软件开发过程最重要的因素是人，但软件开发过程也是一种生产过程，软件开发的结果必然是软件产品的交付，不然就没有意义了。所以对软件开发的管理，意味着将对人的管理，对软件质量的管理，和对开发过程管理进行调和，获取高质量的软件交付，可持续的软件生命，以及软件开发人员的成长和可持续性。

对开发人员的管理和评价，很自然就会用交付的代码来衡量这个开发人员的好坏。这是大方向，但是，是不是一个人写的代码特别多，加班时间特别长，他就是个很好的程序员呢？其实，在软件领域，如果同样的功能，能把代码写得更简洁更清晰，代码量更少，同时交付更快捷有效的程序员，才是更好的。抛弃以代码量和加班时间来衡量程序员，而是以做事的效率和成品的质量来衡量，才是软件企业对开发人员管理的基础。

对软件质量的衡量，也不应该仅限于转测后问题单的多少。鼓励开发人员进行自测，尤其是可重复可追溯的自动化测试，能有效地加深开发人员自身对需求和功能实现的深刻理解。如果交付周期过短，开发人员无法兼顾实现和测试case的编码，在没有测试或者极少测试的情况下仓促上线，那么就会积累这些质量债务，时间一久，代码的质量会越来越陷入恶性循环。

对软件开发过程的管理，公司有很多流程，很多要求要遵守。有时候一些流程非常繁琐，对项目带来的好处也有限，那么项目的管理者，应该有权限或者途经，对流程进行探讨，定制一个符合自己项目的流程，满足公司定义的标准，也不会伤害自己的开发效率。

# 小结

如果技术团队的管理者，不关注技术，不关心代码，而是聚焦于向上管理，我想无论再多的政策也是徒劳，因为其实员工都很聪明，一旦他发现做其他事情远比认真搞技术更有前途，他便会毫不犹豫的丢掉代码，上有所好，下必甚焉，所以，做好软件，请从管理者开始，至少，管理者应该在团队群里参与技术的讨论，或者给老炮们的犀利观点点个赞，您说呢？

高并发软件系统的密码