架构定义？
架构师的职责？
确认需求，技术选型，系统分解，系统设计，培训与指导，沟通
架构师的能力？
沟通能力，领导能力，抽象思维和分析能力，技术深度和广度
数据库系统规划、设计、评审、优化
技术理解透传，熟悉原理，有解决问题的方法和思路
先做个记号。
明确授权，权责匹配；
项目经理不具备业务知识、行业知识和项目知识，缺乏软技能，面对压力无法做出关键决策，无法看到问题的本质，无法进行整体的思考，无法从全局提出系统性解决方案，经常是头疼医头，脚疼医脚；
善于学习总结，加强项目管理意识，注意团队建设，规范开发过程。
代码审查和重构（http://www.cnblogs.com/harlanc/p/6772394.html）
http://mp.weixin.qq.com/s/YK-rZzDk-R4qc69R9qkRow
程序员们特别喜欢讲一句话「talk is cheap, show me the code」，不少人把这奉为技术信仰。在评价一个人的技术能力时，这是一个合理的准则。然而，工作中能写代码并不是唯一的能力准则，很多问题的解决壁垒并不是技术本身。我们在解决问题的过程中，需要协作沟通，需要把自己的理念和想法传给其他人。正确的语言沟通，合理地洞察人情世故，处理好各种社交场景，对我们来说同样重要。这些能力，也许是当「编程技能硬通货」不能保障我们生存时尤其重要。
我想我们还要预防在一个自认为合理的世界中自我封闭。过几年完全脱节，对新事物理所当然地用自己认为正确的那一套代入。现实世界中，我对稍复杂的社交场景便有轻微恐惧，但是我并不排斥也认为应该要去接触各型各色不同领域不同背景的人。我想，不管怎么样，我们应该对这个世界保持关注，不管是现实还是网络。
http://blog.csdn.net/foruok/article/details/60552387
http://mp.weixin.qq.com/s/Ry-G0Nikh6m-h3ZVC2cLyQ
从来没有一个资深的外科医生会放下手术刀，而转到手术室外面指手画脚。一个资深的程序员也不应该离开代码和文档的编写，而只是做做架构图。
作为对一个复杂系统的负责人，必须亲手领导和参与建造，才能有足够的能力去负担起这个责任。因此需要至少使用60%的时间来参与开发的工作。
坚持打开电脑做的第一件事是打开IDE软件，是这一切最重要的一步。你会发现你不在需要在网上看微博和聊QQ来提振开始工作的激情，而会被某一个优化代码的灵感而激励，或者被一个复杂而有趣的问题所吸引，从而更快的能投入到开发中。
对业务领域的理解能力和经验是第一位的。如何抽象好业务领域的模型，不能照搬别人的经验，但也不能完全靠自己想象。需要自己对业务领域做深入思考，同时也多学习了解其他项目的模型。
软件架构设计至关重要，而且工作繁重。不画图纸就敢开工的技术人员要么是天才要么是笨蛋。对于团队来说，架构在分工合作、避免风险、提高质量等多个方面有无可替代的作用。
架构要避免成为空洞的文档，最重要的一步是有人来掌控和实施。
传统行业和互联网的技术相辅相成，并不一定是互联网的技术要比传统行业的技术高深很多，而是它们有自己的侧重点，传统行业更偏向于企业级开发，项目具有业务复杂、流程丰富、中心化管理、企业级抽象度高、业务重用率高的特点，而互联网倾向于把复杂的业务进行拆分成单一的职责，对于单一职责模块的非功能质量进行大幅度的优化，这包括高可用性、高性能、可伸缩、可扩展、安全性、稳定性、可维护性、健壮性等。
非功能需求包括核心非功能需求和其他功能需求。
核心非功能需求：
|
需求 |
描述 |
|
高性能 |
运行效率高，性价比高 |
|
可用性 |
持续可用性，缩短宕机时间，出错恢复，可靠性 |
|
可伸缩 |
垂直伸缩，水平伸缩 |
|
可扩展 |
可插拔，组件重用 |
|
安全性 |
数据安全，加密，熔断，防攻击 |
其他非功能需求：
|
需求 |
描述 |
|
可监控性 |
快速发现，快速定位，快速解决 |
|
可测试性 |
可灰度，可预览，可Mock，可拆解 |
|
鲁棒性 |
容错性，可恢复性 |
|
可维护性 |
易于维护，监控，运营，扩展 |
|
可重用性 |
可移植性，解耦 |
|
易用性 |
界面友好，易操作，学习成本低 |
