卷首语：
蔡超：这八点架构师感悟，真的很干货 | 大道至简
一位资深架构师的肺腑之言，无限缩短你的架构晋升之路。
作者｜蔡超
编辑｜忠良
一、站在“提问题”角度来解决问题
技术人员常常吐槽产品团队需求不合理，不过建议技术团队去走进业务，不仅仅是去设计架构、实现产品的需求，同时也试着去实现客户的需求，甚至发现潜在的需求。这时我们就变成了在设计上提出问题的人，你会发现提出问题的同时，在很多时候也需要同样深入的思考。设计一个好的问题，甚至比解决问题更难。
二、“少”比“多”更困难
软件机构设计切实需要取舍，当大家都在往里面加东西的时候，架构师更应该来做这个说“不”的人。做“少”比做“多”困难百倍，希望你能掌握 CAP 原则做取舍。为了更好的取舍，保持架构风格的一致性，在一开始架构师就应该根据系统的实际需求来定义一些取舍的原则，如：数据一致性拥有最高优先级、提前发布核心功能优于完整发布等。
三、非功能性需求决定架构
非功能性需求决定架构，架构师要更加关注非功能性需求，常见的非功能性包括：性能，伸缩性，扩展性和可维护性等，甚至还包括团队技术水平和发布时间要求。
四、“简单”不容易
很多架构师都会常常提到保持简单，但是真正的一些简单的方法，来自于对问题和技术更深入的理解。这些方案往往不是容易获得的、表面上的方法。
五、永远不要停止编码
架构师也是程序员，代码是软件的最终实现形态，停止编程会逐渐让你忘记作为程序员的感受，更重要的是忘记其中的“痛”，从而容易产生一些不切实际的设计。 Amazon 高级副总裁级别的 Distinguish Engineer，他们每年的编码量也非常大，常在 10 万行以上。
六、仔细识别非功能性风险
架构设计很重要的一点是识别可能存在的风险，尤其是非功能性需求实现的风险，如数据一致性要求、响应延迟要求等。这些风险不容易被发现，但是修正的代价非常大。我们应该通过原型或在早期的迭代中确认风险能够通过合理的架构得以解决。
七、从“问题”开始，而不是“技术”
技术人员非常乐于去学习新技术，更有激情去使用新技术，导致常常有一个通病——使用一些不适合的技术去解决问题，常常会导致简单问题复杂化。
八、过度忙碌使你落后，记得留点余闲给自己
加班已经成为习惯，但是忙碌的工作，常常会导致新知识的匮乏，进步维艰。这就像健身一样，光靠锻炼是不行的，营养补充和锻炼同样重要。个人技术成长也一样，实践和学习是一样重要的。
本文为重写概述，原文链接：
https://mp.weixin.qq.com/s/uwA5JryExOpUtQ_5AF7bBQ，欢迎大家阅读。
蔡超，拥有超过 15 年的软件开发经验，其中 9 年任世界级 IT 公司软件架构师/首席软件架构师。2017 年加入 Mobvista，任公司技术副总裁及首席架构师。
目录
热点 | Hot
转载阿里开源框架 Egg.js 文档被告知侵权，原作者：难道我才是那个恶人？
Gitee 新政被喷惨了，开源仓库必须先审核再上线
Flutter 3.0 正式发布：稳定支持 6 大平台，字节跳动是主要用户
理论派｜Theory
调用链追踪系统在伴鱼：OpenTelemetry 最佳实践案例分享
推荐文章 | Article
2022，我们该如何理解可观测技术
中国技术出海，TiDB 数据库海外探索之路 | 卓越技术团队访谈录
观点 | Opinion
忍受不了糟糕的工作氛围，我退出了 Google WebAssembly 团队
曾经一年有 6 个月在考核绩效，谷歌最终放弃使用了 20 多年的“内卷神器”
初创数据库公司的疯狂行为：删掉花 7 个月开发的 27 万行 C++ 代码，用 Rust 全部重写一遍
评论