[汇总]构架经验
1. 架构师思维
康威定律的影响是一个关键主题：系统的架构反映了组织的结构。
“为什么”这样的提问方式带有评判的味道，例如，“你为什么要采取这种方法”。如果将问题改为“是什么让你决定采用这种方法”，会促使被问者解释他们的想法，而不是为他们的决定辩护，因为当被问及“为什么”时，他们可能会认为自己的决定是不是不正确的。
给架构师：
- 成为帮助团队架构理解的导师，而不是障碍。公开主动地分享你的知识。
- 为那些只有你自己感觉到但团队可能没有意识到的挑战寻求指导，来帮助你克服内心的挑战。不要独自承受，支持性的指导有助于你的角色演化。
- 欢迎来自客户、团队和环境的挑战。这种反馈循环可能会让人感到筋疲力尽，但可以带来巨大的回报。
- 用你的经验将对话引向你的专业知识告诉你会遇到的挑战。
- 了解团队的动态、他们的优缺点、他们对工具的掌握，以及他们日复一日地构建应用程序的实际情况。帮助你在正确的时间组织你的输入，在哪里可以带来最大的价值。
- 成为人际关系的建设者。培养你的软技能，建立起人际网络，从销售团队到产品负责人，从工程经理到技术中小企业。每天都要培养和维护这些关系。
给团队：
- 为非领域专家总结使用工具的经验，带他们踏上理解之旅。
- 利用架构师丰富的经验来洞察你可能有的想法、挑战或主意。他们现在是你团队的一员了。
- 简单明了地表达你的想法、优点和缺点，准备好接受开放性和有挑战性的反馈，构建心理安全感。
- 把头衔和自负留在门外，拥抱团队环境，向团队里的每一个人学习。在当今的软件设计当中，你对设计过程的影响是真实存在的。
- 培养你的演讲、沟通和指导技能，并每天使用它们，在快节奏的团队中进行信息交流是至关重要的。
- 尽你所能留住你的架构师。他们深厚的专业知识对团队的成长和壮大是无价的，不要让他们感到孤立，让他们觉得自己是团队的一部分，是未来解决方案的一部分。
我们还需要架构师吗？还需要架构部门吗？我给出的答案是：不需要，因为每个人都应该是架构师。
阿里技术大牛：一份架构师成神路线图！
绝好的的技术整理！
手上有团队，有资源，我要做的是 “找到合适的人，放到合适的位置上”，让每个人发挥各自的所长，而不是我自己再去纠结一些细节。
架构师虽然听起来很高大上，但本质上仍然是工程师，不是忽悠人的江湖骗子。
架构师的职责与技术负责人的目标有所不同。这两个角色虽然有很多重合之处，侧重点却大相径庭。架构师需要转换思维——积极分配时间进行咨询（沿着各个“电梯”层），着眼于一年、两年或三年之后的情况，并且清楚地把它阐述出来，以让每个人都在同一个轨道上前行。
概念澄清 ｜ 企业架构规划能细化到开发说明书，拿着就能写代码吗？
- 软件架构关乎决策，而非结构
- 架构是一项技能，但架构师不是一种角色
- 架构意味着持续探索
即使能有合理的流程，从外部招到公司的“架构师”很多也只不过只是工龄长罢了，言必谈 DDD，中台，战略，一到了落地环节提不出合理的见解和建议。也有挂着架构师的头衔，实际上却是个“管理专家”，在催进度上更在行。
2. 构架理论
一文看懂：什么是业务架构、数据架构、应用架构和技术架构
企业数字化架构设计中的最常见要素，4A架构。
软件架构设计分层模型和构图思考 各种方案的顶层构架
- 云平台三层架构：资源-平台-应用
- SOA分层：组件-服务-流程
- 云和SOA架构融合
- 应用架构分层
- 软件技术架构分层
- 单个应用功能架构
- 架构图的分层构图逻辑
《数据密集型应用系统设计》《Designing Data-Intensive Application》
这本书的主要讲了分布式数据库、数据分区、事务、分布式系统等内容。从数据模型与查询语言，数据编码到数据复制和分区，再到事务，一致性共识，分布式系统面临的一些挑战（如故障与部分失效、不可靠网络和时钟），作者都结合实例提供了有深度的讲解，在工业与学术之间平衡的很好。
https://hilton.org.uk/blog/zero-bug-policy
作为IT咨询顾问，我经常被客户领导询问：“你们的这个解决方案，和其他家不同在哪里？”
作为咨询公司的工作者，我也经常被同事们提醒：“我们要讲出来我们的方案和其他竞争对手不同在哪里，我们的价值点、卖点究竟是什么？”
面对这些问题，我有时候感觉挺无语——因为财务、人力资源、供应链、研发等等企业运营管理的IT解决方案的课题，在我来看基本原理都是一样的，企业间并没有那么大的差异，甚至跨行业的差异性都不大；企业级IT系统在很大程度上，是企业共性能力的数字化抽象。
要是一个企业的这类IT系统的实施结果，跟其他家做得不一样，倒是真有问题了。
满分的答案都一样，学渣的考卷才百花齐放
什么？代码审查存在缺陷？我带你搞定它！
3. 最佳实践
阿里腾讯程序员写的代码就比别人好？你不知道大厂们操碎了多少心
WhatsApp 50名工程师支撑着一个10亿用户量的产品：成功因素之一是几乎不开会
德国公司Panelbear的云构架，很多有用的建议，非常细节。
技术栈帮助 Atmos 在只有 1-2 名全职工程师的情况下，发展到 1 万多个客户
4. 最差实践
大 型软件设计和实现的本质是大量的工程师相互通过“写作”来交流一些包含丰富细节的抽象概念并且相互不断迭代的过程[2]。稍有差错，系统复杂度就会失控。
也是德企常见问题
LinkedIn十几年积累的 300 万行代码，领导要全部“快速”重写，我直接辞职了
![[汇总]AI经验](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-small-empty.png)
