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

　　在本章开始前，先分享《软件架构师应该知道的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 年终项目总结