软件架构师应该知道的97件事
2011 年终项目总结
2011已悄然逝去，充满未知的2012正等待着我们去探究。为了更好地经营、打造未来的一年，我们有必要对过去一年的经历进行一下总结、反省，因为只有对过去不断地总结与思考，才能从中获得宝贵的经验，为未来的发展做好基础。以下是我2011年的年终项目总结：
第一章、团队建设 第二章、环境搭建 第三章、功能分析 第四章、架构设计 第五章、迭代开发 第六单、内部测试 第七章、运维部署 第八章、上线准备PS：给大家分享一下 2011年读过的几本书 。
三年前，我见证了一家互联网电子商务公司从创业开始到最终结束的整个过程，这家公司失败的根源问题是没有做好产品的推广（money不足）。不过，在整个创业过程中，我也学到了很多东西。离开这家公司后，我想在郑州重新找一家可靠的互联网公司工作，但结果并不理想。后来，我又尝试了传统软件开发行业的工作，可几个月下来，让我认识到的问题是，当前的工作不是自己想要的，更遗憾的是，在上个公司一年多的工作积累也没有用武之地。转而在今年3月初，通过朋友的推荐并面试来到现在这家公司，很高兴自己又重新回到了互联网公司工作，而且也是创业型公司。
现在这个公司主要经营亲子门户网站，致力于育儿资讯、电子商务、社区交流等多元化网络服务。目前，公司项目主要由“内容区(资讯)”和“SNS(社区)”组成，我主要负责内容区的功能分析和架构设计，以及后台的开发工作。
本系列文章主要是想和大家分享一下发生在技术部门的那些事儿，以及自己在实践过程中，所学知识的总结。
声明：本系列文章总结只代表人个观点，请误对号入坐！
1.1 团队介绍 1.1.1 产品部
接收：完成网站产品所有功能的设计，接收运营部和所有人员提出的有效建议。
交付文档：《产品原型说明文档》、相关需求说明书
岗位职能：网站的每个功能都是由他们设计（原型）出来的，并根据运营部（或策划）的需求设计产品，最终把产品需求转化为原型图和配套的原型说明文档。每个需要交付的产品原型文档都要通过需求评审会议才能发布，需求评审会议需要技术小组的相关负责人参加，评审会议结束后《产品原型说明文档》需要发布到技术部各技术小组的负责人手中。
1.1.2 美工组（设计）接收：《产品原型说明文档》
交付：产品效果图、产品所需的各种设计图（标志、ICON等）
岗位职能：凭借艺术细胞把产品原型文档转化为领导能欣赏的网页图片...
1.1.3 前端组接收：《产品原型说明文档》、效果图（美工）
交付程序：静态页面、资源文件（图片/样式表/脚本）、API 调用示例和前端架构说明文档、第三方插件资料等。
交付文档：《内容区前端资源处理标准化(SOP)流程文档》
内部文档：《html&css前端开发规范》、《javascript前端开发规范》
岗位职能：根据美工提供的效果图并参考产品部的原型说明文档进行布局，分析页面结构、提取公共模块、设计并开发样式及脚本框架。在分析和开发过程中，为了能达到更科学的效果（重用、交互体验等），有时需要和美工及产品经理沟通并修改部分效果图的布局和交互效果。在实现某些需求和服务器交互的脚本时，需要和开发人员约定相关接收和返回值的接口。
1.1.4 开发组接收：《产品原型说明文档》、前端组交付的程序
交付程序：各个产品可运行的网站程序、特定业务自动作业处理程序、公共模块的测试程序、统一架构的代码生成模板、程序相关配置说明文档。
交付文档：《内容区技术架构》、《内容区开发规格说明书》、《内容区全文检索解决方案》、《内容区安全测试标准化(SOP)流程文档》、《内容区各产品配置部署标准化(SOP)流程文档》
内部文档：《编码规范（C#版）》
岗位职能：接收产品部提供的产品原型文档，并编写《内容区技术架构》和《内容区开发规格说明书》，根据特定功能分析并编写解决方案，比如《内容区全文检 索解决方案》。把前端组所提供的静态文件，转换成动态网页，在功能分析和开发的过程中，同样也避免不了需求变更，这时需要大家共同协商并解决问题。在网站 程序开发完成并通过测试后，需要编写相关标准化流程文档，有关开发组的具体细节会在后几章为大家分享！
1.1.5 数据库组接收：《产品原型说明文档》、参考开发组的交付文档
交付文档：《内容区数据库结构说明书》、《内容区数据库配置部署标准化(SOP)流程文档》
交付程序：内容区相关数据库脚本
内部文档：《数据库管理规范》
岗位职能：分析产品部提供的原型文档，和开发人员共同协商数据库的设计，指导开发人员编写高性能的SQL语句和存储过程，设计数据库访问权限和数据库物理架构设计，以及数据库运维工作（部署、备份、安全等）。
1.1.6 测试组接收：《产品原型说明文档》、静态效果图、网站所有产品的发布程序、前端组和开发组交付的开发说明书和相关配置文档。
交付程序：经过测试的网站程序
交付文档：《内容区后台使用说明文档》、《测试流程管理标准化(SOP)流程文档》等
内部文档：《Bug流程管理》、《Bug管理工具说明》、《测试申请单》等
岗位职能：根据产品部提供的产品说明文档编写测试用例，并依据以上小组提供的文档对网站产品进行测试，并按照《Bug流程管理》处理Bug。网站产品测试结束后需要依据《产品发布作业标准化(SOP)流程文档》进行产品发布，并编写相关测试总结文档。
1.1.7 运维组接收：经过测试的网站程序和相关部署配置文档。
交付文档：《托管机房IDC部署文档》、《IDC机房网站内容区运维标准化(SOP)流程文档》
岗位职能：公司内部和IDC机房的硬件及网络运维工作（硬件采购、账户分配、网络维护、硬件及系统环境搭建等），包括服务器系统及相关环境的搭建，按照《产品发布作业标准化(SOP)流程文档》对网站程序进行部署。
注： 以上只是简单介绍了技术部内部各小组的工作内容，在实际工作环境中还要和产品部门、运营部门、编辑部门进行协作沟通。
1.2 团队协作
在团队介绍中已经简单描述了每个小组的工作内容，从每个小组的“接收”和“交付”内容中可以看出一些工作流程，我根据以上内容简单地画了一张“团队协作流程图”。
在团队协作的过程中，有很多环节需要注意，如果前期不进行良好的沟通，各种问题就会越来越多，就如雪球会越滚越大，等到问题暴露出来，甚至会造成项目重头再来的局面。接下来我会列出项目中几个比较典型的问题和大家分享。
1.2.1 产品文档评审会议首先产品经理需要在《产品原型说明文档》中，把产品的所有功能描述清楚，因为美工会按照产品原型文档去设计效果图。在会议上产品经理需要依据 《产品原型说明文档》来讲解产品所包含的功能，此时参加的组员都可以发表自己的建议。这个环节很重要，开发人员（开发组长或项目经理）必须要理解清楚产品 所包含的每一个功能，因为要依据这些功能来设计产品的技术架构，如果开发人员误解了需求，有可能会导致阶段性工作重来。同样，测试人员（测试组长或测试经 理）也需要理解每个功能在页面中的表现，并且，确定《产品原型说明文档》对功能的解释足够详细，因为后期测试组需要拿着这个文档来对项目进行功能性测试， 如果前期不确定清楚，在测试时会和开发人员、产品经理发生争论。总之，每个技术小组的负责人都要理解《产品原型说明文档》，这样才能设计和开发出产品经理想要的产品。
1.2.2 需求变更在这个公司，需求变更可以分为两种，一种是如果我们犯了上面的错误，也就是说，开发人员根本没有弄清楚需求，这样就会导致项目在开发过程或内部 测试时，各小组意见不一致，此时，就会请产品经理确认需求，修改相关文档和程序。另一种则是产品经理在设计时没有考虑周全，在内部测试时，客户代表（编辑 人员或负责人）发现不是当初想要的，这时产品经理不得不重新设计需要修改的功能，然后按照流程执行修改。需求变更在传统瀑布开发模型中是不允许的，而在敏 捷开发方法中，需求变更是常见的事情，所以，在竞争激烈的互联网行业中，拥抱变化，才能快速迭代发布产品来抢占市场。
1.2.3 架构统一当网站产品原型和开发文档都完成后，就进入了实现阶段，美工会按照原型来设计网页效果图，而前端会根据效果图来编写前端代码，后台也是同样。这些看似简单的流程，想要做到持续简单的同时，还要保障团队成员在今后有个良好的合作平台，就需要提前定义架构，统一架构。比如，各技术小组都是由多个成员组成的，而公司的发展还会有新成员加入，为了确保新员工加入团队后，能够快速适应项目的开发，或者是当老成员离职后，其他团队成员能够更快地接手他的任务。在第二章，我会介绍各小组必需要建立的一些内部文档，但是除了这些文档，在开始编写代码前，还需要各小组分析产品功能、编写统一的架构设计和案例代码，并要求整个开发团队都按照这个流程和代码结构来编写代码，这样团队中的每个成员都能有效地阅读其他人的代码，同时也方便开发组长（项目经理）进行代码审查。如果没有按照以上方法来执行，那么很多开发人员都有过这样的经历，在修改团队其他人，或者在修改离职员工编写的功能模块时，宁愿自己再重新编写，也不愿审阅他人的代码。关于架构统一，应该由公司的架构师和团队中资深开发人员进行具体实现，这样也可以达到提高团队成员技术水平的效果。
1.2.4 有效沟通在团队协作过程中，建立一个良好的沟通环境很重要，但是很多时候大家是为了沟通而沟通，这样就会浪费大量的项目时间。前两天，在看《 软件架构师应该知道的97件事 》时，收集了一些关于有效沟通方面的建议：
不要把对话当成对抗 不要带着情绪与人沟通 尝试通过沟通设定共同目标 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。 让沟通事半功倍，起立发言是简单、有效的方法！ 必须和执行该决策及会直接或间接受其影响的人进行过沟通，达成共识。本系列目录： 2011 年终项目总结
1、开发人员应该解决问题，而不是解迷取乐。
2、关键问题可能不是出在技术上：
不要把对话当成对抗 不要带成情绪与人沟通 尝试通过沟通设定共同目标3、以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。
让开发人员参与架构的制订过程，这样他们才会买你的帐！4、架构才是影响应用性能和可伸缩性的决定因素，性能参数是无法简单地通过更换软件，或者“调优”底层软件架构来改善的。
5、分析客户需求背后的意义
架构师可以通过询问客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好、成本更底的解决方案。6、让沟通事半功倍，起立发言是简单、有效的方法！
7、故障终究会发生。
8、量化需求
比如：必须在1500毫秒响应用户的输入。在正常负载（定义如下....）的情况下，平均响应时间必须控制在750~1250毫秒之间。由于用户无法识别500毫秒以内的响应，所以我们必须将响应时间降低到这个范围之下。9、一行代码比五百行架构说明更有价值
如果你亲自参与开发，应该珍视自己花在写代码上的时间，千万别听信这会分散架构师精力的说法。参与项目所付出的努力，既能拓展你的宏观视野，也能丰富你的微观视界。10、提前关注性能问题。
11、草率提交任务是不负责任的行为。
12、业务目标至上、掌握业务领域知识
架构师必须通过沟通协调，即保护软件架构，又坚持业务目标，即允许开发人员制定微观（技术）决策，又设法避免他们参与制定业务决策。如果技术决策脱离了业务目标目标和现实条件的约束，则无异于用宝贵的稀缺资源进行高风险的投机。13、先确保解决方案简单可用，再考虑通用性和复用性。
许多用来实现基础设施的代码，包括组件框架、类库、基础服务，普遍存在一个问题，它们的设计一味强调通用性而不考虑具体应用，导致出现许多令人困惑的可选项和不确定因素，这些功能常常不是因为被闲置，就是被误用，甚至毫无价值。14、架构师应该亲力亲为
对技术缺乏全面理解的架构师，充其量只是个项目经理。 架构师完全可以要求团队成员的帮助，让团队成员充分参与制订解决方案，同时引导讨论方向，找出正确的方案。 架构师应该尽早参与项目，与团队成员并肩工作，而不是坐在象牙塔里发号施令。15、持续集成
尽早构建，经常构建。16、避免进度调整失误
加快进度不一定会降低成本，要考虑交付质量和后期造成的影响，可以尝试去掉一些不重要的功能，留待后续版本发布。17、取舍的艺术
世界上不存十全十美的设计，既具有高性能，又具有高可用性；既高度安全，又高度抽象；18、不要轻易放过不起眼的问题
自已的盲点自己难以查觉，忠言虽然逆耳，却是你最宝贵的财富。 组织团队一起来想办法管理风险。19、让大家学会复用
大家知道它们的存在 大家知道如何使用它们 大家认识到利用已有的资源好过自己动手20、架构里没有大写的"I"
自我反省，做人问题。 重视团队合作，架构属于团队，不是你一个人的。你负责导航，大家一起划桨。双方缺一不可，但相比之下，你更离不开他们的帮助。 做技术的，保持谦虚是最基本的素质！21、先尝试后决策
尽量推迟决定的时间，最后即便不做决策，决策也会自己呈现。 对同一个问题尝试两种或两种以上的解决方案，比直接决策然后动手实现的工作量要大。22、程序设计是一种设计
把编写代码看成设计行为，而不是生产行为。23、控制项目规模
抓住真正的需求 分而治之 设置优先级 尽快交付24、架构师不是演员，是管家。
扎实掌握技术和业务领域知识，以严谨的领导风格赢得团队的尊重。25、混合开发的时代已经来临
26、性能至上
尤其目前的互联网行业27、学习软件专业的行话
比如架构和设计模式可以分成四大类，企业架构模式、应用架构模式、集成模式和设计模式。28、具体情境决定一切
架构决策只有在情境需要时，才能牺牲尽量简单的原则。29、侏儒、精灵、巫师和国王
软件架构师好比国王，应该熟悉各种人的性格特点，招聘不同性格的人加入自己的团队，英明的国王知道怎样用目标来激励不同的种族，率领大家并肩作战完成任务。30、避免重复
复制是魔鬼 重复性的工作拖累开发进度31、仔细观察，别试图控制一切
32、架构师当聚焦于边界和接口
低耦合，高内聚 定义系统边界33、助力开发团队
确保开发人员拥有他们所需的工具 确保开发人员拥有他们所需的技能 只要不违背软件设计的总体目标，就让开发人员自己做出决策。 保护好开发人员，不要让他们卷入到不那么重要的工作中。34、记录决策理由
不要为了写文档而写。 懂得《取舍的艺术》，定义软件架构，就是要在质量属性、成本、时间以及其它各种因素之间，做出正确的权衡。35、分享知识和经验
36、模式病
使用模式解决适用的问题才是最重要的，禁止在项目中硬塞不必要的模式。37、关注应用程序的支持和维护
应用程序超过80%的生命周期都是在维护上 理解开发人员和支持人员确实具有不同的技能 在项目中尽可能早地引入支持负责人 将支持负责人作为团队的核心成员之一 让支持负责人参与规划应用程序的支持38、有舍才有得
接受某种约束或放弃某个特性，可带来更好的架构，这种架构在构建和运维上都会更加简单，而且成本底。39、先考虑原则、公理和类比，再考虑个人意见和口味。
40、数据是核心
IDE、操作系统、软件等都是工具。41、不仅仅控制代码，也要控制数据。
源代码控制和持续集成，是管理应用程序构建过程和部署过程的优秀工具。数据方案和数据内容通常会随着源代码变化而变化，它们也是这一过程的重要组成部分，因此也需要对之进行类似的控制。 灵活运用“数据库脚本”解决问题。42、确保简单问题有简单的解
对于简单的问题，不要采用复杂的解决方案。软件设计者都是聪明人，但是出于炫技心理，很容易陷入“杀鸡用牛刀”的误区。 对应第一条“开发人员应该解决问题，而不是解迷取乐。”43、架构师首先是开发人员
作为架构师，主要目标应该是创建可行、可维护的解决方案，当然，也一定要能解决当前的问题。44、根据投资回报率(ROI)进行决策
45、一切软件系统都是遗留系统
即使系统十分前沿，采用了最新的技术开发而成，但对于接手的下一个而言，它也会是遗留系统。 设计优化的架构基础，考虑如下几个问题：清晰性、可测性、正确性、可跟踪 可以参考一些优秀的开源项目46、起码要有两个可选的解决方案
47、理解变化影响
优秀的架构师能够深刻理解变化带来的影响，这种影响不仅限于彼此隔离的软件模块之间，而且包括人与人之间，以及系统与系统之间。 变化有多种不同表现形式：功能需求的变化、可扩展性需求的演进、系统的接口被修改、团队人员流动等。 常用方法减轻变化的影响：运行小规模的增量渐变、构建可重复运行的测试用例、让测试用例更易编写、跟踪好依赖关系、系统性的行动，根据反馈信息作出进一步反应、自动化重复的任务。48、你不能不了解硬件
学习硬件知识 和基础设施架构师紧密合作49、现在走捷径，将来付利息。
50、不追求“完美”，“足够好”就行
在设计和实现上追求完美，会导致过度设计和模糊混乱的解决方案，最终使系统难以维护。应用程序开发不是选美大赛，因此，停止吹毛求疵的做法，不要再浪费时间追求尽善尽美。51、小心“好主意”
那种诱人的、不用想都知道的、外表无辜、以为不可能会产生伤害的那种“好”主意。通常在项目进展到一半而似乎一切看起来都挻好——形势和进度都在循序渐进，初步测试进展顺利，落地日期看起来可靠无误——的时候，项目团队中有人会冒出这些想法。务必小心那些“好主意”，它可能会杀死你的项目。52、内容为王
很多系统的成功取决于其内容的建设。53、对商业方，架构师要避免愤世嫉俗。
54、架构师要以自己的编程能力为依托
对应“架构师首先是开发人员”55、稳定的问题才能产生高质量的解决方案
只要问题是稳定的，你就可以创建出一个拥有稳定设计的系统。稳定的设计可以让你集中精力，打造出高质量的应用程序。56、天道酬勤
57、弃聪明，求质朴。
58、对决策负责
重要的架构决策应该以书面形式记录下来，它们必须经过校核证实，并可被追溯。 必须和执行该决策及会直接或间接受其影响的人进行过沟通，达成共识。59、精心选择有效技术，绝不轻易抛弃。
60、客户的客户才是你的客户！
61、事物发展总会出人意料
设计是一个不断发现的过程，发现问题并解决问题。 没有永不过期的解决方案。62、着重强调项目的商业价值
形成价值陈述 建立量化的度量标准 回过头来关联传统商业的衡量方式 知道该在哪里停止 寻找恰当的时机63、偿还技术债务
花合适时间“一次做对”！ 取巧走“捷径”，争取尽快推出修改后以产品。64、打造上手的系统
用户体验很重要 对最终用户而言，界面就是系统！65、找到并留住富有激情的问题解决者
我们所要找的，是那种具备解决问题的能力和激情的开发人员，都善于攻克各种难题的人才。 提防批评过度，它可能会扼杀开发人员的创造力，降底生产力。 好的开发人员都非常聪明，他们知道自己并非一无是处，如果你对其工作吹毛求疵，将会降低他们对你的尊重！ 以正确的方式经营开发团队，其重要性不言而喻。66、学习新语言
想要理解客户或者想让客户理解你的语言，必须学习客户所在行业领域的语言，这样才能做到有效沟通。67、优秀软件不是构建出来的，而是培育起来的。
设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。注意，不要把这种演化式方法和削减需求、规范混乱和生产废品这样的做法混淆在一起。
作者： Leo_wl
出处： http://HdhCmsTestcnblogs测试数据/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息