Right2021-12-19回答第二题：「拥抱变化」是否反人性，在于变化的内容是什么。许多公司「稳定守旧」反而让人更没有安全感，比如抱着多年前的老技术不放，项目中使用的技术和目前世面上流行的技术严重脱轨，研发人员在这种项目下除了稳定熟悉之外，更多的是惶恐不安。如果公司乐于拥抱前沿的技术，研发人员反而会安全感十足，因为他知道自己在增值。所以「拥抱变化反人性」这一点，正确性是对于目前所处的环境中我是安稳的（熟悉项目、没有挑战没有失败、没有压力），而错误性在于对于整个大的市场来说我是在减值的（技术落后、没有挑战也没有成就）。 当然，不是说拥抱新技术就一定是好的，还得有一个度，如果一有什么新鲜玩意就无脑上，那也会让研发人员缺乏安全感。 上面说的只是现在技术的角度，如果变化的内容是业务方向、战略意图等，这种我觉得就不算是「拥抱变化」，而是像前几课说的「没有确定架构目标」，这种情况毫无疑问会让研发人员没有安全感。 说到这里，其实可以发现老师讲的几条架构守则都互有关联、一脉相承，前几课讲的确定架构目标带来的好处，用这节课的内容也能很好地阐述：有了明确的架构目标，才能顺应人性，研发人员才会有的放矢，从而增强内心的安全感。展开作者回复: 谢谢。 你的答案是我很有启发
46
qinsi2021-12-14文中提到，开发微服务好比新时代的农民工种地，并列举了古罗马和中国等的例子作对比，让我想到了另一个古希腊的例子。据传古希腊有支精锐部队叫底比斯圣队(Sacred Band of Thebes)，战斗力极强，甚至击败了不可一世的斯巴达军队。其特点就是两人一组的作战单位，彼此相互掩护，为对方提供安全感。那么开发单个微服务是否也可以两人一组，顺便还能够延续结对编程的优良传统？作者回复: 哈哈哈，太有意思了！ 之前看到过古希腊军队是鼓励同性恋的， 似乎就是这个套路啊。
共 5 条评论23
neohope2021-12-30拥抱变化的七个层次： 1、极少数个人来自于某种信仰 2、少数个人来自对自己能力的信任 3、部分人来自对组织或环境的信任 4、多数人是被逼无奈，被动接受 5、某些人只想别人拥抱变化，自己才能维持不变 6、很多时候是组织对无法维持稳定环境的一种掩饰 7、更多时候就是一个口号，自嗨而已，不敢付出行动作者回复: 有层次！
18
jiankang2021-12-15学到现在，忽然感觉老师讲的内容暗含了自我实现。 良知是自尊的前提，决策的正确性是增强自我的一种方式，思考力是决策质量的保证。作者回复: 赞！ 特别赞！
共 2 条评论16- shawn2021-12-14我觉得一个微服务可以让2个人负责，高级工程师和初级工程师，高级工程师的安全感体现在主导该服务，初级工程师的安全感在工作中得到高级工程师的指点，觉得自己在成长。
作者回复: 在新人落地的时候这么做是个好办法。
14 
罗均2021-12-16再次感恩东白老师精彩的课程，和精辟的解说🌹🌹🌹 关于第三个问题，学生是一名一直在汽车行业的车厂老兵，这个领域连SOA都是奢求，更不用说微服务了。 然而老师以微服务作为土地来作比喻，的确是非常独到且精确的理解。再结合老师以类似SRP(Single Responsibility Principles)的原则来分配微服务工作的例子，对于微服务粒度的分解，学生有以下肤浅的想法。 服务分核心业务和非核心业务，核心业务相当于东南沿海发达地区的土地，粒度可以尽可能细到一人一服务，这些土地都是“寸土寸金”的。而非核心业务或相当于西北气候恶劣和土地贫瘠的地区，几乎没人肯去，这需要有魄力有能力，更需要有恒心的精英去开垦，才能将“黄沙变金沙”。从90年代朱总理发起的“西部大开发”战略以来，福建省帮扶宁夏省致富的事迹最为amazing。对于非核心业务也是如此，在明确的战略意图指导下，粒度可以大很多个数量级，例如90年代有位福建老板，一口气包下10万亩戈壁滩，经过20多年的开垦经营，硬生生将那块寸草不生的戈壁滩变成绿油油的创收百亿的红酒基地。一些非核心业务，最直接的就是运维，美国那边就有很多优秀团队就硬生生“开垦”出极其优秀的服务，例如目前一大堆神奇的DevOps工具链。 在非核心业务上开创绿洲，或比在核心业务上锦上添花，更有意思。 谢谢老师😊展开作者回复: 你这个解释非常有画面感！ 谢谢！
共 2 条评论12
lujg
2021-12-17有一个疑惑，希望老师回答。微服务架构中一个人负责一个以上核心服务。那么对于pull merge的review过程应该怎么实施？作者回复: 我理解你问的是如果是一个高风险的merge， 需要其他人帮忙review， 但是如果一个人负责一个核心服务， 其他人是不是就没办法提供有价值的review？ 我觉得如果这个是你问题的话， 一个不熟悉代码的人提供高质量review所需要的时间变得更长， 而不是没办法review。 也可以做group review。 另外我认为日常Code review的价值更多在于能力成长， 而不是控制风险。
共 4 条评论11
与非2021-12-14中台战略是不是也让开发人员没有安全感？作者回复: 不一定，但是在大公司里肯定是的。
共 2 条评论10
JianXu2021-12-18郭老师，关于第一个CEO 从心里是否认同的问题，我也有一个问题： 从这篇文章的阐述来看，得出CEO 从内心并不认同似乎是很直接的结论。但是我宁愿把人高看一眼，一家这么大的公司的CEO 能力应该是强的，认知应该是高的，所以我宁愿相信该公司的CEO 甚至整个项目里也不乏能看到您文章中指出问题的人的，那为什么仍然没有撤回这个项目呢？利益绑定问题下面的人不能破那上面的人呢？最终上面的人还是要对业务结果负责人的啊…… 关于派人去直接做迁移，我不知道这个项目的目的是什么？是完成迁移还是去赋能小公司的开发人员？如果只是迁移我认为可行，如果是赋能那就背道而驰了。而当问到赋能这个问题的时候，我的心是为这些小公司的员工好；当问到迁移从而不需要这么多并且可以降低员工要求的时候，发起这个动作的高管对待这些人的心是如何的呢？资源吗？作者回复: 你问了很多很好的问题。 我给你一个总的回答： CEO和创始人和下属的股权比例差异非常大。 这是背景。 你可以试着想象一下问你自己一个问题： 假设有个为你所不齿的事情， 但是有人要你做。 你断然拒绝了。 然后那个人写给你一张支票， 你还是断然拒绝了。 然后那个人在支票上加了一个零， 再加一个零。 你可以问问自己能幸存在这些零之后的是什么？
共 6 条评论7
欧阳绍聪2021-12-16带领团队通过技术优化，进行架构演进，为业务带来外部变化适应性，这是我理解的拥抱变化。而不是要求研发团队，不断修改业务方向，通过广泛探索，“瞎猫逮到死耗子”的方式，找到变化突破口。作者回复: 是的！
6