博客园_Astar之学习.NET路程

[读书笔记]Scrum 总结

2012-02-28T05:52:00Z

最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量。

参考资料：

《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》
硝烟中的Scrum 和 XP
火星人敏捷开发手册
Scrum-Checklists
维基百科：http://zh.wikipedia.org/wiki/Scrum

Scrum 工具

禅道
JIRA+GreenHopper

Scrum 中的角色

Scrum Master——项目负责人、项目经理

保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

Team——开发人员、测试人员、美工设计、DBA等全职能性团队

团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

Product Owner——产品负责人、产品经理、运营人员

从业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目，在 Sprint 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息。

User——最终用户、运营人员、系统使用人员

很多人都可能成为最终用户，比如市场部人员、真正的最终用户、最好的领域专家，也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。

Manager——管理层、投资人

管理层要为 Scrum 团队搭建良好的环境，以确保团队能够出色工作，必要的时候，他们也会与 Scrum Master 一起重新组织结构和指导原则。

Customer——客户、系统使用人员、运营人员

客户是为 Scrum 团队提出产品需求的人，她会与组织签订合同，以开发产品。一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中，负责批准项目预算的人就是客户。

Scrum 中的产出物

Product Backlog——Backlog 待开发项，积压的任务。

产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。

Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周。

在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。

已定 Product Backlog

Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。

User Story、Task——用户故事、任务

用 User Story 来描述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大，可能会导致对它的开发横跨几个 Sprint，此时就应该将这个 User Story 分解。

为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。

障碍 Backlog——问题列表，积压的待处理事务。

列举了所有团队内部和团队相关的和阻碍项目的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

通用会议规则

基本要求

每次会议都要准时开始、准时结束。
每次会议都采取开放形式，所有人都可以参加。

会前准备

提前邀请所有必须参会的人，让他们有时间准备。
发送带有会议目标和意图的会议纲要。
预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。
会前24小时发送提醒。
准备带有会议规则的挂图。

会议推进

展开讨论时，会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。
推进人展示会议的目标和意图。
有必要时，推进人可以商定由某个撰写会议记录。
推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化。
推进人会对会议进行收尾，并进行非常简短的回顾。

会议输出

使用手写或挂图说明来记录文档，给白板和挂图上的内容拍照。
必须传达会议记录和大家对会议结果的明确共同认知。

让团队坐在一起！

大家都懒的动，尽量让“产品负责人”和“全功能团队”都坐在一起！
互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。
互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。
隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到，反之亦然。

团队建设

Scrum 团队最佳人数控制在“5～9”人。
全职能性团队：开发组（后台开发、前端开发、测试人员——3~8人）、Scrum Master（项目经理）、产品负责人
兼职团队成员：美工、DBA、运维

每日立会（Daily Standup Meeting）——建议下班前开始

会议目的

团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。
任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。

构成部分

任务板、即时贴、马克笔
提示：ScrumMaster 不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。

基本要求

成员：团队、Scrum Master
无法出席的团队成员要由同伴代表。
持续时间/举办地点：每天15分钟，同样时间，同样地点。
提示：团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他做得更快？”

会议输出

团队彼此明确知道各自的工作，最新的工作进度图。
得到最新的“障碍 Backlog”
得到最新的“Sprint Backlog”

会议过程

团队聚在故事板旁边，可以围成环形。
从左边第一个开始，向团队伙伴说明他到现在完成的工作。
然后该成员将任务板上的任务放到正确的列中。
如果可以的话，该成员可以选取新的任务，交将其放入“进行中工作”列。
如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。
每个团队成员重复步骤2到步骤5。

每个人三个问题：

上次会议时的任务哪些已经完成？：把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么？
下次会议之前，你计划完成什么任务？：如果任务状态为“待处理”，转为“正在处理”状态。如果任务不在 Sprint Backlog 上，则添加这个任务。如果任务不能在一天成，把这任务细分成多个任务。如果任务可以在一天内完成，把任务状态设为“正在处理”。如果任务状态已经是“正在处理”，询问是否存在阻碍任务完成得问题。——明天做什么？
有什么问题阻碍了你的开发？：如果有阻碍你的开发进度的问题，把该障碍加入到障碍 Backlog中。——今天遇到了什么问题？

注意事项

不要迟到
不要超出限制时间
不要讨论技术问题
不要转变会议话题
不要在没有准备的情况下参加
Scrum Master 不要替团队成员移动任务卡片，不要替团队更新燃尽图。
Scrum Master 不要提出问题，团队成员不要向 Scrum Master 或管理层人员报告。
如果不能出席会议，需要通知团队，并找一名代表参加。

任务板

任务板集合了选择好的 Product Backlog 和 Sprint Backlog，并以可视化方式展示。
任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。
尽量使用大白板，也可以使用软件。

任务板有4列：

选择好的 Product Backlog：按照优先级，将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
待完成的任务：要完成一个故事，你得完成一些任务。在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集所有特定 Backlog 条目需要完成的新任务，并将它们放入该列。
进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始，没有完成的任务都会放在该列中，并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小的部分，然后把新任务放到那一列，移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，Scrum Master 就会记下一个障碍。
完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡。

燃尽图（Burn Down Chart）

跟踪进度要由团队来完成，燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。一般来说，燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
团队每天更新燃尽图。
如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。在 Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。

Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的所有Sprint，纵轴表示各个Sprint开始前，尚未完成的工作，它的单位可以是个（Story 的数量），人天等。

Sprint 规划会议——第一部分（上午）

会议目的

该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，团队将会决定他们能够交付哪些东西。
产品负责人在会前准备：条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。

基本要求

迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。
只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

构成部分：

经过估算和排序的 Product Backlog。
挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
假期计划表、重要人员的详细联系信息。
参会成员：团队成员、Scrum Master、产品负责人

持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。

会议输出

选择好的 Product Backlog 条目。
各个 Backlog 条目的需求。
各个 Backlog 条目的用户验收测试。

会议过程

从第一个 Product Backlog 条目（故事）开始。
讨论该 Product Backlog 条目，以深入理解。
分析、明确用户验收测试。
找到非功能性需求（性能、稳定性...）
找到验收条件。
弄清楚需要“完成”到何种水平。
获得 Backlog 条目各个方面的清晰了解。
绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕 UI 设计等。
回到步骤1，选取下一个 Backlog 条目。

流程检查：询问团队能否快速回答下列问题，只需要简要回答即可：“我们能在这个 Sprint 中完成第一个 Backlog 条目吗？”如果能得到肯定的回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。——接下来，休息一下。在休息后，对下一个 Backlog 条目展开上述流程。

结束流程：

在 Sprint 规划会议第一部分结束前留出 20 分钟。
再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，...第二个，...？”
如果团队认为他们不能再接受更多的 Backlog 条目，那就停下来。
现在是非常重要的一步：送走 Product Owner，除了团队和 Scrum Master 之外的所有人，都得离开。
当其他人都离开后，再询问团队：“说真的——你们相信自己可以完成这个列表？”
希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。
将结果与 Product Owner 和最终用户沟通。

注意事项：不要改变 Backlog 条目大小，不要估算任务。

Sprint 规划会议——第二部分（下午）

会议目的

该会议的工作以设计为主，产品开发团队可以为他们要实现的解决方案完成设计工作，在会议结束后，团队知道如何构建他们在当前 Sprint 中要开发的功能。

基本要求

只有产品开发团队才能制定解决方案，架构师或其他团队之外的人只是受邀帮助团队。

构成部分：

能够帮助团队在该 Sprint 中构建解决方案的人，比如厂商或是来自其他团队的人员。
选择好的 Product Backlog 条目。
挂图......

注意事项：不要估算任务，不要分配任务。

会议输出

应用设计、架构设计图、相关图表
确保团队知道应该如何完成任务！

会议过程

从第一个 Backlog 条目开始。
查看挂图，确定对于客户的需求理解正确。
围绕该 Backlog 条目进行设计，并基于下列类似问题：
- 我们需要编写什么样的接口？
- 我们需要创建什么样的架构？
- 我们需要更新哪些表？
- 我们需要更新或是编写哪些组件？
- ......

当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。

持续时间：在 Sprint 规划会议第一部分完成后，召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分，在 Sprint 中，每周该会议占用时间为 60 分钟。

估算会议——根据项目情况合并到 Sprint 第二部分会议

会议目的

要做好战略规划，你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作，这个数据也是必须的。
团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

基本要求

只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。

构成部分：

Product Owner 根据业务价值排定 Product Backlog 各项顺序。
需要参加的人员：Team、Product Owner、User、Scrum Master

注意事项：

不要估算工作量大小——只有团队能这么做。
Product Owner 不参与估算。

会议过程

Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
团队使用规划扑克来估算 Backlog 条目。
如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog 条目使用规划扑克进行估算。
重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

持续时间：该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适。

会议输出

经过估算的 Product Backlog。
更小的 Backlog 条目。

扑克牌估算（Planning Poker）

具体步骤：

每个人各自估算后独立出暗牌，听口令一起开牌。
数值最大者与最小者PK，其他人旁听也可参考。
讨论结束后重新出牌和开牌。
重复上述过程，直到结果比较接近。

常见问题

1、为什么任务要分给组而不是个人？

答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。

2、为什么不让最后领任务的人自己估算？

答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

3、为什么不让师傅估算大家采纳，他不是最厉害吗？

答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

Sprint 评审会议（Review Meeting）——根据项目需要举行

会议目的

Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。

基本要求

Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

构成部分

有可能发布的产品增量，由团队展示。

会议输出

来自最终用户的反馈。
障碍 Backlog 的输入。
团队 Backlog 的输入。
来自团队的反馈为 Product Backlog 产生输入。

持续时间：90分钟，在 Sprint 结束时进行。

会议过程

Product Owner 欢迎大家来参加 Sprint 复审会议。
Product Owner 提醒大家关于本次 Sprint 的目的：Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
产品开发团队展示新功能，并让最终用户尝试新功能。
Scrum Master 推进会议进程。
最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

注意事项：

不要展示不可能发布的产品增量。
Scrum Master 不要负责展示结果。
团队不要针对 Product Owner 展示。
Sprint 反思会议（Retrospective Meetin）——根据项目需要举行

会议目的

该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。

构成部分

参与人员：团队成员、Scrum Master

基本要求

从过去中学习，指导将来。
改进团队的生产力。

注意事项

不要让管理层人员参与会议。
不要在团队之外讨论找到的东西。

会议输出

障碍 Backlog 的输入。
团队 Backlog 的输入。

持续时间：90分钟，在 Sprint 评审会议结束后几分钟开始。

会议过程

准备一个写着“过去哪些做的不错？”的挂图。
准备一个写着“哪些应该改进？”的挂图。
绘制一条带有开始和结束日期的时间线。
给每个团队成员发放一叠即时贴。
开始回顾。
做一个安全练习。
收集事实：发放即时贴，用之构成一条时间线。每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。
“过去哪些做的不错？”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。
做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。
“哪些应该改进？”：像“过去哪些做的不错”那样进行。
现在将即时贴分组：
我们能做什么》团队 Backlog 的输入。
哪些不在我们掌控之内？》障碍 Backlog 的输入。
根据团队成员的意见对两个列表排序。
将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入，并决定到时候要如何处理这些发现的信息。

