说点题外话03｜银弹可以杀死狼人，但你怎么知道狼人不是你呢？

可怜之人必有可恨之处 我们当前就是100%的投入附属性工作，还在加量加码，甚至整个行业风气都是，别人吹的牛，我们得实现了 业务价值是啥，谁去关心，我们要的就是高并发，高性能，高可用，要24*7，要5个9 能不能达到业务价值不知道，但我知道面试必备，那就得这么实现，看过的理论得套上，听过的中间件得用上 to c行业还好些，至少每人都可能是用户，量级也得确会见到，to b行业就比较突显，不关注领域知识，一味追求技术，三位数的QPS都达不到，架构却要支撑七位数，造成不必要的复杂，交付缓慢，质量下降 老板各种diss技术，花高价招更牛的技术引入更高的复杂性，彰显各自的英明神武 老师课程是要正本清源还本归宗，解决问题前先理解问题，定义问题，不追求模型的完美，而是通过建模迭代试错，知识消化，技术方与业务方达成一致，找出最本质的业务诉求，再找到对应解决方案，这些都是本质工作；再通过各种适当的模式做好附属性工作 每个技术人成长阶段不同，关注重点不同，低段位时重心还是追求实现的术，高段位时得回归业务价值的道，只是在术上走远了，不能忘了出发时的目标 老师你们的小巨人计划可不可以多透露点，让我们也能一个打十个

很有意思的是，“没有银弹”成为了一种银弹。 那就是面临任何一个不熟悉、不适应的方法，都可以高瞻远瞩的说一句“没有银弹，这个xxx不是万能的”。然后心安理得的继续原本的做法。 没有银弹就成了杀死一切改进建议的银弹

again, hard to sleep at night. 本课用了很多笔墨讲述两关联一循环的知识消化过程就是用来指导我们更好完成本质工作的。其他各类模式、分层和restful api 等都是解决附属工作中的一些技术性难点。

所以，低代码是行业毒瘤的原因也是不定义问题，随意归因，和迷信复用吧

本质性困难源于业务复杂性。如果业务极其简单，是否可认为银弹存在？

再来一波题外话吧。

补充适用于程序员的财务知识，有什么推荐的书籍或者学习套路么？

能多說一下漸進增強嗎

看到这里明白为啥专栏感觉没那么长了。。花里胡哨的其实就是天桥卖艺的。。真东西不会太复杂

当我发现自己是狼人的时候，就会偷偷把银弹破坏掉。 软件开发中的本质性困难在于，如何发现问题、理解问题，并选择恰当的解决方案。而这个本质性的困难是永远存在的，不会因为人工智能、知识图谱、机器学习、区块链、数据中台、低代码……而变得简单。事实上，因为可选择的技术过多，也许会变的更加困扰。 虽然现在不写代码的，不过还是有机会锻炼自己的 Essential Ability，比如理解问题、定义问题。 我觉的倾听、写作、演讲这三样，虽然算不上核心技能，但是如果掌握的好，也能增色不少。 我自己的时间管理，或者说是任务分解，做得并不好，比如现在已经是我预计睡觉的时间了， 可是还在写日更的文字。 把测试开发称为“人格分裂性多人运动”，这个真是一言难尽，当然我也不太熟练。 前司可能就是在使用“不定义问题、随意归因和迷信复用”的开发方式，作为项目经理的我，主要的职责是文档开发，而不是去需求调研。 对于思考题，我觉得可能“两关联一循环”，以及关联对象、角色对象、上下文对象……这些都集中于学习领域知识，并且理解业务，这些应该有助于完成本质性工作。 而类似于测试驱动、持续集成、重构……这些方法论上的东西应该是有助于附属性工作。