说点题外话03 银弹可以杀死狼人，但你怎么知道狼人不是你呢？
你好，我是徐昊。今天我们再来专门说点题外话。
在软件开发的黑话里，有一颗银色子弹（并不是滚筒洗衣机）可以解决一切问题，而我们一代代软件人，都在苦苦追求它。每当有新技术出现的时候，就会有人问，XXX是不是银弹啊？比如说啊，云计算是不是银弹，DDD是不是银弹，RESTful API是不是银弹，低代码是不是银弹（并不是，这是行业毒瘤）。
然而有意思的是，银弹这个隐喻被引入软件开发领域中的时候，是源自Fred Brooks经典的软件工程论文《没有银弹：软件工程的本质性与附属性工作》（No Silver Bullet—Essence and Accidents of Software Engineering）。
简而言之，Fred Brooks将软件开发中的工作分为本质性工作（Essential Task）和附属性工作（Accidential Task）。所谓本质工作，就是解决本质性困难的工作。而软件的本质性困难就是：如何从抽象性问题发展出具体概念上的解决方案。也就是如何理解我们要解决的问题，并选择恰当的解决方案。
与之相对的则是附属性工作，也就是将寻找到的解决方案，转化为电脑可执行程序的工作。而在这个过程中遇到的困难，就是附属性困难。
Fred Brooks说呢，如果我们把具体的软件开发看成由本质性工作和附属性工作构成的混合形态，只要附属性工作不是占据全部工作的9/10，那么就算我们把附属性工作降到0，也没法获得十倍的效率提升。
也就是说，理解问题并寻找解决方案的本质复杂度难以降低，它一定会占据软件开发中的大部分时间和精力（比如知识消化的“两关联一循环”）。所以哪怕一行代码都不写，我们也没有办法将生产效率提升十倍。
这告诉我们什么呢？当你思考你的职业生涯时，需要考虑一下，你的本质性技能和附属性技能。然后我想你们都懂本质性技能是什么，因为我们已经强调了无数次了，那就是理解问题、定义问题。
我曾经领导过我司一个技术管培生计划，目的是培养十倍效能的Thoughtworker，也叫小巨人计划。考虑到我司员工略高于行业平均水平的效能，当时就有人心怀疑虑，在这个基础之上，怎么还能再提高十倍呢？
其实答案很简单，任何人只要学会工作中的时间管理和人格分裂性多人运动，也就是任务分解和测试驱动开发，都能获得三倍左右的效率提升。而想要再进一步，就需要有更好的定义问题的方法，从本质性任务上寻找突破。这就需要我们能更好地理解业务，并且能够快速地学习领域知识。
前者可以通过学习财务、法务知识入手，并通过四色建模以及后续8X Flow在工作中的强化，后者则需要通过刻意练习，训练对应的胜任力。这其实不难，但难的是转变思路和行为。正所谓易学难精，这是需要你自己多下功夫的，我在这里就不多展开了。
当然，对于Fred Brooks的论断也有一种逆向推理，也就是能不能将附属性工作的比例提高，高到超过9/10呢？然后发现方法竟然惊人地简单：不定义问题、随意归因和迷信复用。
不定义问题就是不问要解决什么问题，按着套路推代码就行了。反正最后落到代码上也不过就是CRUD，那管它到底要CRUD啥呢。于是乎，别说9/10了，百分之百都能变成附属性工作。
随意归因呢，就是不把问题的根源追溯到业务上，寻找到技术上要解决的问题就停止了。我可以理解技术人员对业务领域的诸多陌生与百般不适，然后就在自己擅长的地方停止了。然而事实是，当我们在做业务系统的时候，最终是由业务为我们的软件买单的。那么如果既不能增效，又不能降本，那要我们有何用？难道是因为好看吗？
最后是迷信复用，它还有另一个和银弹很般配的名字，叫金锤。意思是说，我拿了锤子，然后满眼都是钉子，不问是啥就乱砸一气。实际上，这是在打着技术卓越（毕竟在讲复用了）的名义，不定义问题和随意归因。
Fred Brooks论文中之所以用到银弹，是因为只有银弹可以杀死狼人。而狼人呢，是从一般人突然变身为恐怖的怪物。
正如软件项目，看着一切正常，突然就超期了，失控了，事故了。所以盲目追求将附属性工作的比例提高，而忽略本质性工作，这不是银弹，这是狼人的血。结果就是没有杀死狼人，反而自己变成了狼人。
好了，关于银弹就言尽于此吧。在进入下一个题外话之前，希望你能认真思考如下问题。
思考题
我们在旧约部分讲的内容里，既有理念，也有技巧。那么请按你的理解来分析一下，其中哪些帮我们更好地完成了本质性工作，哪些解决了附属性工作呢？
请把你的思考和想法分享在留言区，我会和你交流讨论。同时，也非常期待你能把自己的疑问和想听的话题，写在留言区，或者反馈给专栏编辑。我们下个题外话再见！
- 码农戏码 👍（20） 💬（3）
可怜之人必有可恨之处 我们当前就是100%的投入附属性工作，还在加量加码，甚至整个行业风气都是，别人吹的牛，我们得实现了 业务价值是啥，谁去关心，我们要的就是高并发，高性能，高可用，要24*7，要5个9 能不能达到业务价值不知道，但我知道面试必备，那就得这么实现，看过的理论得套上，听过的中间件得用上 to c行业还好些，至少每人都可能是用户，量级也得确会见到，to b行业就比较突显，不关注领域知识，一味追求技术，三位数的QPS都达不到，架构却要支撑七位数，造成不必要的复杂，交付缓慢，质量下降 老板各种diss技术，花高价招更牛的技术引入更高的复杂性，彰显各自的英明神武 老师课程是要正本清源还本归宗，解决问题前先理解问题，定义问题，不追求模型的完美，而是通过建模迭代试错，知识消化，技术方与业务方达成一致，找出最本质的业务诉求，再找到对应解决方案，这些都是本质工作；再通过各种适当的模式做好附属性工作 每个技术人成长阶段不同，关注重点不同，低段位时重心还是追求实现的术，高段位时得回归业务价值的道，只是在术上走远了，不能忘了出发时的目标 老师你们的小巨人计划可不可以多透露点，让我们也能一个打十个
2021-07-26 - 爱睡觉 👍（7） 💬（1）
很有意思的是，“没有银弹”成为了一种银弹。 那就是面临任何一个不熟悉、不适应的方法，都可以高瞻远瞩的说一句“没有银弹，这个xxx不是万能的”。然后心安理得的继续原本的做法。 没有银弹就成了杀死一切改进建议的银弹
2021-07-25 - Oops! 👍（8） 💬（1）
again, hard to sleep at night. 本课用了很多笔墨讲述两关联一循环的知识消化过程就是用来指导我们更好完成本质工作的。其他各类模式、分层和restful api 等都是解决附属工作中的一些技术性难点。
2021-07-24 - 狩月 👍（4） 💬（2）
所以，低代码是行业毒瘤的原因也是不定义问题，随意归因，和迷信复用吧
2021-07-25 - 马若飞 👍（1） 💬（1）
本质性困难源于业务复杂性。如果业务极其简单，是否可认为银弹存在？
2021-07-27 - 云师兄 👍（0） 💬（1）
再来一波题外话吧。
2021-07-25 - 下弦の月 👍（0） 💬（1）
补充适用于程序员的财务知识，有什么推荐的书籍或者学习套路么？
2021-07-24 - HoshinoKanade 👍（4） 💬（0）
能多說一下漸進增強嗎
2021-07-24 - 陈小虎 👍（2） 💬（0）
看到这里明白为啥专栏感觉没那么长了。。花里胡哨的其实就是天桥卖艺的。。真东西不会太复杂
2021-11-24 - escray 👍（2） 💬（0）
当我发现自己是狼人的时候，就会偷偷把银弹破坏掉。 软件开发中的本质性困难在于，如何发现问题、理解问题，并选择恰当的解决方案。而这个本质性的困难是永远存在的，不会因为人工智能、知识图谱、机器学习、区块链、数据中台、低代码……而变得简单。事实上，因为可选择的技术过多，也许会变的更加困扰。 虽然现在不写代码的，不过还是有机会锻炼自己的 Essential Ability，比如理解问题、定义问题。 我觉的倾听、写作、演讲这三样，虽然算不上核心技能，但是如果掌握的好，也能增色不少。 我自己的时间管理，或者说是任务分解，做得并不好，比如现在已经是我预计睡觉的时间了， 可是还在写日更的文字。 把测试开发称为“人格分裂性多人运动”，这个真是一言难尽，当然我也不太熟练。 前司可能就是在使用“不定义问题、随意归因和迷信复用”的开发方式，作为项目经理的我，主要的职责是文档开发，而不是去需求调研。 对于思考题，我觉得可能“两关联一循环”，以及关联对象、角色对象、上下文对象……这些都集中于学习领域知识，并且理解业务，这些应该有助于完成本质性工作。 而类似于测试驱动、持续集成、重构……这些方法论上的东西应该是有助于附属性工作。
2021-08-15 - 黄骏 👍（1） 💬（0）
老师，银弹那篇论文的链接（http//worrydream.com/refs/Brooks-NoSilverBullet.pdf）打不开， 应该是 http://worrydream.com/refs/Brooks-NoSilverBullet.pdf
2023-10-11 - cober 👍（1） 💬（0）
说的太好了，一语道破天机，现在团队正陷入这些困扰。
2021-08-08 - Geek_1mljez 👍（1） 💬（0）
一针见血！
2021-07-24 - 切糕 👍（1） 💬（0）
搞统一语言和领域建模就是解决本质性问题 具体落地就是后者啦
2021-07-24 - 老敖 👍（0） 💬（0）
感觉徐老对低代码怨念很深，我也一样
2022-12-09