附两张流程图（资料截图）

本文链接

[2011 年终项目总结] 第八章、上线准备

2012-02-15T23:20:00Z

此系列文章总结了我在2011年所负责项目的收获，主要包含了“团队建设、环境搭建、功能设计（未发布）、架构设计、迭代开发、网站测试、运维管理”，从这七方面总结一个互联网项目从创建到上线的主要过程（不包含策划和运营的工作）。本章主要介绍项目在上线前需要准备的一些工作和注意事项，另外根据项目的性质不同，需要准备的工作也会有差别，接下来所要介绍的内容只限于个人观点。

1.1 准备工作

1.1.1 域名注册

有兴趣的朋友可以补补功课“域名”，在域名注册前后需要注意以下事项：

域名来源通常由项目创始人在开启项目前就已经注册了，或者成立公司后由“核心员工”根据项目信息商讨使用什么域名。当确定项目的“域名组成”后可以通过 “域名提供商”查询域名是否被注册，没有注册则选择服务比较好的服务商进行注册，如果域名已经被注册，可以根据公司情况协商是否要通过交易平台购买此域名。域名注册时要注意域名的“所属人、版权信息、联系方式”等信息，防止域名后期产生版权争论。
在互联网行业中，为了方便域名的记忆和推广，多数根据项目信息来决定域名，但是也有些项目是先注册了域名，再根据域名来开展项目的具体有哪些产品，这样就会导致域名约束项目的发展，一定要避免这种情况的发生。
注册域名前也要考虑此域名在之前是否有被使用过，可以通过搜索引擎进行查看，防止域名对项目本身的推广产生影响。
域名在注册成功后，需要删除域名的默认DNS绑定信息。
为了防止项目后期受到竞争对手模仿或个人利用，要注册和项目主域名有关的受保护域名，比如主域名为“xxx.com”，根据需求注册其它后缀的域名 “xxx.cn、xxx.net、xxx.com.cn、xxx.org等”，如果不受资金的约束，可以同时注册和项目有关的域名。

推荐域名注册商：

1.1.2 IDC服务商

　　域名问题解决后，紧接着在网站上线前要解决选择IDC服务商的问题，根据项目的情况选择“虚拟主机（云）、VPS、服务器托管”，如果选择“虚拟主机（云）”或者“VPS”，可以根据项目的“用户群”选择一些优秀的IDC提供商。我们目前选择“服务器托管”，考虑到现场安装、维护等问题，就需要在当地选择一些优秀的机房来托管服务器。

在选择IDC服务商时，要考虑到机房所提供的“带宽、防火墙、内部网络环境、服务条款”等问题，注意协议上的条款和行业潜规则，在选择带宽时，要根据需求购买。

注：由于地区问题，我们所在地区除了电信和网通机房外，没几家公司真正自建机房，所以很多时候是没得选的……

1.1.3 网站备案

　　目前网站备案是越来越麻烦了，网上流行说“备个案比领结婚证还麻烦”，所以网站在上线前一个月就要开始网站的备案工作。首先打开备案申请网站“工业和信息化部”了解一些流程文档，现在的IDC服务商都提供备案接入平台，同IDC服务商良好的沟通可以加快网站备案的速度。网站备案时需要注意主域名的填写，以及域名所属人及IDC服务商的信息。

注：一定不能忽视网站备案问题，避免网站上线时因为备案问题导致上线延迟。

1.1.4 运维部署

　　选择完IDC服务商后，就要开始项目物理环境的部署，由运维人员和IDC服务人员进行协调沟通，完成物理架构的部署，以及系统环境的搭配和配置，参考 “第七章、运维管理”。

1.2 项目部署

当准备工作都完成后，就要开始项目的部署工作，项目部署前要完成项目的开发和测试。

1.2.1 数据迁移

此处所指的数据迁移只是把“上线前”内部准备的数据（数据库、图片、文件）迁移到线上环境，如果前期在内部模拟和线上同样的环境，在上线时的数据迁移工作就会很轻松，只需要将数据复制到目标环境。目前的数据迁移工作比较简单，迁移内容如下：

数据库：备份本地的数据库，然后还原到远程数据库服务器，也可以采用数据导入/导出来完成。
图片：打包本地图片为zip，复制到远程图片服务器指定磁盘目录中，如果图片量比较大，可以由运维人员通过存储设备复制到IDC机房进行部署。
文件：主要包括项目的静态资源和专题文件，同样采用远程复制即可，注意部署前要考虑到是否为最新版本或优化（压缩）过的文件。

1.2.2 项目发布

首次进行项目发布时，应该由开发人员进行发布部署，开发人员从源代码版本控制中提取最新的已经测试的版本，按照线上的环境进行发布程序，并部署到线上环境中。项目发布到线上环境时需要注意以下事项：

动态编译：根据环境（测试、模拟、线上）的不同，如果程序中有动态引用的Services，就需要在发布前重新动态引用。
发布配置：前不久刚阅读完《持续交付》这本书，书中多次强调要做好项目的配置管理工作，只有打好这个基础才能在后期完成持续集成中的自动化工作。项目发布时要根据线上环境修改项目的配置文件，并在配置说明书中讲清楚每个节点的作用，方便运维人员以后维护。在项目发布并可以稳定运行后，运维人员需要对配置文件进行备份，并且每次升级前都应该备份。
合并优化：在项目生产环境时，为了方便开发和调试，会在项目中使用大量的插件和注释，项目发布时需要对已发布的程序进行优化，比如“资源文件的压缩合并、删除非编译文件的注释和调试文件”。
初始设置：使用VS在发布项目时，需要把发布模式修改为“Release”，注意在“Debug”发布后修改web.config为“Release”是不行的。另外在项目发布时要注意项目的初始设置是否生效，比如“错误页、404、302”等。
冒烟测试：项目发布并部署完成后，开发人员可以简单对项目的核心功能进行“冒烟测试”，查看项目是否可以正常运行。

1.2.3 运维管理

项目发布后，运维人员要开始对网络、操作系统、应用软件进行“封存”配置，主要的配置信息如下：

硬件防火墙的规则及VPN访问权限设置、操作系统用户权限和防火墙的过滤规则，数据库服务器及软件的配置和安全设置（DBA）。
IIS站点的初始设置和网站目录的访问权限设置，对相关域名进行绑定（暂时不对外开放）。
监控软件及应用程序的运行配置。

可以参考“第七章、运维管理”

1.2.4 线上测试（内）和数据初始化

　　项目发布后，此时站点还没有对外开放，内部人员通过VPN连接到远程机房，通过内部DNS访问“线上”的项目进行测试工作，因为线下已经对发布的项目进行了完全测试，此时的测试可以根据时间关系进行适当的冒烟测试，具体测试方法可以参考“第六章、网站测试”。

线上测试后如果没有发现问题，此时管理员需要对测试数据进行初始化，数据初始化还包括编辑对网站内容的推荐，保证网站上线后是“丰满的”。

1.2.5 数据备份

在所有工作都准备结束后，运维人员要对线上发布的可运行程序及数据进行备份，“第七章、运维管理”介绍有数据备份方案。

1.3 其它工作

完成以上工作后，可以开通域名解析，对外公开访问权限。在项目对外公开访问前/后，根据项目的性质选择性检查以下工作是否完成：

第三方服务：数据统计（Google Analytics）、网站管理工具（Google）、网站监控（监控宝）等。
SEO相关工作：生成网站地图（属于功能模块）、“robots.txt”设置、各大搜索引擎提交网站等。
性能分析：网站各地区访问速度测试（webkaka）、前端优化检查（yslow）
其它检查：收藏夹图标（favicon）、Apple Mobile Web Clips Icon、死链接检查（Xenu）

本系列目录：2011 年终项目总结

本文链接

[2011 年终项目总结] 第七章、运维管理

2012-02-06T11:14:00Z

本章所涉及的运维管理有两部分，第一部分介绍公司内部的“IT运维”，第二节部分介绍“网站运维”的相关总结（很多内容还在实践中改善）。

7.1 IT运维

参考“IT运维”第一段，“IT运维”并不是本节所介绍的那么简单，它的复杂程度根据公司规模和性质有关系。目前公司“IT运维”主要负责以下日常工作：

硬件采购：制定不同部门员工的电脑配制单和公司网络设备需求等，由运维人员提供给行政部门采购。
设备管理：对网络设备、服务器设备、操作系统运行状况进行监控和管理。
系统管理：负责员工电脑操作系统的安装和维护支持，架设并管理内部应用系统（虚拟化、文件服务器、版本控制系统、数据库服器等）。
资源管理：建立内部资源管理机制（文件服务器、版本控制系统），并对这些资源和数据进行管理和备份。

目前运维组有以下工作流程：

新电脑安装流程
新员工开设帐号流程
电脑收回及帐号删除流程
机房上架机器操作流程
日常技术支持流程
网络维护规范流程
硬件安全管理流程
备份规范流程

7.2 网站运维

首先区分“网站运维”和“网站运营”是两个完全不同的工作，也属于不同的部门，并且网站运维也不只是安装系统、架设局域网那么简单的工作，本章节总结目前项目都做了哪些运维工作。

7.2.1 物理架构

在“第四章、架构设计”中介绍了项目的物理架构，在项目进入物理架构设计阶段时，项目负责人要和运维负责人共同完成项目的物理架构，因为运维负责人会为网络架构、数据存储、网络安全等提出一些更好的建议，前期设计良好的物理架构，会方便后期的架构扩展和运维管理。

7.2.2 运维管理

硬件采购

运维负责人要根据网站的物理架构和IDC机房环境选择合适的硬件，采购物美价廉的硬件。选择什么品牌的服务器、购买服务器硬件的哪些套餐、什么版本的操作系统更适合网站等这些工作也是一项技术活，并且要提供多套价格表供上级领导选择。在硬件采购时，需要注意以下事项：

性价比：不管企业处于哪种阶段，选择“性价比”最好的方案才能得到领导的认可。
实用性：根据实际需求购买硬件和软件服务，硬件更新太快，不要盲目追求高配置而造成资金浪费，结合项目的发展情况来扩充硬件需求。
稳定性：可扩展性、可冗余性、热插拔性
售后服务：这个很重要

资料：51CTO、IT168

网络部署

目前项目部署环境是由IDC机房提供一个机柜，运维人员按照项目的物理架构把服务器相关设备部署到IDC房机，有关网络的部署需要注意：

网线制作：不同的网络设备需要不同的网线质量来连接，比如千兆和万兆交换机的连接是有区别的。
部署整理：把硬件设备摆放到合适的位置，不要随意摆放，为每个设备和网线贴上标签，写明每个设备的用途，方便后期维护和整理。

系统安装

