十年架构感悟
蔡超
Mobvista 技术 VP 兼首席架构师
免费领取
14796 人已学习
课程目录
已完结 1 讲
十年架构感悟
十年架构感悟
蔡超 2020-11-30
大家好，我是汇量科技的蔡超，也是 QCon 的老朋友了。
以前我会给大家分享一些具体的技术，例如微服务，甚至我会带上笔记本跟大家一起写写代码、调调程序。这次不一样，我会给大家分享一些软性的内容，分享一下我做架构这十年来的感悟。
1.“提出问题”难于“解决问题”
跟大家分享的第一个感悟是：“提出问题”难于“解决问题”。包括我在内，工程师们最大的一个特点就是善于解决问题，因为我们通常都是从问题解决者的角度来进行工作的。但是，我们很少会主动提出一些问题，主动从用户的场景出发去提出问题、提出需求。
很多时候，公司里的一些矛盾就来自于工程师和产品经理之间，比如我们常常会说产品经理不懂技术，需求提得不够专业。但我们作为工程师也可以想一下，我们是不是应该把自己的位置再往前挪一点，去看看用户到底有哪些困惑，然后提出一个合理的需求去解决它；或者我们自己去体验一下用户的场景，然后提出一个全新的问题并解决它。
简而言之，我们不要仅仅去做一个解决问题的人，也要做一个提出问题的人，主动去思考什么样的问题、需求，能让我们的业务更加先进。
很多时候，我们会觉得设计一个架构、写一个程序去解决问题是一件很难的事情，当然这也是一个很棒的工作。但如果你静下心来去尝试提出一些问题，改进一些用户的需求，你会发现，这是一件更难的事情，至少对我来讲是如此。
确认放弃笔记？
放弃后所记笔记将不保留。
新功能上线，你的历史笔记已初始化为私密笔记，是否一键批量公开？
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该文章仅可阅读部分内容，如需阅读完整文章，请先领取课程。
免费领取
登录 后留言
精选留言(51)
mai谢谢蔡老师的分享，不忘初心，坚持匠心✊
蔡老师分享的几本书：《设计原本》，《面向模式的软件架构》，《恰如其分的软件架构》2020-12-1345
Untitled
1.学会提出问题
2.做减法，tradeoff and blance
3.非功能性需求决定架构
4.keep in simple,布隆过滤器
持续学习，做正确的事情。2020-12-01241
陈斯佳
谢谢老师精彩的分享！整理了一下笔记和同学们分享一下
1. “提出问题”难于“解决问题”。程序员要学会如何从用户的角度发现困难，提出需求问题，适配用户场景。不仅仅是一个解决问题的人，而是提出问题的人，不断地思考什么样的需求的问题能让我们的产品更先进
2. “设计最难的部分就是去设计我们要设计什么样的问题” - 《设计原本》Brooks
3. 什么是架构？从很多层面上说，架构是一种tradeoff，是一种权衡、平衡。作为一个架构师，你应该是那个说“不”的人。决定不要什么比要什么更难。先确定一个大原则，之后在做选择的时候根据这个原则来取舍，这样就不会随着工作的推进而迷失了
4. “决定不做什么和决定做什么是一样重要的”-史蒂夫.乔布斯
5. “人们认为专注是对你要关注的事情说yes。但是这完全不是专注的本意。专注是对其他一千个好的想法说no。你必须非常谨慎的挑选。实际上我对我拒绝做的事和我做过的事一样感到骄傲。创造力就是对一千件事说NO的能力。” - 史蒂夫.乔布斯
6. 非功能需求决定架构。所谓的非功能需求，包括性能，伸缩性，可扩展性，可维护性，甚至还包括了你的团队结构，你的团队技术水平，你的发布周期的要求，这些来筛选那些可以去使用的方案，最终找到一个合适的架构。
7. 非功能性需求在架构中是非常重要的，起了决定性作用，因为功能性需求在设计完之后，如果是了一个功能，未来我们可以再加上去，它对你的架构不会有本质上的影响。但是如果我们忽略了某一种非功能性需求，在未来这有可能产生灾难性的后果，很有可能你就需要重写，比如架构导致数据一致性的问题，没用充分考虑性能问题等，这样所有的功能性实现都没有意义，你就得完全重写整个东西。Micro-Kernel模式架构可以了解一下。
8. “简单可以比复杂更难。你必须非常努力的把你的想法想清楚之后你才有可能把事情做的很简单。但是这个努力是值得的，因为一旦你达到了这个目的，它会给你带来排山倒海的能量。为了能达到真正的简单，你必须思考的足够深入。”--史蒂夫.乔布斯
9. 简单不同于容易，而且恰恰相反，真正的简单其实是来自于不容易的，复杂才容易，简单蕴含了巧妙在里面
10. 在软件开发生命周期中，对软件发布后的维护占了整个成本的一半以上。如果你要让一件事情简单，你就可以让后期的维护变得简单，这是性价比最高的事情
11. “我相信软件开发中最难的部分，也是最经常导致失败的部分，是和软件用户之间的沟通交流”--Martin Fowler（马上搜了一下Martin Fowler的推特账户，发现大师在人间还活跃着，很激动…）
12. 对于一个架构师来说，你永远都不要停止编码，你永远都是一个程序员。如果你停止编码，你就会丧失对敲代码这种痛苦的感觉，你就会容易产生不切实际的幻想，做出不切实际的设计，这是最大的一个问题。（罗胖也坚持自己做启发俱乐部磨练自己的手艺）
13. 风险优先。所谓的架构设计就是你要在早期就能识别出这个系统可能出现的风险问题，然后通过你的设计去除或转换它，比如通过原型或架构切片的早期迭代去测试我们的架构是否还存在风险。
14. 敏捷开发的精髓是，如果一个项目会失败，那你要让它快速的失败
15. “如果你这个项目其中能预见到的风险都能通过重构解决的话，那么你就没必要设计软件架构，你重写就好了。”--《恰如其分的软件架构》Just Enough Software Architecture
16. 从“问题”开始，而不是“技术”
17. 过度繁忙使你落后，因为你没有时间去更新你的知识。在一个公司干了几年，如果你不持续学习，你就很容易“被忠诚”，因为你失去了跳槽的能力和勇气。而且在你的工作中，你面对的问题会越来越复杂，你会觉得越来越难以应付，你只有通过不断地加班来解决。如果你不能紧紧跟随你所在行业的发展，那你只能天天加班，这会是一个恶性循环，越加班，越没有时间学习。试想一下，如果你已经领先业界五年了，你还在乎休息一个礼拜吗？
18. 做更好的自己。锻炼配合营养，实践也要结合学习，你才能变得越来越好。
19. 要不断学习，你不一定要换领域，你可以用不同的方式做同样的事情，然后把事情做的更好。
20. 不忘初心，坚持匠心2021-01-01136
行与修
过度繁忙让我们落后！警醒！2020-12-0623
依旧木瓜看出来了，是个务实派架构师2020-12-0616
Geek_f71330
keep it sample，我觉得老师已经把容易和简单的区别讲的很通俗了ᥬ🤪᭄2020-12-01213
iHTC你的知道没有更新，而你面对的业务和场景越来越复杂（越来越大的数据量、越来越复杂的业务场景、越来越刁钻的用户需求），所以你会觉得越来越难以应付，所以你只有通过不断加班来应付🥳2020-12-078
Cryhard讲到简单和容易的时候，老师稍微有点紧张了。讲的道理是很不错的，以后会更好！2020-12-057
Holos不忘初心，坚持匠心2020-12-027
MaLu听完后，觉得几个点选择的都比较典型，主要的观点是两个，1.做事之前明确业务
（1）提问题的重要性（2）确定事项的决策（3）对领域、业务的敬畏（4）风险的识别
2.怎么与时俱进
（1）保持编码，感知实施的感觉
（2）学会停顿，避免繁忙2021-01-156
蛋炒番茄我觉得讲的很好，跟贴地气，通俗易懂2020-12-156
爱学习的大叔老师下次分享健身的经验，哈哈哈2020-12-086
Jawf这是写代码的真架构师2021-01-044
瘦瘦瘦以不同的方式做同样的事情，把同样的事情做成不一样的效果2020-12-074
r荣s松感谢老师的分享，好久没听一个视频听的这么入迷了，不忘初心2020-12-054- 浩支持我超哥2020-12-034
小波Transformers
老师，在中国程序员真的走35岁被退休的说法吗？技术一般的、35岁以后的程序员，应该往哪个方向努力？甚至说往哪个新的职业转型、转业？2021-03-062
niexias- 尝试提出问题，去解决一些用户体验。作为工程师的一个特点是解决问题，这仅是以问题解决者的角度去工作的。作为工程师也可以把自己的位置往前挪一下，去看看你用户到底有什么困惑，然后提出一个合理的需求去解决它。以一种新的角度去是需要用我们的创造力。
- 架构需要平衡。人性的本质的贪婪的，做一个项目的时候，我们什么都想往里面放，特别是一些非功能性需求。架构需要平衡，决定不做什么和决定做什么是同样重要的。做架构设计的一开始，就是确立一些设计的原则。
- 非功能性需求决定的架构。很多时候我们觉得，做架构的第一步就是，收集各种需求，这个架构要满足这些需求，毕竟产品最终是为用户服务的。而事实上，一个好的架构，是由非功能性需求决定的。非功能性需求包括性能、伸缩性、可扩展性、可维护性等，如果忽略了某一种非功能性需求，那么可以带来灾难性的麻烦。
- keep the simple 并不简单。把一件事做简单，需要很多深入了解的工作。比如对架构的简化，很大程度上来自我们对技术、开发过程，以及不同业务场景的深入理解，而不仅仅是这个结构写起来好不好写。真正的简单是来自于不容易的。
- 永远不要停止编码。代码是软件的最终实现形态，代码的实现可能会影响架构的最终呈现。放弃编码，最大的影响不是说你的代码技术落后了，最大的影响是你逐渐丧失对编程的敬畏，忘记作为一个程序员的感受，最后可能会做出一些不切实际的设计。
- 风险优先，不要把风险放到最后。架构设计的主要目的就是转化、降低、避免整个开发过程中的风险。要尽早的去测试风险，看看我们的架构是不是能解决相关的问题，尤其是非功能性需求，绝对不要把风险放到最后。
- 从问题出发，而不是技术。工程师非常乐意学习一些新技术，并且很乐意去应用这个技术。经常在某一个时刻特别想去实践一下新的技术，以至于忽略了当前手上的问题用这个技术是否是最合适的。其实这样是有很大的害处的，可能导致问题变得更加复杂，给工作带来不少的烦恼。
- 过度繁忙使你落后。对于大部分程序员来说，忙碌已经成为习惯。而作为一个技术人，如果你不更新你的知识，或者忙碌没有时间更新知识，那么结果是怎么样呢？必然让你落后。即便不跳槽，随着业务的发展，数据量变大，场景越来越复杂，如果你长期去更新支持，那么你会觉得越来越难以应付。另外，如果你不更新知识，不深入思考，你所创造的技术和业务就没有领先性。这其实是一个恶性循环。2021-03-012
jsdlkjafkd手动点赞2020-12-032
蜗牛君深入地学习，把同样的事做得不一样。在知识深度上成长。2020-12-022
收起评论