分享这篇耗子叔的-《请玉伯一起来聊一聊“所向无敌的土方法”》

点击上方蓝色字体，选择“设为星标”

优质文章，及时送达

闲来无事逛知乎，逛到了这一篇当年耗子叔和玉伯的论战，详情如下，后面看看我的评论。

---

玉伯对我的《开发团队的效率》（//coolshell.cn/articles/11656.html）一文做了评论，觉得理想化，觉得不接地气，我截图如下。

首先，让我来尝试理解玉伯一下，然后，我会给出当时最实际的案例，我非常好奇玉伯那“所向无敌的土方法”

一、是“常识”还是“理想”

1）我在文中：“一个全格的程序员应该能够掌握多个语言，也能够负责多个模块甚至不同的职责”，玉伯认为这就算“全栈了”？这就算“牛人了”？玉伯，你是这么理解的么？

2）我认为，正常的工程师需要了解需求，需要做自测，需要了解运维。玉伯认为这就是“全栈”了？，这就是“牛人”了？这就是一种“理想”，一种“不接地气”么？玉伯是这么理解的么？

3）我在Watchdog一节中说的，解决问题就要解决在根上，不要绕。玉伯认为这么正常的思维方式就是“不接地气”么，就是“理想”么？

4）我在接力棒开发中，说到了，团队能够很好合作的前提是需要有一个比较统一的开发框架或是开发协议，需要把自己当成服务者，而不是对方式的保姆，玉伯认为这么做就是太理想了么？

玉伯，你不觉得我说的这些都不是理想，而就是一种常识么？

二、求“所向无敌的土方法”

我还是给你几个案例吧，我很想知道你那些“所向无敌的土方法”。

声明一下，我本来不想给这些案例的，

但是我想和玉伯辩论一下，是“理想”还是“常识”，

同时，我非常非常想知道——玉伯的“所向无敌土方法”说的究竟是什么？

1）我的文章里提到了这么一篇文章：《阿里云OCS超时问题的分析与解决》//blog.aliyun.com/341，玉伯同学看看，当然，我不确定你能不能看得懂。这篇文章的的内涵是：“阿里云连一个小小的keepalive参数都没有被整体设计过，导致问题，排查起来相当困难”，就是说，这篇文章暴露了阿里云有多Low。想问一下玉伯的土方法是什么（比较讽刺的，这篇文章的最后一段是“这是我们工作中最大的乐趣！”）（在这个案例下，请玉伯说一下你的所向无敌的土方法）

2）我刚到阿里云做VNC的时候，看到做这个事有三个人分别来自三个团队，一个是搞底层的，一个是搞Tengine，一个是搞控制系统的。他们三个人都不了解别人的系统，然后，每个人都站在自己角度给我一个完全不一样的方案。时间估计要做3个月，因为要各种配合，开个会，开发，测试，运维，网络……来一堆人，近20个人，各种扯，我很崩溃。我很难理解这么一个小玩意需要这么多人。于是我和另一个同学，两个人，不到三周就把控制系统、Tengine、控制系统搞完了，还开发了产品不要的OpenAPI，我连前端都做了，要不是前端在重构，代码进不去。（在这个案例下，请玉伯说一下你的所向无敌的土方法）

3）阿里云虚拟机有一些因为控制系统里的状态和实际状态不一致。控制系统认为这是一块新硬盘，但实际是用户在用的，于是用户一个重起就导致我们的控制系统把这块硬盘给格式化了，造成了用户数据丢失。玉伯，如果你找找内网，你还可以看到相关的贴子。就是高层们在大谈各种“意识形态”的东西——什么客户第一啊，什么要和用户坐在一架飞机上，等等。我们在讨论这个问题的时候，主管说，要开发一个巡检系统，实时监控控制系统和实际情况有什么不一样的。我说，我不同意，因为，a)知道了不一样谁是对的呢？b)这并没有解决问题啊。既然状态不一致了，要就找到根本原因为什么不一致，然后彻底解决。（在这个案例下，请玉伯说一下你的所向无敌的土方法）

4）阿里云存储有一次需要开一个新的集群，一个运维的同学在部署这个新集群的时候，把一个现有的生产线上的集群的配置copy到新集群那边修改。但是配置项太多，改漏了一些，导致这个新的集群连接到了正在生产的集群，导致一个重大故障。我们在周例会上review这个案例，主管说，让每个云产品团队都开发一个自己的权限管理系统，不要让什么东西都能被修改。我说我不建议这么做，因为，a) 权限系统并不解决这个问题，另外，带来更多的维护工作，b）要开发也不要每个团队各做各的啊，应该是统一做啊，c)最重要的是，这事应该是自动化部署的问题啊。主管说，反正你早晚要这个权限系统的，另外，以后上线，要两个同学，一个是在操作，另一个在旁边验证操作。我心里直嘀咕：“这事就是人肉运维出的事，加更多的人让其更人肉”？我的确很难理解。（在这个案例下，请玉伯说一下你的所向无敌的土方法）

虽然我有一堆一堆的这样的案例，为了简单起见，我先例这些吧。

---

说说我的想法，首先两位背景不同啊，一个是资深后端架构师，一个是前端开源社区的大牛，虽然都是编码高手技术专家。但是毕竟兵器不同，战场不同势必会影响思维方式，我个人比较认同耗子叔的观点的，为什么呢？首先是因为我也是后端程序员啊。

当然不是无脑的，因为耗子叔在文中也提及到了自己的疑问，可惜玉伯没有继续解答。我支持的另一个角度在于耗子叔多次提到的“这没有解决问题啊”，确实啊，很多可以主事的，有决策权的反而不是那些当事人，只是听一些汇报，邮件，参加了几次例会就用自己多年沉淀下来的“土经验”判断，这个需要加个系统啊，那里需要加个校验啊，增加个框架，来个权限系统啊，这些根本没有解决核心问题，都是意淫出来的一出大戏，属于思维定式和思维惯性。

记得孙玄大牛说过，NB的架构师是把事情越做越简单，SB的架构师把事情越做越复杂，以文中提的例子展开，核心问题是A，结果引入B去解决A，是不是复杂了。正常应该是往A走啊，走到问题的核心啊。

还有最后一点提到的“人肉运维”的情况，我也发现了这个问题，我司的两个我比较喜欢的技术团队复杂人就是两种解决问题的思路，一个是工具控，认为人会犯错，所以搞了一批工具和系统做兜底和控制，严重影响效率，一点不灵活，人的跳跃思维完全被限制了。另一个是SOP控，喜欢建立各种规章制度，SOP，效率没上去，事情却多了。

还是思维方式的问题啊，有问题不怕，解决问题呗，怕的是为了解决问题搞了一个更复杂的工具去解决问题，结果工具成了新的问题中心。