根据网站的架构需求，安装网站运行环境所需要的操作系统和应用软件，初始化操作系统相关配置，调整操作系统安装策略。这个过程可以由项目负责人（开发人员）辅助完成，或者参考内部测试环境进行安装。安装操作系统和应用软件时，需要注意以下事项：

最小化安装：Web服务器使用Windows Server 2008 Web版本已经足够，减少授权费用，关闭操作系统不使用的服务，只安装需要的组件，比如：IIS7默认并没有安装“动态压缩”的功能，静态资源和图片服务器采用Centos+Nginx。
软件配置：在默认安装SQL Server、IIS、Nginx、杀毒软件等后，都需要对这些软件的功能需求边界进行设置，关闭不使用的功能配置，屏蔽一些安全开关，必要时对可运行的环境配置进行备份。
权限设置：在操作系统和软件默认安装后，为了能保证网站程序的正常运行，需要对默认环境进行配置，有时需要开放一些安全权限，也需要关闭一些安全设置。比如“为网站程序建立专有的系统用户，限制IIS站点的访问权限和目录执行权限，并设置“当前用户”对操作系统的操作权限。”参考“配置Web 服务器安全性 (IIS 7)”
安全策略：根据需求分配访问网站程序用户的权限和安全级别，在不同的节点进行控制，比如“硬件防火墙过滤原则”、“服务器访问权限控制”、“网站程序访问权限”、“具体服务接口调用的安全策略”、“配置信息加密控制”等。
容量规划：根据网站的物理架构、逻辑架构、具体数据需求来规划数据存储空间和数据存储策略，考虑后期数据容量的扩充和维护，可通过监控工具（RRDtool）查看数据容量的变化，及时对磁盘容量进行扩充。
系统备份：当操作系统和应用软件环境都安装完毕后，需要对目前可正常运行的环境进行备份（Windows Server Backup），防止系统产生问题后花费大量时间来初始化操作系统，如果使用“虚拟化”，可以灵活设置虚拟机的快照，更方便备份和还原。

网站安全

　　第一步要最大化保证网络、操作系统、应用软件的安全级别，然后按照“第六章、网站测试”中的安全测试方法对网站进行安全测试，并对用户所产生的数据进行加密（用户密码等资料），对网站程序的配置信息进行加密（.NET 自带），最后防止社会工程学对网站进行破解，做好内部保密工作。

网站部署

根据内部流程，网站部署最终由运维工作人员负责，具体流程参考“第一章、团队建设”的团队协作图，网站部署流程如下：

1、运维组接收测试组的升级工程单（紧急情况特殊对待）。
2、按照升级工程单从版本控制系统获取最新需要发布的程序。
3、升级工程单会详细描述此次升级需要更新的文件和需要修改的配置说明，升级对应的网站程序，按照工程单中的要求来决定是否需要重启网站。
4、通知测试组验证此次升级是否有效。

注：目前内部程序更新和升级版本都需要手工操作完成，这样难免会产生误操作，团队内部正在学习“持续集成”中的一些最佳实践，实现自动化配置发布流程。

监控与报警机制

网站投入运行后，如果想要随时了解网站的运行情况，就需要采用可靠的监控解决方案。

网络、硬件设备、操作系统：采用开源软件搭建监控平台，目前我们采用“Cacti”来监控网络运行状况、磁盘容量监控、操作系统及操作系统的服务运行状况（Nagios插件），也可以在“Cacti”上安装插件来监控“Memcached”的运行状况。为了可以在远程监控操作系统的运行状况，可以为服务器安装“远程管理卡”实现通过远程浏览器监控操作系统的重启过程。
网站程序运行监控：在网站架构初期，就要考虑网站程序日志系统的重要性，通过网站程序的日志系统可以监控网站业务的运行状况，记录重要的错误信息方便分析。
第三方监控服务：以上两种监控解决方案只是针对内部监控，可以使用第三方服务来监控网站的运行状况（HTTP、PING），通过开发服务器操作系统的 SNMP服务来监控操作系统和具体服务的运行状况，第三方监控服务优点在于可以实现分布式监控，网站管理员可以查看网站在各地区的访问速度，同时也具备多种报警机制。目前我们使用了“监控宝”和“webluker”，它们分别提供了免费的监控服务，大家可以尝试使用。
报警机制：常见的报警方法有“日志记录、邮件通知、短信通知”，也可以使用第三方通讯软件的接口（GTalk）。我们采用内建邮件服务器，对外发送邮件通知（QQ企业邮局），QQ企业邮局提供免费短信提醒，网站出问题后可以收到短信通知。（注意报警策略可以随时关闭）
有关监控文章分享：监控与报警机制

日志管理

目前我们做了以下日志记录和管理：

网络运行日志：监控网络和设备产生的日志，目前采用“solarwinds”工具。
操作系统和软件日志：定期备份操作系统产生的日志，根据需求设置软件的日志存储策略（IIS、SQL Server），一定要合理存储和管理应用程序产生的日志。
网站程序运行日志：考虑到网站性能，默认不开启网站业务的日志记录，只有发生问题或在测试环境时才开启网站的日志记录。

数据备份

在IT运维中，有一项重要的工作为“数据备份”，公司内部需要一种备份解决方案来解决内部数据（文档、文件资料、源代码、应用软件）的备份，针对不同的环境备份机制不同，但是一定要定期把对于公司最重要的数据进行备份，可以同步到光盘或者第三方存储设备上。

除了内部数据备份，网站在运维的过程中所产生的数据（数据库、图片、任何资源）、操作系统及应用程序配置信息，都需要一套可行的备份解决方法。

推荐以下备份方法：

工具：FileGee
批处理：手动编写脚本（bat）对数据进行备份
Windows Server Backup：操作系统自带的数据备份解决方案

采用哪种方案并不重要，重要的是运维人员和公司内部要认识到数据备份的重要性。

自动化管理

自动化管理主要是为了节约运维成本，减少长期手工操作产生的误操作。在保证一些运维实践都可以正常运行后，使用工具或脚本串联一系列操作过程。 “CC.NET”就是为了解决自动化配置和软件发布管理工具，如果团队要采用“持续集成”，项目前期就需要规好化产品的配置管理、版本控制、测试策略、自动化构建脚本等工作。

本系列目录：2011 年终项目总结

本文链接

[2011 年终项目总结] 第六章、网站测试

2012-01-31T12:18:00Z

软件测试早已成为一门学科，它也是传统软件开发周期中重要的环节。在互联网行业，网站测试也是必不可少的。回忆在自己的技术成长过程中，从中可以看出测试工作越来越被企业重视（自身所在环境）：

2004～2006：以学习技术为主，偶尔开发小软件（VB）和个人站点（ASP），完全没有认识到测试的概念，只是在开发过程中完成功能测试，记得当时ASP漏洞横扫一片……
2007～2008：为学校官方做一些网站，自己联系老师收集需求，从网上找PSD模板，Table布局，最后用ASP/ASP.NET连接Access 实现功能。08年从事一家科技公司“生产”企业站，由美工完成效果图，自己完成剩余的工作，销售会配合技术人员完成一些功能测试，并没有完全认识到兼容性的问题，当时还都是以IE6为主。
2009～2010：09年从事第一家互联网公司，开发B2C商城，此时的技术团队成员虽少，但每个成员的工作内容划分很明确。由设计人员完成网站的主体设计（LOGO、首页色调），美工兼前端（DIV+CSS）完成网站效果图的设计和网站页面的布局，当时的JavaScript还主要由后台开发人员编写。团队中没有专业的测试人员，相关测试工作都由开发者来完成，比如前端开发人员要完成网站兼容性测试，后台开发人员要完成具体的功能测试，在网站上线前会由相关编辑及运营人员配合测试系统。10后半年尝试传统软件开发行业，套用页面模板进行功能开发，有专业的测试人员和项目管理流程，测试人员根据需求文档完成产品的功能测试，测试工具和测试方法还都不全面。
2011～现在：重新回到互联网公司，从头开始一个“亲子门户网站”的开发，技术团队的组成参考“第一章、团队建设”，测试组在团队中发挥着重要作用，本篇文章主要分享自己在整个项目周期中，有关测试所整理的总结。

6.1 测试环境

从网上找到一个公式：测试环境=软件+硬件+网络+数据准备+测试工具

6.1.1 硬件环境

在“第二章、环境搭建”中介绍了采用“虚拟化”来解决测试环境中的硬件问题，根据实际需求模拟多台操作系统来部署网站。在我们网站的测试过程中，有以下测试专题需要特别硬件支持：

压力测试：在“虚拟化”环境中对网站进行压力测试时，本地“虚拟化”系统的吞吐量和网络流量有限，无法模拟出高并发的访问量，可以借助公司内部交换机，在多台员工机器安装LoadRunner客户端进行最大化压力测试。
稳定测试：在进行网站功能测试时，可以把网站“最小化”部署到单台虚拟机上，只要能保证网站可以正常运行而不影响功能测试。对网站子功能进行稳定性测试，利用“虚拟化”模拟发布环境，根据需求搭配必要的硬件，并且为网站填充适量的数据进行稳定性测试。

6.1.2 软件环境

在“第二章、环境搭建”介绍了网站所使用的软件和技术，开发组在发布第一个测试版本时需要协助测试组来部署网站的运行环境，也可以参考《项目配置说明书》。在部署软件环境时，需要注意以下事项：

软件版本：测试环境需要和生产环境使用一致的软件版本，避免出现意想不到的Bug，可以在公司内部搭建文件服务器，由专人进行维护和更新，大家统一从文件服务器下载软件，防止病毒和版本不一致的问题。负责编写《项目配置说明书》的人员，需要在文档中写清楚软件的版本号和下载地址。
统一环境：在测试环境中，一定要具备和上线后一样的网站运行环境，测试人员才能最大化覆盖系统的Bug，同样运维专员在具体实施过程中也有“样板部署”可以参考。

6.1.3 参考资源

测试组在对项目进行测试时，需要参考其它部门或小组交付的文档和资源。

内部文档

在测试过程中，测试组主要参考以下文档：

功能性测试：《产品原型说明文档》、《产品开发规格说明书》
稳定性测试：《产品技术架构说明文档》
数据库结构验证测试：《产品数据库结构说明书》
安全性测试：《产品安全测试标准化流程文档》

效果图和静态页面

除了参考文档外，还可以参考效果图对网站整体进行“黑盒测试”，效果图是原型文档的具体实现，在测试过程中如果有疑问需要及时和产品经理进行沟通。

6.2 测试工具

6.2.1 常规测试

网站的常规测试是指功能测试，在不同测试周期可以采用不同操作系统和浏览器对网站进行常规测试，此处用版本对照来举例说明：

内部测试版本（Alpha）：网站部分功能还没有开发完毕，此时测试组可以采用开发组推荐的测试环境(Firefox、Chrome) 只对交付的程序进行功能测试。
公开使用版本（Beta、Release）：采用网站目标群体使用最多的系统和浏览器，比如“Windows XP+IE6”。

注：目前项目并没有引入TDD开发方法，只能对网站进行“黑盒测试”。

