1、分工的合理性。耗子说分工越细团队越没效率，并没有说到点子上。影响团队效率的，是分工的合理性，而不是粗细。究竟怎样的分工是合理的？不同领域、不同团队，在不同阶段下，合理的分法可能都不同。在支付宝，对于高交互类业务，前后端分开，各司其职是很有必要的。对于可规范的平台类业务来说，让 Java 开发懂一点前端，基于前端提供的服务化方案去独立完成产品研发，则是非常不错的方式。分工的合理性离不开实际场景和团队的人员情况，会有一些规律性，需要在时间的长河中不断去探索、沉淀。
　　2、团队间彼此赋能。是耗子说的团队间的服务化。这一点非常非常赞同，服务化不是我帮你做事，而是让你能做我的事。不过耗子依旧是只说了方向，而没有说打法，是目标，而不是解决方案。在支付宝，为了能让 Java 开发学会更多前端技能，我们的做法是，成立了前端技术学院，与各技术团队负责人一起，筛选出培养目标，通过一系列培训，以及在实际项目中的以战练兵去赋能。同时，也需要在前端类库与框架层面发力，尽可能让前端的技术门槛降低。一方面是通过培训提升人员的能力，一方面是通过技术架构优化降低技术门槛，当能力提升能匹配上技术门槛的降低时，很可能可以真正实现团队间的彼此赋能。真实操作过程中，还有大量大量的细节工作需要去攻破，远比耗子喊喊口号复杂很多。
　　其实这些接地气的解决方案，回过头来想，都很「土」，都是自然而然能想到的方案。但正因为「土」，反而不怎么被很多有远见的牛人待见。因为很多牛人，总想着通过某些取巧的方式去达成目标，我之前也疯狂想过通过各种更快速的方案，比如搞一套类似 Visual Studio 的可视化拖拽方案去给后端团队赋能，但实际操作下来，这样反而会惯坏后端团队，使得后端团队在前端技能的积累上停留于初级阶段。大道至简，返璞归真，越来越觉得，真正能解决问题的，往往都是「土」的方案。
　　耗子说的第二点，接力棒式的软件开发，跟软件开发中的锁本质上是一样的。解法是，一是要找到合理的分工，二是要通过服务化让团队间彼此赋能。
　　耗子说的第三点是保姆式的软件开发，这一点的解法依旧是合理的分工与服务化赋能。耗子解决方案里提到的招聘、以及人多人少的问题，并不是关键。支付宝近一年，在逐步把测试团队取消掉，让开发也懂测试。但无论怎么融合，专业化的质量工具团队与质量架构师依旧是有必要的。这需要大家的专业度都提升，开发需要懂得测试，掌握的技能与责任感需要更多，同时测试发展空间也被打开了，不再需要专职的测试去做重复性的人肉测试，而需进一步提供测试自动化工具，需要往深里钻，非常有挑战。
　　WatchDog 式软件开发，这一块要看领域。耗子所在的领域我不熟悉，不多评价。但解决方案里提到的设计想好了再做，以及残酷无情还债，实在是有点片面，并不具备普适性。大部分商业系统的设计，如果要等设计想好了再做，可能已经错失商业契机，做出来已经黄花菜都凉了。先土土的上去，在行进中开火，在飞机高空飞行时换零件，我更佩服这种能力。如何做到高空中换零件，一开始可能还真需要 WatchDog 系统。常见的是监控系统，这一块太重要了。
　　不光是从技术上考虑需要 WatchDog 系统，还有一个非常实际的问题是考虑团队人员的实际情况。大部分团队里都有很多新人，有很多耗子可能看不上的普通工程师。这些新人们每天在产生大量代码，很多代码可能质量真的不高。长期的挑战是如何让大家的技能都提升到耗子期望的水平，但短期的挑战也非常棘手：如何让一帮新人写出来的代码，即便再烂，也有一定的可控性？
　　去年和 Facebook 的一个工程师交流，他说有挑战的事情之一是，如何能让一帮刚从大学毕业的 newbie 们，写出来的全栈代码不至于太烂。这背后需要大量工程化的思考与实践，涉及质量控制等很多方面。前端领域的同学，对近如日中天的 React 技术应该不陌生。React 背后的故事真的非常有意思，React 能在 Facebook 的环境下诞生，一定程度上是被逼无奈。有太多各种背景的新人们需要在 Facebook 环境下去写前端代码，但如何保证这些所谓的 Facebook 牛逼闪闪的全栈工程师写出来的前端代码不会随着时间快速腐败？如何保证各个业务线的前端代码不会臭不可闻？Facebook 有一个专业的 Frontend Infrastructure Team（简称 FIT），这帮人可是想尽了各种办法，后才发现基于 DOM 是无望的，必须超越 DOM，必须打破 W3C 规范的很多拘束，于是有了大道至简的 React 方案。React 的技术亮点在于「土」，新人们操作 DOM 老出问题，我搞一层 Virtual DOM，不让你直接操作真实 DOM。Flux 单向数据流的设计也是一种非常「土」的做法，土得出奇，但现阶段看起来，正因为土，反而把很多很多问题简化了。土到，牛气冲天。
　　后，回到如何构建一支心目中的理想团队。我的想法依旧是一张图：

　　很多团队是处于 A1 状态，都期待着往耗子说的 B1 而去。我们真正要解决的问题，是如何带领团队从 A1 波谷，到达耗子描绘的 B1 波峰。除了合理分工、团队间的彼此赋能、以及土到的技术突破，还需要重视一个规律性：
　　波峰是不稳定的，不要尝试让团队永远处于美好的波峰状态。当一个团队的人都成长成为精兵悍将时，往往意味着这个团队前途有限了。站在波峰，很容易藐视群雄，很容易拔剑四顾心茫然。一个良性团队，在短暂攀登上波峰时，应该能有勇气去打破一些东西，有勇气去带着团队下山。下山会很痛，甚至会让效率降低，但不下山，不到达另一个波谷，永远难以攀登上更高的波峰。前端团队的发展在这一点上有很多故事可讲，耗子若有兴趣，我们可以私聊。
　　很尊重耗子的理想，也是我的理想。面对现实，我选择我的路，也期待着耗子能把自己的路在美国走通。