业务场景总结

How to?

http://www.iteye.com/news/26955

你必须不断寻求改善。这里有一些很不错的书籍，可以提升你的技能：
1. 每一个软件架构师都应该知道的97件事
2. 企业应用架构模式
3. C#中的敏捷原则、模式与实践
4. 企业集成模式
5. JavaScript：最精彩的部分
6. 修改代码的艺术
7. 领域驱动设计
8. 企业架构战略
9. 设计模式
10. 目标
11. SOA设计模式
12. SOA服务设计原则
每一到两年学习一门新的编程语言。
选择一个重点领域，尽可能对技术有一个高层次的理解。
针对你的重点领域，开始写博客，并继续扩大你的知识面，在你的重点领域中成为专家。
尝试不同的技术、编程语言、设计模式、架构等。
向你的听众介绍技术，并努力让每个听众都能理解。
阅读博客，浏览并参与到Twitter和Google+中，收听播客、看杂志、参加用户组会议和技术会议，并在这些会议上发言。
每天安排时间学习新的东西，即使它只需15分钟。
有效利用一些被浪费掉的时间。
了解各种可用的工具，以帮助你更有效地做好本职工作。
了解大量不同项目中的不同架构。
了解不同的项目管理方法。
你所用的技术可以提供给业务多少价值？了解评估的方法。

大胆行前人未行之路

http://www.infoq.com/cn/articles/pragmatic-architect

架构设计恰好就需要如此。来到事物之间：在代码行上或其间，发现隐藏的领域概念；在你的系统和其他系统的组件之间，可以引导你设计好接口和工作流；在不确定性及可选项之间，驱动你的决策。架构师的工作就是去尽早地发现这些“在中间的”事物，使它们更加明确，从中做出决策。以上这些加上扎实的有关架构方法和技术的专业知识，以及谨慎的实践，就是对架构的精通之道：在软件系统的痛点上进行深思熟虑并最终决定它的成败。

架构师应该掌握的协商原则

http://www.infoq.com/cn/news/2013/01/architect-negotiation

在你与人协商时，需要决定结果以一种不让人惊讶的方式给出
协商的第二个原则就是不要模棱两可：是就“是”，不是就“不是”。
架构师们应该委派权威而不是义务：一般情况下，我总是试着在每一组中找出几个需要共事的关键个人，与之建立高度信任的关系。我给这些人在协商中成长的机会，以及做决定的能力。要认识的一个基本原则是你不能委任责任。
- 当你做的某个决定以失败告终，Dave认为应当采取下列补救措施：
  - 承担责任。
  - 在尽量早的时间内向受影响的各方道歉。
  - 让别人知道所发生的事情。
  - 让别人知道所发生事情的原因。
  - 不要责备别人，不要把责任转嫁给别人。
  - 在别人试图搞清楚发生的事情时，不要保持沉默。
- 倘若你说你要做某件事，并已经承诺做这件事，你需要兑现承诺：
  - 不管是在公开场合还是私下说的。
  - 不管是口头承诺还是书面承诺的。

创建@

2013-01-15

最后修改@

2018-06-17

标签/Tags

Architecture 1

如何成为一个架构师 2018 程序啪啪啪