6.2.2 工具介绍

测试管理

JIRA：在“第二章、环境搭建” 2.2.4有介绍。
TestLink：测试用例管理系统，主要功能是测试用例的创建、管理和执行，并且还提供了一些简单的统计功能。

测试工具

QTP:自动测试工具，使用QTP的目的是执行重复的手动测试。
LoadRunner: 预测系统行为和性能的负载测试工具，主要对网站前台进行压力测试。
WcfStorm：用于测试WCF和WebService的工具，支持传输Object[]类型。
Webscarab：是一款代理软件，用于对网站进行手工安全测试，主要功能包括HTTP代理，网络爬行、网络蜘蛛，会话ID分析，自动脚本接口。
其它：AppScan、Xenu

6.3 测试方法

6.3.1 功能测试

无论是在网站开发过程中还是网站开发完毕后，当把发布的网站程序交付给测试组时，测试人员首先开始对发布的网站程序进行功能测试。在进行网站功能测试时，需要参考《产品原型说明文档》和《产品开发规格说明书》。这两个文档对网站功能以及每个页面呈现都描述的很清楚，甚至对每个表单所要输入的字数限制都有要求，测试组会严格按照需求对网站进行功能测试。

对于一些重复性的功能测试，可以采用自动化工具进行批量测试。比如：链接是否可用、重复表单数据输入、批量填充数据库数据等。

6.3.2 安全测试

个人认为互联网项目安全性是最重要的，无论功能做的再完善，用户体验做的再好，如果不能保证项目的安全性，会导致项目在运行过程中存在着安全隐患。在项目的架构时期就应该考虑安全设计，并且开发人员要有构建Web站点的安全意识和经验，测试人员也需要具备安全测试的技能。以下推荐一些安全方面的资料：

《Web 安全测试》：讲解一些Web安全知识，也介绍了一些安全测试工具的使用。
设计安全的Web应用：介绍了Web站点流行的“csrf”攻击手法和防范措施。
做好网站安全的纵深防御：InfoQ针对之前互联网公司用户信息泄露事件做的专题，文章底部有相关安全链接。

写文章之前对郑州几家还不错的互联网项目进行了简单的安全测试，多多少少都存在有安全漏洞，之所以存在这些问题，首先开发人员对安全意识不够，测试人员或许就没有对网站进行安全测试。我们的网站在上线前，对项目所存在安全隐患进行了总结，整理为文档对测试组进行了培训，这里会介绍一些常见的安全测试方法。

在进行安全测试前，项目负责人要说明项目所存在的安全隐患和安全测试点，以及目前项目所做了哪些安全防范，测试人员参考文档来验证安全问题，如果测试人员具备安全测试技能，可以在进行功能测试时，同时对功能点进行安全测试。目前项目表格如下：

每个工具的具体使用方法可以Google，对Web站点的业务逻辑进行测试时，最常用的工具是“Webscarab”，使用它可以截获HTTP的请求和输出，并可以修改Cookie，通过它来绕过客户端验证，测试服务器端是否采用相关安全措施。上图介绍了Web站点常见的安全项目，尝试了几个站点，多数都存在以下问题：

服务器端缺少验证：网站表单提交只采用了前端JavaScript验证，通过Firebug或者Webscarab可以伪造数据破坏系统业务逻辑，比如“用户名长度”、“邮箱格式”、“相关必填项”、“脚本注入”等。
权限控制：网站特殊业务逻辑的权限设计不够谨慎，之前测试一个网站，当用户登陆成功后，可以通过传入具体站内信标识删除其它会员的站内信，并可以根据任意用户订单号查看订单明细等权限漏洞。
文件上传：只采用客户端验证文件扩展名和文件大小，当通过手工POST上传文件超过需求文件大小时并没有相关的拦截提示，只有文件上传完毕后服务器端才判断文件大小有问题，这样会严重影响服务器的网络带宽。
验证码：在提交表单时，通常采用验证码来防止客户端恶意提交或者暴力破解用户信息，有些网站甚至把验证码明文存储到Cookie当中，这和没有验证码有什么区别呢？另外有些网站把验证码存储到Session当中，但是提交表单成功后并没有销毁当前验证码，而只是在当前页面重新加载时重新给Session ID赋值，这也是一种错误的使用方法。当客户端第一次输入正确的验证码后，提交表单并拦截页面输出，利用工具使用之前正确的验证码进行重复提交，这样的验证码也相当于没用。有关验证码识别就不介绍了，属于另外攻击手段。
脚本注入：最常见的Web站点攻击方法，参考“设计安全的Web应用”。
SQL注入：这个就更不用介绍了，参考“SQL Injection”，常见的解决办法有“参数化传递”、“存储过程过滤”或者采用第三方工具“UrlScan”。
……

注：本节只介绍网站本身的安全测试，有关操作系统以及应用软件本身的安全可以使用“及时更新安全补丁”和“最小化安全设置”的原则。

6.3.3 兼容性测试

在做产品规划时，就应该决定网站所针对人群和所能运行在什么平台，这些属于网站的基础需求，只有确定这些后，前端才可以做相应的取舍，根据平台和浏览器的特性设计前端部分代码。可以通过“虚拟化”来构建兼容性测试所需要的测试环境，优先用户使用最多的平台和浏览器进行测试。

平台测试

Windows：xp、2003、2008、7
IPad

浏览器

IE
Firefox
Chrome
Safari
Opera
山寨浏览器：360、搜狗、世界之窗等

分辨率

标准：1024×768
小于：800×600等，产生滚动条。
大于：1280×800等，显示大背景。

测试工具推荐

IETester：支持多标签来测试IE系列浏览器。
SuperPreview：微软提供的工具。
在线测试：http://browsershots.org/、http://spoon.net/browsers/

开始进行兼容性测试前，可以看一些有关浏览器内核和工作原理的文章：

6.3.4 性能测试

网站的性能可以通过很多手段来提高，针对不同的阶段和场景采用不同的方法，推荐一本书给开发人员参考《构建高性能Web站点》。

加载速度

测试页面和页面元素的加载速度，查看整体页面在稳定网络环境（内网）下的加载速度，发现问题并提供给开发人员分析，网站上线后可以通过一些第三方服务（http://www.webkaka.com/）查看网站在各地区的访问速度。

　　压力测试

网站上线前我们需要对整个网站和一些核心组件（数据库访问）进行压力测试，有些问题在开发阶段是无法呈现的，而在多用户并发访问时就会出现问题。我们在开发数据库访问组件时，会建立一些demo页面，使用“LoadRunner”对这些页面和操作进行压力测试，查看数据库组件的相关性能和在特定环境下所支持的并发率（操作时间上下限）。整个网站的压力测试受限于测试场景，要在稳定的网络环境中和特定的硬件条件下，分析网站功能并录制多个常用的用户操作场景，并对这些场景进行压力测试，分析测试结果并对网站进行优化。

具体有关“LoadRunner”的使用方法可以参考网上的一些教程，这里提供一个快速入门的系列“当DiscuzNT遇上了Loadrunner”。

6.3.5 稳定性测试

网站稳定性是指在有特定“数据量”和“访问量”的前提条件下，可长时间正常运行。有些问题只有在运行一段时间后才会发现，做好网站的日志系统，记录网站在运行过程中的记录和错误日志，对这些问题进行分析并解决。

本系列目录：2011 年终项目总结

本文链接

[2011 年终项目总结] 第五章、迭代开发

2012-01-18T08:54:00Z

在本章开始前，先分享《软件架构师应该知道的97件事》有关开发的相关内容：

程序设计是一种设计（把编写代码看成设计行为，而不是生产行为）。
开发人员应该解决问题，而不是“解迷取乐”。
一行代码比五百行架构说明更有价值
让大家学会复用，避免重复（复制是魔鬼，重复性的工作拖累开发进度）。
先考虑原则、公理和类比，再考虑个人意见和口味。
模式病（使用模式解决适用的问题才是最重要的，禁止在项目中硬塞不必要的模式）
取舍的艺术，有舍才有得。
不要轻易放过不起眼的问题
确保简单问题有简单的解
起码要有两个可选的解决方案
现在走捷径，将来付利息。

本章主要介绍项目开发前的准备工作和项目所使用的开发模式。

5.1 准备工作

5.1.1 需求阶段

需求未完成

在其它部门进行需求分析时，技术部可以并行开始以下工作：

需求讨论会：项目负责人（架构师/项目经理/开发组长）应该参与产品主要功能的需求讨论，只有明确需求才能做好项目前期的架构，前期可以根据核心需求开始一些基础框架的开发。
团队技术选型：多数公司都是由“技术元老”来选择核心技术框架，或者根据第一个“招聘”的开发人员来决定技术框架，很多公司上层组织不会关心这个问题。我是被招聘过来的，所以肯定已经选择了.NET框架，个人认为选择.NET的主要原因是：相比PHP和JAVA，.NET在郑州更好招募，另外技术主管也是.NET出身。讨论“什么技术框架更好？”这个话题并没有多大意义，在现实环境中这些讨论都是浮云，闲着没事也可以参考“如何做好企业/团队的技术选型？”。
第二章、环境搭建：内部文档编写、开发环境搭建
技术储备：开发人员可以根据团队的技术选型，学习自己之前没有接触过的技术，比如有些前端开发人员在之前有可能没有用过 jQuery，或者不清楚JavaScript面向对象的写法。后台开发人员没有接触过ASP.NET MVC，或者不清楚ASP.NET WebForm自定义控件的开发等。这个阶段可以采用师父带徒弟的形式，由团队中熟悉这些技术的开发人员来指导没接触过的开发人员。避免选择一种大家都不熟悉的技术，这样会因为不了解此技术而导致后期不可预见的问题。
公共类库的开发：每个项目中都包括公共类库，如果团队是刚组建起来的，每个有经验的开发人员都会有套自己的公共类库。为了统一公共类库，项目负责人（开发组长/架构师/项目经理）应该组织大家共同协商公共类库的需求，并按照“开发规范”共同编写公共类库，具体需要注意细节请参考上一章“第四章、架构设计”。
尝试多种解决方案：针对网站的特殊功能，比如“搜索”，需要单独的解决方案来完成功能的开发。如果团队成员都没有成熟的搜索开发经验，就需要抽取专门人员去学习搜索技术，并至少提供两种搜索解决方案，比如我们团队中分别研究了 “HubbleDotNet”和“Lucene.NET”。
其它工作：内部培训、模拟协作、知识共享。

需求评审

在“第一章、团队建设”中，已经讨论了有关“产品文档评审会议”，再次强调“项目负责人”一定要重视。

功能分析

参考“第三章、功能分析”

架构设计

参考“第四章、架构设计”

5.1.2 项目里程碑

公司领导会决定公司的发展里程碑，而相关领导（总经理、产品总监、技术主管等）会根据公司里程碑决定每个项目（产品）的里程碑。具体的项目负责人（开发组长/架构师/项目经理）应该根据需求分析、开发文档、团队人员等条件来估算整个项目的里程碑。

