做最好的自己

概述部分

Check        描述

                  文档版本

                  更新记录

                  引用文档

                  术语

设计方法和原则

Check        描述

                  限制和约束

微软参考：

http://msdn.microsoft.com/zh-cn/library/dd393574.aspx

官方网站： http://nant.sourceforge.net

每日构造的流程：

1. 编译Solution

2. 执行所有的单元测试

3. 执行所有的自动化测试

4. 执行BVT测试

从测试人员那里我们时常听到一些意见，如这个bug的归属不明确、解决一个问题引进更多的bug、这个bug根本就没有解决。。。

首先我们要明确Bug的生命周期是什么？项目干系人在整个周期的角色是什么？这个问题在下一个话题中说明。在这里我简单说一下目前的现状。从能提交测试版本开始，开发人员在解决一个

问题一、设计文档太泛泛

问题二、设计文档跟踪和修改断档

问题三：需求理解造成的解决方案的偏差

对于开发人员来讲，全面深刻的理解需求并给出优秀的解决方案，需要具备2个素质，1. 对业务领域的准确理解和定位；2.

DBA是公司的宝贵人力资源，优秀的DBA人员可以为产品提供丰富的数据库优化知识，为大数据量的挖掘、分析和存储提供技术支持。

网优产品是一个专业性很强的应用软件，核心资源是产品积累的一个产物，由核心资源衍生出的数据库ER关系模型是产品的核心业务模型的一部分。是产品真正的宝贵资源。

如果能够把业务模型和

亲和力、协助、有效、鼓励、熟悉、明显、个性化、安全、满意、简单、支持、多样性

简单原则， 保持界面的简单和直接。用户能从直觉的、便于使用的功能受益，确保基本的功能明显的展现在用户面前。为易于访问和使用而组织功能。避免设计一个混杂着功能的界面。一个良好组织的界面只是在背后默默的支持用户更加高效的工作。

个性化原则

移动项目期间设计占整个研发周期不足1/4，采用敏捷的尽可能提交测试demo的方法发现实施起来困难，没有效果，而且出现比较严重的需求不符的问题。此次电信项目，我改变策略，整个项目的1/3还多的时间在需求确认、用例分析、业务建模上，例如充分理解需求、从各个角度设计架构、细化模块职责和模块之间的关系、细化类职责和类之间的关系、细化核心类的各个属性、方法的含义和规则、挖掘隐含的需求并确认等等。

我们肯定不是完全的敏捷，因为很多敏捷的特点并不存在，例如我们结对编程吗？客户和我们在一起吗？我们有单元测试吗？我们持续集成吗？。。。

我们肯定不是完全的迭代，在研发的整个周期里，需求确认后我们何时有做过风险评估？何时做过项目调整？何时标记过里程碑？。。。

我个人认为是不是敏捷、迭代不重要，重要的是我们应该剪裁并形成一套适合网优产品线的软件工程方法，每次产品研发周期的结束阶段，我们应该坐在一起讨论、积累、调整、优化这个方法，形成一个看得见摸得着的制度并共享给研发团队的所有成员，让大家知道这个流程、学习这个流程、最后在下一个研发周期内严格执行这个流程。如此反复。。。

我们迫切需要一份用例规约图集

需求描述的Feature，通过用例规约图逐层分解，便是最初的功能模块，这是一个很好的认识和理解需求的开始点。往往我们没有用例规约图，便不能形成对需求的整体认识和把握、不知道如何站在用户的角度看待系统。而且良好的用例规约图为项目管理和后期的架构设计提供非常关键的基础信息。所以我认为即使没有现成的用例规约图，作为设计者，应该自己绘制，并与涉众人员沟通，确认如下的一些问题：谁在使用该系统、如何使用该系统、有哪些子系统、子系统之间的关系， 系统下有哪些核心模块、模块之间约束、通信关系等

抱怨是自我心态调节的一种手段，是对暴露问题的不满和强烈的抵制情绪，是心理压力的一种释放，没有人不会抱怨，但是抱怨解决不了问题，我们应该仔细分析根源找出解决问题的办法。

领域模型建模

在需求复杂且相对稳定的情况下，我们迫切需要一个领域模型的映射环节，这一环节称为通用语言建模。在需求和代码之间的通用语言建模是对业务领域模型的确认、理解、优化的过程。需求获取知识、建模理解和巩固知识并促进需求的深化演进，我认为建模过程有三个好处：

<cruisecontrol>   

     <project name="ccnetProject" webURL="Http://192.168.1.1/ccnet" publishExceptions="true">

         <!--工作目录，下载的源码将会被保存在这个目录下，如没有设置则会自被保存在安装目录下server子目录以project name为名称的目录下-->

         <workingDirectory>e:\ccnet</workingDirectory>

         <!--对这个项目的监控过程的日志记录目录-->

shutdown.exe -i

控制网络中的计算机的关机方式

shutdown.exe -s -t 2100 -f -c "警告"

35分钟后强制关机

shutdown.exe -a

取消关机操作

制作快捷方式

"%WinDir%\System32\shutdown.exe -s"

最短距离原则：

使错误检查代码距离失败操作的距离最短

最小范围原则：

即让调试人员可以利用调试信息精确定位某个代码位置，或者某个条件，以加快发现问题根源的速度。

立刻终止原则：

当检测到严重的错误时，使程序立刻终止并报告第一现场的信息

可追溯原则：

对于代码，就是可以查找出当前线程是如何运行到这个代码位置的；

对于数据变量，就是要知道它的值是经历了什么样的变化过程而成为当前值；

可控制原则：

如通过配置使用1GB内存来调试系统；

可重复原则：

比较简单的重复；

可观察原则：

静态特征， 各种文件， 如映像文件、源文件、符号文件、配置文件等