实现阶段, 详细设计, 编码过程中的控制与管理
一、 前言
项目进入实现阶段, 主要活动聚焦于：详细设计、编码、自测试、监测。此节为软件项目过程中，历时最长，工作量最大，细节最多的环节，确保此节之可控，可管理，实为至关重要。
然则公司层面的此节过程控制, 不够具体, 也没有与其他维度的管理措施相结合, 市面上之参考实施往往也是论而无策，况每公司有其特殊性, 不能一概而论之。
本细则就实现阶段中的各项活动如何与质量保证, 绩效考核, 管理工具如何进行有机结合, 使其管理活动不流于形式，便于实施，真正起到效用而进行原则性规定和范例规定。
实施过程中，问题多有变化差异，特殊性等，本文也不能做到全面，全面必造成细节繁缛，限定过紧，未必有利于实施，因此必有其缺失，但万变不离其中，只要遵循一定的原则去分析和解决，或可迎刃而解。
二、 原则
1 此过程中的每项活动，规定须由开发人员主动发起，非管理者被动去追；
2 开始实施时, 必严格要求, 细节形式也须锁死, 必待开发人员养成习惯后, 才可形式不拘；
3 措施之细节须与管理活动中的质量保证, 绩效考核, 管理工具相结合, 一举多得, 既利本团队代码质量, 惩奖有据, 又同时兼顾公司过程管理规范所需。
4 措施需利于实施，最大限度力求不额外增加工作量，可灵活规定哪些功能，代码免查或抽查，但必须事先规定。
三、 例则
(一) 任务切分
本公司之开发任务切分（WBS）以Redmine作为管理工具，任务切分须遵循以下原则：
1 切分任务以两个工作日为限，这是公司硬性规定，符合QA要求，须遵循之；
此条规定看似死板，却与以上第二条原则：“细节形式也须定死”异曲同工。
2 切分任务须保证以下两点：
2.1 定义任务之可交付件：可以是代码，文档，二进制文件，包，可运行程序等；
2.2 可交付件要便于验证，且须定义验证之标准，方法，不得模糊；
2.3 是否是关键任务；
2.4 根据IFPUG定义功能点数和任务复杂度，以此作为任务分值；
2.5 任务的关键特性：功能，性能，稳定性，易操作，可移植，可配置等不限；
(二) 详细设计
开发人员根据Redmine排定之任务进行开发，遵循以下准则：
1 编码前，原则上须提交详细设计，项目经理或架构师或项目经理授权的人批准后，方可编码。若遇到不能及时确认，可先行编码，待审批人得空，须第一时间找其确认。
2 开发人员须主动进行详细设计和及时确认，若直至编码完成仍未确认，视为忽略确认， KPI-1，终未见其人，电话沟通。
3 多条Redmine上的开发任务可能属于同一功能，或者代码逻辑中不可分割的项，开发人员自性评估，合并，而后做到一个详细设计图中；
4 详细设计规定：
4.1 以Rose时序图或流程图，说明功能之实现过程，细节程度到函数为准。
4.2 关键函数，且对函数处理流程或逻辑进行流程图示或逐条文字说明；
4.3 代码实现有差异，须更新详细设计，且及时通知审批人；
4.4 详细设计中，须标明：
4.4.1 关键函数；
4.4.2 要单元测试的函数，关键函数必须单元测试；
4.4.3 提供给其他模块的接口，必须标明，必须单元测试；
4.4.4 编码所需时间评估，以小时计;
4.5 详细设计中, 须提供自测试方案作为设计之部分, 自测试方案须明确：
4.5.1 自测试的方法: 单元测试，与其他模块整合测试，编写测试代码测试，手工测试。
4.5.2 测试方案：
4.5.2.1 构造怎样的数据，怎样的操作才能验证编码；
4.5.2.2 预期结果该怎样查看，怎样验证；
4.5.3 测试方案必须能够验证任务的关键特性：
前述之功能，性能，稳定性，易操作，可移植，可配置等；
4.5.4 测试方案若是针对功能的，必须能够验证正常流程和异常流程；
5 例外：
5.1 设计须编写测试代码进行思路验证的，首先提交逐条阐明的思路；
5.2 研究性任务，开始任务前，首先须提交逐条阐明的研究思路；
6 详细设计文件
6.1 详细设计作为项目的一部分, check in到工程中;
6.2 统一命名规则：产品名_版本号_功能名称_设计者姓名.mdl
6.3 详细设计统一放到项目的rootdir/detaildesign目录下；
(三) 编码
1 编码当遵循公司编码规范以及下述之代码走查中规定的代码规范；
2 若详细设计中，确定了要单元测试的，当先编写单元测试代码；
3 编码当按照详细设计编码实现，若有差异，须及时更新并通知审核人；
4 记录编码工时：记录编码开始，截止时间，计算工时，并记录在案；
4.1 编码工时以编码开始，直至调试完成，当需要联合其他模块的，以整合完成为结束；
4.2 当编码过程中，发现需要对以往其他任务关联的代码进行重构的，记录在案；对以提交验证模块代码作更改，并特地标明，没有标明的说明的，KPI-1；
4.3 编写单元测试代码的时间，算到自测试工时中；
5 编码完成时，统计代码行数，完成代码行统计的时间，算到工时当中；
6 编码输出工件中，要求文档的，要按照正式文档编写格式，提供正式文档，而不是以后再补；
6.1 输出文档工件
6.1.1 为项目之一部分, checkin到项目中；
6.1.2 统一命名规则：产品名_版本号_8字以内短作用名.扩展名；
6.1.3 统一放到项目的rootdir/configdoc目录下；
7 编码完成后，创建编码日志，记录：
7.1 编码工时：含预计工时，实际工时；
7.2 更改记录：设计更改，其他已提交代码更改；
7.3 自测试工时，在自测试完成后填写；
7.4 编码日志文件:
7.4.1 编码日志，为文本文件， checkin到项目中；
7.4.2 编码日志统一命名：产品名_版本号_编码者姓名.txt；
7.4.3 编码日志统一放到项目的rootdir/codelog目录下；
(四) 自测试
1 自测试须按照测试方案编写测试案例；
2 自测试案例为：验证所开发之功能的：输入数据，操作步骤，预期结果；
2.1 输入数据可以是：调试输入，构造数据，其他模块来源之数据等不限，但必须要符合实际业务；
2.2 预期结果可以是：界面展现，数据，日志，调试观察等不限，但必须清楚确定；
2.3 操作步骤可以是：人工操作，调试逐步运行，运行单元测试等；
3 特别说明：
3.1 关键特性含功能的：
必须能够验证正常流程；
必须能够验证意外流程；
3.2 关键特性含性能的：
必须包含能够验证的测试环境，数据构造方法，性能计算方法；
3.3 关键特性含稳定性的：
必须包含针对各种异常状况的容错，恢复处理，并模拟异常；
3.4 关键特性含可移植性的：
必须包含在各个平台的功能测试案例；
3.5 关键特性含可配置性的：
必须包含对配置数据正常和异常的处理；
4 自测试报告已自测试案例为基准，填写自测试结果，即为自测试报告；
4.1 整合阶段的自测试报告，交由打包者整合提供；
4.2 打包者负责眼看各人之测试报告, 确保各人自测试通过;
5 自测试完成后，如实填写自测试工时；
6 自测试文件
6.1 自测试报告，为文本文件， checkin到项目中；
6.2 统一命名：产品名_版本号_功能名称_编码者姓名_xxxx_自测试.xlsx；
6.3 编码日志统一放到项目的rootdir/selftest目录下；
6.4 若为整合阶段之整合自测试报告,
命名为:
产品名_版本号_BuildNumber_自测试.xlsx
(五) 代码走查
1 代码走查由编码者主动发起，主动讲解，而不是由其他参与走查的人发问；
2 代码走查一旦发现并认定缺陷，无需解释, 发现缺陷,不一定扣KPI，但若一周内出现2次以上相同的缺陷， KPI-1；
3 走查前准备
必须有准备，准备的文档为：
3.1 更新后的详细设计文档；
3.2 编码日志；
3.3 自测试报告；
3.4 不准备以上3样文档的， KPI-1；
4 走查首要检测
4.1 查3样准备文档是否备齐；
4.2 查交付件是否都有；
5 走查中
5.1 走查业务实现；
5.1.1 按照自测试测试案例运行；
5.1.2 按照详细设计之流程自我讲解；
5.1.2.1 关键函数实现逻辑讲解；
5.1.2.2 关键数据结构，不能有不明确的地方；
5.2 走查代码规范
5.2.1 代码格式
5.2.1.1 缩进: 统一以ＴＡＢ缩进；
5.2.1.2 换行，同一方法类， 功能模块之间以空行分隔；
5.2.2 注释规范
5.2.2.1 源文件注释、类注释、方法注释、实现必要说明注释。
5.2.2.2 采用统一格式，格式老潘定，每个人的ＩＤＥ添加
5.2.2.3 只要出现的注释字段，都必须填，不能空；
5.2.2.4 特别是参数的作用、取值范围及参数间的关系;
5.2.2.5 修改注释：谁, 什么时间, 为什么修改, 对应到代码段
5.2.3 函数规范
5.2.3.1 异常必须说明什么情况下回抛出异常;
5.2.3.2 多线程的设计, 必须做详细的设计说明;
5.2.3.3 有Close方法的类, 要注意调用Close
5.2.4 拷贝重复
5.2.4.1 出现两次以上的相似度强的代码, 封装;
5.2.5 异常规范：
5.2.5.1 异常处理、异常捕获、异常日志、异常提示（准确、有意义）。
5.2.5.2 异常捕获不应该改变异常本身的作用, 除非是特殊需求;
5.2.5.3 代码中不能使用System.out.println()，e.printStackTrace()，必须使用logger打印信息。
5.2.5.4 异常应该用说明文字来描述异常出现的可能原因或者代表的具体业务内容, 不能直接log异常本身完事;
5.2.6 命名规范
5.2.6.1 类、方法、变量、配置文件名称等等命名规范、易懂、有意义。
5.2.6.2 java命名法则
5.2.6.3 方法名, 变量名, 易懂、有意义, 不缩写
5.2.6.4 带特征(该list就list, 该map就map)
5.2.7 单元测试。
5.2.7.1 已经指出要做单元测试的地方, 必须做单元测试;
5.2.8 函数过程
5.2.8.1 函数的规模尽量限制在200行以内, 超过则说明
5.2.8.2 一个函数最好仅完成一件功能, 违反则说明
5.2.8.3 尽量不要编写依赖于其他固定函数或对象内部实现的函数。
5.2.9 日志记录
5.2.9.1 系统中涉及到以下功能的代码块，必须作日志记录
5.2.9.1.1 用户登录
5.2.9.1.2 对数据库进行插入、更新、删除SQL操作的
5.2.9.1.3 会造成系统数据发生变化 (如调用执行数据库的函数、存储过程等)的
5.2.9.1.4 会造成系统配置文件发生变化的
5.2.9.1.5 涉及对服务器上的文件进行操作的(如文件上传、删除等功能)
5.2.9.2 记录内容：用户身份标识、操作时间、操作IP、操作内容(可记录操作SQL语句，也可以做详细文字描述，或两者兼有)
5.2.9.3 业务流程的关键节点, 关键数据必须在日志中有体现, Level为Info级别;
5.2.9.4 日志文件记录到一个文件, 除非运维有特殊要求的情况;
5.2.10 性能
5.2.10.1 SQL要审查
5.2.10.2 内存, 线程, 连接特别频繁使用时, 要用池;
5.2.11 公共代码
5.2.11.1 不要轻易编写公共代码, 二是首先问其他同事有无此类公共代码, 有则尽量用;
5.2.11.2 没有公共代码, 申请编写公共代码;
5.2.11.3 公共代码提交并测试通过, 在产品中验证, 对多个公共代码组织培训推广,推广3个使用者以上者, KPA+1;
5.3 优秀分享
5.3.1 亮点: 算法精炼, 高性能, 规范优美, 快而好;
5.3.2 只要有说服力的亮点都可以;
6 日/周走查
6.1 项目经理或架构师在周会上宣布，某周为xxxx规范周，该周检查代码规范时，以检查代码规范中的xxxx为重点；
6.2 日走查
6.2.1 以走查业务实现为主；
6.2.2 以走查代码规范为辅；
6.2.3 重点看周检查主题；
6.3 周走查
6.3.1 周走查当日的代码走查;
6.3.2 周走查以优秀分享为主;
6.3.3 项目经理或架构师分享当周发现的典型问题及解决方法;
6.3.4 周走查评选优秀代码, 当选第一者, KPA + 1;
6.4 被走查的编码者自己记录走查过程中发现的问题或缺陷；
6.4.1 走查报告
6.4.1.1 日走查以文本文件的方式记录.
6.4.1.2 记录到编码日志中, 填写Redmine时, 作为附件上传;
6.4.2 周走查报告
6.4.2.1 周走查报告为汇总之日走查报告;
6.4.2.2 形成公司要求的正式的走查报告,提交到SVN;