时间估算注意

千万不能让领导（不懂技术）来估算项目完成时间，应该由项目负责人（开发组长/架构师/项目经理）来估算时间，估算时间的前提是必须了解整个项目的需求和架构，并且清楚团队每个成员的技术水平，一定要避免出现——别人豪言壮语“害”我或整个小组。
项目负责人应该规划整个项目的主要里程碑，并且为每个重要的里程碑规划时间，必要时要让团队成员加入共同估算时间。
公开项目里程碑，让整个团队以及其它部门也了解项目的整体进度。可以通过把重要里程碑打印出来，或挂到白板上，并更新每个里程碑的进度状态。
确定项目每个里程碑要交付的内容，让团队所有成员都知道每个阶段所要交付的任务。

注：项目里程碑的时间按排可以采用Microsoft Project、MindManager、Excel制定。

5.1.3 任务分配

分工明确

为了保证项目的顺利交付，在项目开始前，要对项目的功能模块进行合理化分，并合理分配功能模块，项目负责人要时刻关注项目的进度，和团队成员进行有效沟通。在项目开始时，针对这个问题我们做了以下工作：

分析项目：在 “第一章、团队建设”已经介绍了技术部各小组的职责和工作流程，但是 “后台开发小组”还分为“网站前台开发”和“网站后台开发”。在“第四章、架构设计”的第二章已经介绍了项目的逻辑架构，从中可以很清楚看出项目分为两大部分，而这两大部分所采用的开发模式也不同。首先根据团队开发人员的技术专长来划分任务，具备ASP.NET MVC开发经验的可以负责“前台”的开发，而具备企业级应用开发经验的可以负责“后台”的开发，因为后台需要了解ASP.NET自定义控件开发，以及 ASP.NET AJAX的使用。后台开发的技术门槛相对较低，可以采用师傅带徒弟（应届生）的形式开发。无论是网站前台还是后台，在项目开发开始前，需要项目负责人和团队成员共同开发基础框架，并且要由资深开发人员统一网站架构规范，定义从顶层到底层的代码架构风格，团队成员要共同讨论架构风格，并且达到意见一致，这样才能保证代码风格统一，出了问题也好改，并且每个功能模块可以交叉开发，有利于初学者从中学习到新的知识。
功能模块：经过分析项目，可以明确划分“前台”和“后台”两大块，在开始功能模块开发时，要保证基础施和公共类库已经开发完毕（基本功能，后期可以迭代增加。），并且已经统一了从顶层到底层的代码风格。此时可以由项目经理分配任务，也可以由开发人员选择自己感兴趣的功能模块。项目经理要保证项目的进度，合理划分任务。
独立模块：目前公司有两个产品线，两个产品线有公共模块（技术），有些模块（搜索、图片、视频）是由专人负责研究的。
人员变动：在任务安排的过程中，项目负责人需要考虑人员变动，做好代码规范、架构统一、交叉工作可以适量解决人员变动的情况。

代码走查

项目负责人应该走查每个开发人员编写的核心代码和算法，避免出现严重导致网站安全和性能的代码。在走查的过程中，如果发现开发人员“重复发明轮子”，比如：实现了一些公共类库已有的方法，这时可以把这些“轮子”合并到公共类库，或者进行相关的代码重构。

项目计划表

本次项目并没有采用具体的项目管理工具，而是使用表格的方法记录，跟踪项目的整体进度，项目计划表模板如下：

5.2 开发模式

在“第四章、架构设计”的第二节讲述逻辑架构，已经简单介绍了项目前台和后台的开发模式，本节会分享一些最佳实践。

　　5.2.1 前端

在项目开发中，好的前端设计对网站的性能、用户交互体验都很重要，也会提高后台开发人员的开发效率。在2011年，公司举办了河南郑州第一届“前端技术交流会”，详细的内容请移步“么么亲子前端建设与优化”，PPT里讲解了目前项目的前端架构。

5.2.2 前台

目前常见的开发模式有“表驱动开发模式”和“领域驱动开发模式”，我们采用的是第一种，当时也有考虑采用“领域驱动开发模式”，考虑团队人员的平均技能水平，另外互联网“展示型”项目本身业务逻辑都比较简单，所以还是采用了传统的开发模式。

　　.NET开发中常用的前端（网站UI呈现）开发模式可以参考：“有关网站UI实现的几种方式的讨论”，我们项目的前台采用ASP.NET MVC来实现，如下图“CMS.Web”结构：

整个前台架构比较简单，采用多层架构，前台具体项目结构如下：

多个产品

因为项目由两个产品组成，所以建立了两个“MVCWeb”项目，方便发布和部署。

MVCWeb

Razor：很好用的视图引擎
模板机制：利用ASP.NET MVC Razor 模板机制来实现布局重用，具体使用方法在“Shared”文件夹下创建模板文件，参考“ASP.NET MVC3: 通过Razor实现布局”。
@helper：能够方便创建可重用的帮助器方法，此方法可以在视图模板中封装输出功能。使代码能更好地重用，也使代码更具有可读性，参考 “ASP.NET MVC 3和Razor中的@helper 语法”。
@model：这个指令用一个简单而干净的方式实现视图文件对强类型模型的引用，参考“ASP.NET MVC 3: Razor中的新@model关键字”
使用Razor服务器端注释，而不采用Html注释，以免发布版本暴露项目信息。
推荐书籍：《Pro ASP.NET MVC 3 Framework》

MVC

为了使项目结构更清晰，把“路由、控制器、ViewModels、初始化”从“MVCWeb”中分离为一个单独的项目。

路由：在“第四章、架构设计”中的1.2.2节有介绍。
控制器：捕获路由的请求，完成前台业务逻辑的组装，调用“ViewModels”。创建“BaseController”，用于完成每个控制器的初始化工作，包括“override void OnException”的重写。
ViewModels：每个视图的数据提供者，调用业务层。
视图缓存：实现“IRouteHandler”，根据路由键从缓存中取出想要的数据，并根据配置输出客户端缓存信息。
初始化：完成网站程序初始化的工作，比如注册相关事件、公用缓存数据、读取配置信息、相关日志记录等。

Entity

很简单的一层，贫血实体类，只提供供数据传输，数据库表可以利用代码生成器辅助。

Business logic

网站程序的业务逻辑层，为“ViewModels”提供数据，完成Controller的操作和数据库访问层的调用，也包括数据缓存的添加和更新。

DataAccess

参考“第四章、架构设计”的1.2.4。

　　5.2.3 后台

网站后台采用“ASP.NET WebForm”，为了提高开发效率，后台基础代码编写了“代码模板”，采用“CodeSmith”来生成基础代码，具体业务逻辑代码是继承在生成代码之上，防止重复生成覆盖手写的代码。网站后台项目结果图如下：

WebForm

参考“第四章、架构设计”的1.2.2，项目负责人根据后台需求，分析产品经理所需要的权限模型，把后台管理框架划分为“三级”，然后提练出后台项目的几种“页面操作模板”和“常用显示效果”。美工会根据这些需求来提供效果图，然后由开发组长和前台小组负责人沟通并实现管理框架的静态效果，并提供相关交互效果的API调用方法。为了更好的实现管理框架和方便以后的快速开发，目前采用了WebForm中的以下技术：

模板页：根据后台管理框架，提出页面公有部分封装为模板页。
用户控件：重用页面模块
自定义控件：把后台管理框架中的基础元素都封装为自定义服务器端控件，并增加相应的服务器端事件。把不包括具体业务逻辑的公用组件封装为自定义服务器端控件，反之封装为用户控件，可以参考Discuz!NT源代码中部分自定义控件的设计。
页面生命周期：后台管理的所有页面都包括了权限控制，目前采用“页面基类”形式控制每个页面的访问权限和相关初始化操作：

Common

该项目主要包括网站后台的公用模块，比如：

后台管理页面基类
后台公用业务逻辑：文章状态的枚举类型、每个后台管理模块的编辑模板等。
后台公用工具库：分页算法、文章状态的枚举类型
前台缓存更新服务操作集合

TaskService

网站后台除了要完成整个内容区项目的内容管理外，还要包括一些自动化作业处理的开发，此项目是以Windows Service部署在数据库服务器，它会定时完成一些网站业务的统计并更新到数据库当中。

PS：本意想把项目部分代码贴出来，发现代码有太多的上下文关系，年底了，也没有太多时间建立空白项目，针对一些问题我会找一些不错的博文来参考，年后有机会分享。

本系列目录：2011 年终项目总结

本文链接

[2011 年终项目总结] 第四章、架构设计

2012-01-08T04:12:00Z

有关架构的概念和其重要性此处就不再详细讨论了，在很多社区和书籍中都有介绍过。在这里推荐两本书，分别是《企业应用架构模式》和《Microsoft.NET企业级应用架构设计》，其中，第二本适合.NET开发人员来看。另外，选择不同的网站后台语言就意味着不同的架构路线和不同的开发框架，我们使用的开发语言和相关软件技术，已经在第二章中有过介绍。

互联网项目（门户、社区、电商等）在初期架构阶段，首先，要分清楚项目所针对的人群有哪些，并根据需求分析和上线后的推广力度来估算有多大的访问量；然后，负责架构的人员根据这些资料设计架构粒度。现在投资互联网项目的成本都很大，已经不像几年前买个虚拟主机就可以搞定了。所以，前期一般不会把架构搭的很大，或者买很多服务器来支撑这个架构。但是我们可以根据需求设计一套可灵活扩展的架构，然后根据项目的市场发展状况来扩展架构，两位圈内名人曾讲过这样的话：

高德纳：过早优化是万恶之源
冯大辉：好的架构和最初设计有关系，但最重要是发展中的演化。

本章分别从“物理架构”和“逻辑架构”两方面来描述目前项目的架构设计。

1.1 物理架构

我理解的物理架构也可以称之为宏观架构，主要包括硬件与网络的部署策略、整体架构硬件的可伸缩性、安全以及性能上分析。下图是目前项目的逻辑架构视图，此图虽没有把相关扩展点画出来，但是会给大家介绍哪些是可以在后期进行扩展。

1.1.1　客户端缓存

关于客户端缓存应该属于网站优化方面的知识，随着互联网技术的发展和客户端浏览器的支持，有效的利用客户端缓存可以为服务器减少很大的压力。客户端浏览器根据每个HTTP请求的Header信息来决定当前请求的资源是否需要缓存，目前项目的客户端缓存分为“动态页面”和“静态资源”两种：

动态页面：由ASP.NET MVC输出，根据需求为每个所输出的页面设计缓存策略，比如：网站总首页会在客户端“相对”缓存5分钟，而文章会缓存10分钟。如果服务器端对缓存页面内容更新后，可以通过改变“ETag”值来强制更新客户端缓存。
静态资源：包括“脚本文件、样式文件、网站图片、静态页面（404、专题等）”，目前这些文件都存储在“静态资源服务器”，可以通过Web服务器的批量设置调整资源文件的客户端缓存，不同的Web服务器需要不同的配置，大家可以根据需求去Google。

有关“静态资源”在客户端缓存的强制更新，可以通过版本号的形式来强制更新客户端缓存，比如：

1.1.2　防火墙

硬件防火墙的主要功能可以参考百度百科，这里介绍此项目正在使用的几个主要功能：

内网端口统一屏蔽：防火墙对外网服务器（IP）只开放80端口（目前需求），虽然操作系统本身也具备防火墙功能，但是配置比较麻烦，又不统一。
外网和内网IP的映射：在防火墙内配置了外网和内网（公网千兆交换机）的IP规则对应，浏览者通过外网访问会直接转换为内网IP进行访问。
VPN：如果需要通过外网管理内容区网站或者远程管理服务器，就必须通过VPN进行连接，连接成功后会自动分配内网地址，然后才能对服务器进行管理。

注：在购买防火墙时，要根据需求查看防火墙所支持多大的“吞吐量”，因为它是测量防火墙性能的重要指标。

1.1.3　公网千兆交换机和内网存储交换机

公网千兆交换机

当外网请求过来时，防火墙会把其转换为内网请求，通过公网千兆交换机访问具体内网服务器，根据IDC提供的带宽，这里配置“千兆”已足够。

内网存储交换机

目前所有服务器都会有一块网卡接着内网存储交换机（万兆），服务器上的所有数据（除系统文件和程序文件）都是通过“iSCSI”协议存储到“存储设备”上的。

1.1.4　Web服务器

一个网站最重要的就是Web服务器，因为它会把数据转换为页面（HTML）返回给浏览者，这种说法仅限于目前的环境。在SNS区，Web服务器后面是由多台应用程序服务器组成。为了减少成本，现在项目只有一台Web服务器，但是此台服务器上运行了多个站点和服务，后期可以根据访问量，把这些站点和服务扩展到另外的服务器上。此台服务器的系统环境和所运行的服务如下：

操作系统：Windows Server 2008R2 x64
Web服务器：IIS 7、.NET Framework 4、ASP.NET MVC 3+Razor
运行站点：内容区网站、内容区百科、内容区搜索服务

为了方便扩展，不同的站点都由不同的域名划分，同时也运行在不同的应用程序池当中。需要注意的是，Web服务器不会存储任何有关共享资源和用户的相关数据，所有资源都是通过绝对路径访问其它服务器上的内容，这样就方便以后为某个站点或服务增加负载均衡。有关负载均衡可以通过软件（Nginx）、硬件（F5）或DNS轮循等几种方案来实现，因为硬件比较贵，所以我们在内部针对Nginx做过测试，在分离以上站点时，可以正常运行。很多大型站点是采用“混合型负载均衡”——以上几种方案都会使用。如果考虑到今后会使用负载均衡，在初期架构时，就要首先解决所有和状态有关的问题，比如用户登陆和验证码状态，在我们 SNS区架构时，就要考虑采用专门的状态服务器来存储这些内容。

301跳转：很多网站都会申请一些保护域名，并把这些域名转向到主域名上，我们的解决方案是在IIS上建立多个空站点，然后设置所有请求都转向到主域名站点上。

下面分享一些关于IIS7配置方面的资料：

错误页设置：如果采用“集成模式”，一定要把网站错误地址写成绝对地址，比如（http://stat01.xxx.com/404.html），如果网站启动过程发生错误，这时就会导致错误死循环。
启用动态压缩（GZIP）：http://www.cnblogs.com/ntwo/archive/2011/01/10/1932081.html
多个进程处理一个应用程序池设置：WebGardens 特别功效：降低CPU占用、Web Farm和Web Garden的区别？
IIS默认连接数设置：让Windows Server 2008 + IIS 7+ ASP.NET 支持10万个同时请求
权限设置：http://www.cnblogs.com/limshirley/archive/2011/05/17/2049039.html
IIS7教程：http://msdnwebcast.net/webcast/8/1970/

1.1.5　缓存服务器

当网站没有应用缓存时，每一个动态页面的访问请求，都需要通过连接数据库，执行相关数据查询，最后返回给客户端。这样无疑增加了服务器的压力，并且数据库连接是相对耗时的操作。在服务器端可以通地以下方式实现缓存：

Web服务器：不同Web服务器的缓存设置方法不一样，Nginx和Squid都可以通过配置文件来设置资源的缓存，IIS也可以同时开启“静态资源”和“动态内容”的缓存（GZIP）。
ASP.NET MVC：可以通过Action的OutputCache属性来设置缓存的类型和时间。
自定义缓存：根据网站自身的业务逻辑来使用缓存，把一些业务数据存储在缓存当中，可以使用ASP.NET中的“System.Web.Caching.Cache”来管理缓存，或者使用第三方缓存“Memcache、Redis”。

缓存模块设计

在设计缓存模块时，我们定义一系列的缓存操作接口，使用者（Web服务器）并不清楚缓存模块当前所采用的是哪种缓存方案，使用者只需要调用具体的方法来管理缓存。缓存模块在初始化时会根据配置文件来决定当前系统需要使用哪种缓存方案，目前系统支持ASP.NET Cache、Memcache、Redis三种缓存策略，三种缓存策略在不同的部署环境都有各自的优势。

ASP.NET Cache：网站初步上线时，当没有单独的缓存服务器，并且访问量和缓存数据量都不是太大时，就可以采用ASP.NETCache缓存策略，因为它相对于后两种是最快的。缺点是它和应用程序池在一个进程当中，网站重启或应用程序池崩溃都会导致缓存直接丢失。
Memcache：弥补了第一种的缺点，支持分布式，很多大型网站都在使用。缺点是，如果在访问量高峰期出现了缓存雪崩，就会导致缓存大量失效，同时数据库服务器将承受巨大的压力，严重的话会导致整个网络集群的瘫痪。
Redis：可以用来做缓存服务器，支持数据持久化，把缓存中的数据定期存储到磁盘上，目前，国内新浪微博正在使用此技术，我们只是尝试使用了它的缓存功能，并没有它的NoSQL特性。

缓存策略

缓存是一个好东西，但是如果我们错误的使用了它，就会带来意想不到的麻烦。在实践当中，我总结了以下常见的注意事项：

缓存键的设计：一般缓存键都是以常量的形式存储在类中，这样就会方便调用，并且缓存键常量是采用模板形式，灵活度比较高。如果要设计更为灵活的缓存键，可以参考Discuz!NT的设计。
缓存对象粒度：缓存粒度的原则当然是越小越好，但是这样就会增加组装环节。根据业务逻辑灵活控制缓存对象的粒度，减少缓存中的数据冗余。
缓存管理：网站启动时，会把必要的初始化数据放入缓存中，其它的数据是在第一次访问时存储到缓存当中，在网站后台会有缓存的主动更新和强制更新功能。

1.1.6　数据库服务器

目前网站的数据存储在一台数据库服务器上，采用 “SQLServer 2008 Enterprise Edition (64-bit)”数据库。考虑到后期的扩展，前期规划时需要完成以下工作：

模块分库：根据内容区的产品模块，进行合理的分库，方便以后根据需求把这些数据库部署到不同的数据库服务器上。
读写分离：当数据库访问量很大时，可以把数据库部署到不同的数据库服务器上来解决压力，但是当某个模块数据库服务器压力过大时，可以通过读写分离来解决数据库服务器的压力，SQL Server可以通过发布订阅来解决这个问题，但是网站程序的数据库访问层也需要提供支持，把不同的读写业务逻辑分发到不同的数据库服务器上。第一种方法是在读写业务逻辑中调用不同数据库连接字符串。另外一种方法，前期规范好存储过程和SQL语句的书写标准，在数据库访问组件中根据最终执行的命令，分发到具体的数据库服务器，比如所有“select”都分发到“读”数据库服务器，而所有“Update、Delete”都分发到“写”数据库服务器上。随着业务的增加，如果存在多台“读”服务器时，就需要考虑数据同步延时的问题，可以根据具体情况来解决，比如：当用户刚添加一条评论时，在客户端增加一个标记，在几分钟内他的所有读操作都分发到“写”数据库上。
负载均衡：如果存在多台“读”数据库服务器时，需要在数据库访问组件上增加负载均衡的功能，目前项目只是简单实现了“轮循算法”，也可以在算法中为每个数据库器连接字符串增加“权重”值。

安全设置

在开放的互联网环境中，互联网项目第一个要谈的就是安全问题，根据项目的不同，安全的侧重点也不一样。在保证操作系统本身的权限划分和漏洞升级后，在“第六章、内部测试”会讨论网站程序所需要的安全测试。在保证网站程序没有安全问题外，还要保证数据库服务器的访问安全性，我们分别从以下几个方面来确保数据库服务器（SQL Server）的安全性。

隔离原则：在防火墙内隔离数据库服务器，禁止外部链接，并在数据库服务器操作系统防火墙中设置只允许网站程序服务器连接，修改默认连接端口。
权限分配：首先关闭没有用的数据库账户，对数据库文件所在的文件夹设置操作系统级别的权限分配。针对不同的网站程序，分配不同的数据库访问账号，并根据不同的业务逻辑为不同的账号分配不同的执行权限。比如：网站前台程序所拥有的数据库账号只有执行“特定存储过程”和“特定表”的查询操作，并不具备创建、删除表的操作，更没有查看数据库有多少表的操作。
数据加密：第一、对网站程序的配置文件进行加密，防止Web服务器被攻破后拿到明文的数据库连接账号。第二、对必要的“数据列”进行加密，不做明文存储，比如会员表的密码字段，并且不能用简单的加密方式进行加密，防止碰撞破解，保存好加密干扰字符，并定期更新干扰字符。
最小化运行：只开启网站程序业务所需要的SQLServer服务。

备份机制

SQL Server已经具备了很强的备份功能，可以设置作业进行定时备份，根据需求选择具体备份策略，具体操作可以参考这篇文章“SQL Server 维护计划实现数据库备份”。

数据镜像和同步

当网站“主数据库服务器”发生问题后，网站程序需要自动切换到另外一台正常工作的数据库服务器，这时可以采用主从数据库镜像的方案，网站程序的数据库访问组件只需要配置主数据库的连接字符串，就可以做到主从镜像自动切换，具体配置方法可考MSDN或者“SQL Server 2005 镜像构建手册”。如果只是需要在主数据库服务器发生问题后，手动切换或者开启另一台工作的数据库服务器，可以采用数据库复制的方案，具体配置方法参考“通过SQL Server 2008数据库复制实现数据库同步备份”。

1.1.7　静态资源服务器

前端优化中最好做的就是动静分离，在前期项目规划时就应该在内部搭建动静分离的开发环境，在项目中采用绝对路径和前端进行协作开发。如果前期只有一台服务器，可以在服务器上建立多个站点存放静态资源。静态资源服务器可以采用的CentOS系统，使用高性能的Nginx作为Web服务器。

缓存和压缩

调整Nginx的配置，为静态资源增加客户缓存输出，并且可以把静态资源存入到Nginx内存当中，当然也可以使用Squid来做。关于静态资源的压缩，推荐使用“UI Compressor、Google Closure Compiler）”。如果有更高的区域性需求，可以使用第三方 CDN来做。

1.1.8　图片浏览服务器

独立图片浏览服务器原因同上，图片浏览对于内容型网站来说是很重要的功能，在前期规划时需要注意以下事项：

图片上传：后台程序会把编辑上传的图片通过内网发送给图片上传服务，图片上传服务根据后台上传需求进行上传并保存图片，返回上传成功后的图片路径和文件名。图片上传服务具备如下功能（缩略图、水印、版权、保存Exif信息到数据库）。
目录规划：根据需求设计图片的存储机制（路径、文件名）以及原图片的备份，对后期的扩展很重要。
数据分析：图片上传成功后，会把图片的所有Exif信息存储到数据库中，方便后期进行数据分析。
图片访问：对图片的访问增加防盗链功能，采用“HttpHandler”来实现，目前为了良好的体验，考虑到图片都是编辑上传的，不会造成大量的恶意引用，此功能暂没有开启。

1.1.9　内容区后台管理服务器

基于安全和程序架构的原因，内容区前台和后台项目是分开部署的，并且采用不同的开发框架。内容区后台是单独部署在一台服务器上，管理员需要通过VPN才能登陆管理后台，并且后台采用HTTPS登陆。

1.1.10 数据存储设备

以上所有服务器的数据存储都分为两种：

原始数据：操作系统和应用程序所需要的文件是存储在本地硬盘上的，应用程序主要包括杀毒软件、运行环境和软件工具。
用户数据：网站程序所产生的数据和文件都是通过“iSCSI”协议存储在内部存储设备上的，后期根据发展会购买专门的存储设备，采用“FC HBA卡”进行数据传输。

单独的存储设备是防止服务器系统或者服务器硬件坏掉时，不需要单独从硬盘中把数据复制出来的麻烦，只需要启动一台新服务器连接到内部存储设备就可以正常运行了。

1.1.11 其它

远程管理卡

主要方便“运维”通过远程监控服务器（开机、关机）的重启过程，当然也可以远程管理操作系统。

管理工作站

一台远程管理服务器，安装 “VMware”系统，虚拟化了多个操作系统，方便安装相关监控和日志分析软件。

摄像头

监控机柜在IDC机房的动静。

1.2 逻辑架构

逻辑架构从某种程度来看是物理架构的实现，但不仅限于此。它需要考虑功能的重用性与可扩展性、服务接口的定义，并定义整个系统的架构风格。

在分解复杂的软件系统时，软件设计者用得最多的技术之一就是分层。当用分层的观点来考虑系统时，可以将各个子系统想像成按照“多层蛋糕”的形式来组织，每一层都依托在其下层之上。在这种组织方式下，上层使用了下层定义的各种服务，而下层对上层一无所知。另外，每一层对自己的上层隐藏其下层的细节。——《企业应用架构模式》

一般软件系统都是有“表现层”、“领域层”、“数据源层”组成，当然我们的系统也是：

1.2.1　基础设施和公共类库

公共类库

统一公共类库的目的是为了方便团队使用一致的“公用方法”，所有能提练出来并与业务逻辑无有关系的“公用方法”。公共类库与业务逻辑无关，公司的所有开发小组都可以使用，并长期对它进行维护。在开发公共类库时注意以下几点：

不求多而全，但要精而强，每个方法要求有详细注释和具体使用方法（测试用例）。内部要提供API清单，方便新人查看有哪些方法，免的重新制造轮子。
避免从网上直接下载使用，必须经过代码审查和测试。
规范类库和方法的命名规范，方便开发人员记忆和使用。

目前项目的公共类库包括：工具函数库、Web请求处理库、XML操作库、IO操作库、脚本输出辅助库、常用算法库（加密、过滤等）。

系统日志

在第三章的功能介绍中，已经详细介绍了日志系统的功能和作用，系统日志项目的具体设计如下：

ILog：日志记录操作的接口。
FileLog/XmlLog：具体日志记录操作的实现，目前支持“文本文件”和“XML文件”。
LogInfo：日志信息和日志级别。
LogInfo：日志系统的业务逻辑，常用日志记录方法。

系统配置

访问配置文件的接口，详细功能在第三章有介绍。

数据缓存

上一节介绍了缓存的具体设计，数据缓存项目的具体设计如下：

ICacheHelper：数据缓存操作的接口。
CacheStrategy：具体数据缓存操作的实现，目前支持“ASP.NET Cache、Memcache、Redis”。
CacheHelper：数据缓存的业务逻辑，每个系统的具体缓存业务逻辑都存储在各项目中，方便数据缓存项目的复用。
CacheKeys：公共缓存键。

1.2.2　表现层

内容区前台（ASP.NET MVC）

ASP.NET WebForm的缺点在网上也都有讨论，目前很多采用ASP.NET的互联网项目都是自己来实现“HttpHandler”做项目，不再使用ASP.NET自带的页面模型。微软也已经意识到了这个问题，这才有了ASP.NET MVC框架，ASP.NET MVC主要取代项目中的表现层，下面分享我们用它都做了什么：

Razor：ASP.NET MVC支持自定义视图引擎，自带了Razor，上手快并且有很好的智能感应输入提示支持。
ASP.NET Routing：在之前的ASP.NET项目中，大家都采用第三方URL重写组件来实现更好的URL设计和SEO(盲目)优化，ASP.NET MVC中已经解决了这个问题，当然在ASP.NET 4.0 WebForms中也可以使用。具体讨论可参考“ASP.NETRouting相关”
XmlRoute：ASP.NET MVC默认路由规则是存储在“Global.asax.cs”中，也可以通过扩展把规则存储在XML中，具体实现参考“ASP.NET MVC Routing Using XMLCustom Configuration Settings”。
Ajax：在ASP.NET MVC中，Action可以返回多种丰富类型的结果，这样就不需要在传统ASP.NET中实现“HttpHandler”或创建“ashx”，也更方便我们来开发API。
重写输出：为了更好的控制页面缓存和客户端缓存，我们重写了ASP.NET MVC默认请求和输出，在请求时根据当请求的路由判断是否已经缓存并输出，输出时根据客户缓存策略输出对应的HTTP Hearder。

内容区后台（ASP.NET WebForm）

ASP.NETWebForm自有它的缺点，当然也有它存在的优点，合理的使用可以有效的提高开发效率和代码重用。

Code-Behind：使用ASP.NET WebForm的页面模型和服务器端控件(自定义)，可以快速开发应用系统，当然也会带来性能上的瓶颈，内容区后台只有内部人员使用，性能问题暂不考虑。
自定义服务器端控件：我们没有直接使用ASP.NETWebForm自带的控件，而是根据“效果图”和“前端交互”封装了所有控件，把常用的组件也封装为自定义控件，比如：图片上传控件、分类选择控件、超文本编辑器控件、数据显示控件(Repeater)等。
ASP.NET Ajax：后台开发并没有专业的前端人员来编写Javascript实现Ajax效果，所以采用ASP.NET Ajax更适合我们在ASP.NET WebForm下开发。

1.2.3　服务层

　　处理领域逻辑的常见方法是将领域层再细分成两层。服务层独立出来，置于底层的领域模型或表模块之上。通常只有使用领域模型或表模块时才会这样细分，因为仅使用事务脚本的领域层并不复杂，没有必要再单独设服务层。表现逻辑与领域层的交互完全通过服务层，就好像应用程序的API一样。——《企业应用架构模式》

从逻辑架构视图上可以很清楚看到，内容区前台和后台的服务层架构也是不同的，前台的服务层主要有“ViewModels”和“Business logic”组成，而后台只有“Business logic”，后台很多页面逻辑已经在“Code-behind”中完成了。

在“第五章迭代开发”会分享服务层的一些最佳实践。

1.2.4　数据访问层

　　数据库访问层是完成服务层的具体实现，执行相关的存储过程或脚本命令，并以表模块或者对象（Data Mappings）的形式返回给服务层。如果项目有“读写分离”需求，就需要根据具体的业务逻辑在数据访问层把具体的操作路由到具体的数据库服务器，可以通过调用数据库访问组件来实现，但前提是数据库访问组件必须支持多台数据库的操作。

前台：存储过程、对象映射
后台：脚本命令、表模块(DataTable)、对象映射

注意：所有数据库访问操作都必须采用参数化传递，防止SQL注入，采用using来使用DataReader对象。

1.2.5　数据库访问组件

在项目中，数据库访问组件也属于“基础设施层”，因为它是一个统用的组件。在项目中，并没有采用第三方ORM框架来实现数据库访问，主要是为了后期扩展考虑，使用ADO.NET可以灵活的实现读写分离、负载均衡，也方便日志记录和异常信息的捕获。

在开发数据库访问组件时，需要以下注意事项：

数据库访问组件是决定性能最重要的一层，每一行代码都要经过思考。根据需求进行设计，比如架构路线已经决定采用了SQL Server数据库，就不要盲目设计让数据库访问组件支持多种数据库。
增加错误日志记录功能，当数据库操作发生错误时，应该及时记录错误日志并通知管理员。
合理使用using，避免打开数据库连接后没有关闭，这样会导至数据库表加锁或占满默认连接池数目。（利用SQL Server的活動監視器(圖形化介面)瞭解Connection Pool運作）
支持事务操作、参数化传递。
性能测试，数据库访问组件开发完毕后，所有功能都必须经过严格的测试，并且根据需求进行压力测试，编写多种场景的测试功能并对这些功能进行压力测试。

本系列目录：2011 年终项目总结

本文链接

[2011 年终项目总结] 第二章、环境搭建

2012-01-04T12:11:00Z

“工欲善其事，必先利其器”，在具备好的协作团队的同时又具备有好的开发环境，当然会事半功倍！本章将为大家介绍我们的技术团队在协作的过程中所用到的软件环境。

2.1　基础文档

无规矩不成方圆，如果按照CMMI最低标准流程执行的话，我们在软件开发过程中就会产生数不清的文档，而在敏捷软件开发中，更强调则是程序员团队与需求专家（产品经理）之间的紧密协作及面对面的沟通（认为比书面的文档更有效）。我认为，在正式写代码之前，有些文档是必须要准备的，有些东西也必须要标准化、流程化，这样才能减少错误的发生，或者是在发生问题时，可以更快、更有效地解决问题！

在上一章介绍了每个技术小组需要使用的内部文档，而这些内部文档需要在开发前就约定好，并在实际开发过程中得到优化，下面将简单介绍这些文档所包含的内容。

2.1.1　前端组

《html&css前端开发规范》：包括了Html标签的书写规范和CSS命名规范，共同约定了一些技巧和使用注意事项，同时也规定了各种注释规范（文件、块、行）。

《javascript前端开发规范》：js是前端使用的主要网页脚本语言，同其它编程语言一样，需要大家统一编码习惯，比如命名规则、变量定义原则、代码缩进格式、注释等。

2.1.2　开发组

《编码规范（C#版）》：C#是开发组的主要编程语言，但由于团队是刚组建起来的，所以每个人的编码风格都不一样。此文档主要来约束大家的命名规范、注释规范、特殊技术使用规范等，但并不限制某个功能必须采用某种技术或算法来实现。我在编写文档时也参考了网上的很多资料，大多都不统一，也不太规范，最终参考了《.NET 设计规范--.NET约定、惯用法与模式》来编写此文档。

2.1.3　数据库组

《数据库管理规范》：主要包括数据库对象（数据库、表、字段、视图、索引、触发器、函数及存储过程）的命名规范，还包括脚本格式的统一（存储过程、注释）和数据库安全管理的注意事项。

2.1.4　测试组

《BUG流程管理》：主要介绍BUG在内部协作过程中，从产生到解决的流程，也规定了BUG级别和各种BUG状态的处理方法。

《BUG管理工具说明》：介绍JIRA的使用方法和注意事项。

2.2　协作环境

2.2.1　版本控制

在软件开发领域，版本控制系统已经成为每个技术团队首要搭建的环境。以下引自维基百科，版本控制（Revision control）是维护工程蓝图的标准作法，能追踪工程蓝图从诞生一直到定案的过程。此外，版本控制也是一种软件工程技巧，借此能在软件开发的过程中，确保由不同人所编辑的同一程式档案都得到同步。”

在我们团队中，存在两种版本控制，一种是文档版本控制，它的具体格式主要体现在文件命名上，比如：《***网站（内容区）开发规格说明书_V1.0.9_2011-11-03》是由“文档名称+版本号+更新时间”组成的。另一种则是源代码版本控制，它是用于存放内部产品的整个生命周期所需要的文件，我们内部的版本控制系统采用的是”Subversion”。

版本控制是一个很大的话题，在部署版本控制系统前，我们需要分析产品和内部人员的架构，并根据需求来建立版本库和划分权限，这样即有利于后期的扩展，也方便大家协作开发。另外，还要考虑版本控制系统所在服务器的备份。现在，来分享我们一个产品的目录存储结构，我会附加说明每个文件夹的作用。产品目录结构如图：

CMS：内容区产品

---V1.0.0:以大版本号划分文件夹，只有在重大改版或架构变化时，则升级为“V2.0.0”。

------BackgroundDev：开发组文件夹

---------1_Doc：项目开发组文档，包括开发规范、功能说明、架构设计、进度控制等。

---------2_SourceCode：项目源代码目录

---------3_Test：包含一些功能性临时测试项目

---------4_Release：产品发布文件夹

------------Alpha：内部测试或内部使用版本

------------Beta：线上测试版本

------------Release：最终V1.0.0发布版本

---------5_Update: Release版本的升级包

---------6_Other：第三方插件、学习资料和一些快速开发代码生成模板。

------DataBaseDes：数据库组文件夹

------FrontEndDev：前端组文件夹

------ProductDes：产品组文件夹

------Release：所有小组的Release备份

------Update：所有小组的Update备份

注：这里只说明开发组文件夹”的目录结果，其它小组则根据需求设计文件目录。

以下是搭建环境所用到的工具：

服务器端

VisualSVN Server：之所以使用它，是因为它集成了”Subversion”，并支持图形化配置界面，方便SVN版本库的建立和用户权限的分配，同时支持Windows Server 2008，另外也是免费的。

官方地址：http://www.visualsvn.com/server/
下载地址：http://www.visualsvn.com/server/download/

客户端

TortoiseSVN：集成操作系统的资源管理器，方便更新和提交，官方网站提供中文包下载。

官方地址：http://tortoisesvn.net/
下载地址：http://tortoisesvn.net/downloads.html

Ankhsvn：将Subversion的操作集成在Visual Studio的SVN Client软件，支持Visual Studio 2010。

下载地址：http://ankhsvn.open.collab.net/

Dreamweaver CS5：集成了SVN客户端工具，具体使用方法可以Google。

2.2.2　环境模拟

在正式开发之前，我们会根据产品的架构设计（物理架构），在团队内部搭建一个产品发布后（IDC）的同样的运行环境，以方便开发人员调试程序。针对内容区的产品，我们一共搭建了三套环境，“分别是开发环境”、”测试环境”、“内部使用环境”，下面介绍每个环境的用途。

开发环境

主要方便开发人员自己测试程序，在发布给测试组时，首先要部署到内部开发环境查看是否能正常运行，同时也可以和测试环境部署的程序进行对比，来确认某个问题是环境引起的还是程序本身的问题。内容区是由多个子产品和多个开发人员组成的，各个产品会相互调用，这样就方便大家查看对方程序的运行效果。

测试环境

当产品发布新版本时，测试组会从版本控制系统中提取最新版本，然后部署到测试环境进行测试。注意，所有环境的数据库并不是共享的，这样大家每次都不需要初始数据，因为有些BUG是由数据引起的。

内部使用环境

这个环境其实是没必要部署的，但是内容区项目比较特殊，根据内部进度，要求网站在上线前必须具备运营所需要的数据。由于我们在开发进度上，要求内容区的后台管理系统的部分功能，在开发阶段就要提供内部使用版本，并提供给内容部”使用，所以就临时部署了这个环境，其实这个环境还是有用的，因为它是用真正数据来运行的，可以覆盖测试环境测试不到的问题。此环境在网站上线后就撤销了，测试部门直接从线上导出数据，并部署到测试环境来测试。

注：上述几个环境并不是和线上机器同样配置的环境，而是用虚拟化模拟出来的，但是针对一些特殊测试场景会做特殊处理，比如压力测试。

2.2.3　虚拟化

关于虚拟化在互联网产品开发中的重要性，请大家看一篇文章的介绍，里面的内容也都是我想表达的，文章标题为”虚拟化——互联网时代的产品开发加速器”。我们团队中使用微软的“Hyper-V”来实现虚拟化，关于“Hyper-V”的使用大家可以参考MSDN，其实和装虚拟机一样，只是在分配是要考虑到硬盘空间和内存大小，最大化的使用主服务器，微软也提供了“Hyper-V”的客户端管理工具，可在官方网上下载。

上一节所提到的“环境模拟”都是用虚拟化来实现的，除了产品测试所需要的机器外，我们还给每一位开发人员分配一台虚拟测试机，以方便程序开发和测试。在互联网产品开发中，浏览器兼容性是前端开发很头疼的问题，为了能模拟客户最终浏览的效果，我们虚拟出了各种操作系统的默认浏览器版本，来方便开发和测试人员测试网站。

注：“Hyper-V”对有些Linux版本的系统兼容性不是太好，内部有关Linux系统的虚拟化采用“VMware”来实现。

2.2.4　Bug管理系统

我们的技术团队采用JIRA来做“Bug跟踪”，JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。目前我们只使用它来管理内部产品 BUG，另外在JIRA平台上还安装了“Subversion JIRA plugin”插件，可以和内部源码管理工具结合起来，方便查看BUG所对应的源代码文件。

合理的使用JIRA可以为项目管理和产品版本的发布带来很多好处，在开始使用JIRA平台前，测试负责人需要给开发人员进行培训，使其并养成一些良好的习惯，在这里分享一些从测试组学来的经验。

分析公司产品的规划，合理在JIRA建立项目分组，比如内容区项目“可以分开建立为内容区前台”、“内容区后台”、“内容区前端”三个项目组。
把各项目细化为功能系统，每个功能系统对应某个开发人员，这样更方便管理Bug。
测试人员在提交Bug前要理解当前Bug属于哪个项目和哪个功能系统，并正确选择当前Bug所属的项目版本号。
开发人员在解决Bug时，一定要填写备注并正确选择Bug处理状态。
开发人员在提交源代码到版本控制系统时，除了填写当前源代码备注外，还需要加上Bug编号，这样就可以在JIRA中查看Bug对应的源代码文件了。
在填写Bug内容时也有很多学问，这个测试人员更有经验，比如加上Bug所在页面的链接、配上图片、Bug级别的选择等。（内部文档有相关规定）

有关JIRA的相关资料请参考以下链接：

官方网站：http://www.atlassian.com/software/jira/overview
中文演示：http://www.jira.cn
Subversion JIRA plugin：https://studio.plugins.atlassian.com/wiki/display/SVN/Subversion+JIRA+plugin
论坛讨论：http://www.fangwai.net/bbs/

2.2.5　内部通信

企业邮箱

目前，通过腾讯企业邮箱来实现内外的邮件沟通，客户端可以使用Foxmail、OutLook、网易闪电邮，当然也可以绑定QQ邮箱。

官方地址：http://exmail.qq.com/

RTX

内部通信使用腾讯企业RTX，方便分组和人员架构，就是功能太弱了，用户体验还较差！

官方地址：http://rtx.tencent.com/

2.3　开发环境

2.3.1　开发工具

C#
ASP.NET 4.0
ASP.NET MVC 3、Razor
HTML5
jQuery 1.6.3
Visual Studio 2010 Professional、Ankhsvn
Adobe CS5、EditPlus

2.3.2　使用的软件和技术

Windows Server 2008 R2 x64（Web版和企业版）
SQL Server 2008 R2 running Microsoft Windows Server 2008 Enterprise Edition x64
CentOS
IIS 7
Nginx
Memcached：正移植到Redis
HubbleDotNet：全文索引
CKEditor
JIRI
VisualSVN Server
TortoiseSVN
Hyper-V、VMware
Cruise Control.NET
Cacti：安装了Nagios插件
iDRAC：DELL远程管理卡
SolarWinds
Symantec Endpoint Protection：赛门铁克

2.3.3　第三方技术服务

Google Analytics
Apple Mobile Web Clips Icon
监控宝

2.4　持续集成

2.4.1

CC.NET 有关持续集成的概念和理论知识请参考《持续交付--发布可靠软件的系统方法》，目前团队还在规范化发布流程，以后会引用CC.NET来自动化这些操作，有关CC.NET的具体使用方法，园子里很多人都分享过。

本系列目录：2011 年终项目总结

本文链接

[2011 年终项目总结] 第一章、团队建设

2012-01-03T11:12:00Z

三年前，我见证了一家互联网电子商务公司从创业开始到最终结束的整个过程，这家公司失败的根源问题是没有做好产品的推广（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 年终项目总结

本文链接

2011 年终项目总结

2012-01-03T11:05:00Z

2011已悄然逝去，充满未知的2012正等待着我们去探究。为了更好地经营、打造未来的一年，我们有必要对过去一年的经历进行一下总结、反省，因为只有对过去不断地总结与思考，才能从中获得宝贵的经验，为未来的发展做好基础。以下是我2011年的年终项目总结：

PS：给大家分享一下 2011年读过的几本书。

本文链接

[读书笔记]软件架构师应该知道的97件事

2011-12-30T10:26:00Z

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、优秀软件不是构建出来的，而是培育起来的。

设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。注意，不要把这种演化式方法和削减需求、规范混乱和生产废品这样的做法混淆在一起。

本文链接