圣诞节公司大厅布置方案

圣诞节公司大厅布置方案内容摘要：

要改变的是缩进是 4 个字符，类与类之间间隔 2 行，方法与方法之间间隔 2 行， import 类时用完整的类名。 写代码时要对类及函数提供详细的注释及说明，基本做到看它们的说明就能知道这个类或函数的功能以及主要算 法的实现原理。 在开发过程中对主要的模块要编写 UnitTest，同时要 UnitTest 先行，也就是遵循 XP 规则中的测试驱动原则，当所有的单元测试代码通过时，此功能也就基本上完成了。 5. 代码管理 我们采用 VSS+SourceOffsite 进行版本控制，其中存放了此产品的所有源代码、库文件、文档及 release 时的安装程序，各个部分存放在不同的目录中。 每天早上要求开发人员从 VSS 中 get latest version 的源代码，然后进行编译并开始一天的工作。 在下班之前理论上要求员工 check in 所有当天修改 的代码，在check in 之前要保证编译是能通过的。 若有谁 check in 的代码导致 daily build失败则会被要求某些惩罚措施或警告，象微软公司要负责照看当日的每日构建。 有时我们编写的代码涉及到多个文件，而且此改动是比较复杂需要花费多天的工作量，如果现在 check in 进去可能会导致 BVT（ Build Verify Test）测试通不过，因为有些代码没有完全完成，而之前的代码能使 BVT 测试通过，而且这些代码基本上不会涉及到他人，在这种情况下可以不 check in 进去，直到全部代码完成能提交 BVT 测试时 再一起 check in 进去。 每天我们都会做 daily build，一般是在凌晨 4 点进行，那时有个程序会自动从VSS 中拉下最新的代码并进行编译。 因为我们同美国进行同步开发，因此如果想要把修改的代码进入到这个 build 中去那就需要在凌晨 4 点之前把相应的代码check in 进去。 若有人 check in 进去的代码导致编译通不过则会在本步骤中被发现。 当编译完成之后自动产生安装包，测试部门将会对这些代码进行 BVT 测试，同时对 VSS 中开发库打上 label，如果发现了什么 BUG 就能根据这个 label 知道是哪个时候开始出 现这个 BUG 的。 BVT 是指 Build Verify Test，是对组件中基本功能的测试。 这个测试每天都会进行，看新加入的代码或修改是否会影响系统的基本功能，便于及早发现错误。 6. 测试 在开发人员完成了 function Spec 后，测试部门开始了测试规划，确定需要测试哪些方面，如何测试及进度安排。 测试人员需要写许多测试代码，有些测试代码需要集成进 BVT 测试，有些可能需要进行单独的测试，目的都是为了使产品符合要求，使开发人员容易找出问题所在并改正。 产品功能是否符合了要求，是否能被发布是由测试人员决定的，因 此测试人员也比较辛苦，责任重大。 通过了每天的 BVT 测试，还有一些性能测试、兼容性测试、灾难测试等需要在产品发布前进行。 在完成这些测试之后由测试人员决定本产品是否能 release 出去了，如果没有什么问题则会给某些关系较好的用户进行β测试，之后再最终 release 出去。 7. BUG 管理 由于我们每天进行着测试，因此经常有 BUG 被测试部门发现，一旦发现了新的BUG，就会被添加进 BUG Tracking System 中。 目前较流行的 BUG Tracking System有 TestTrack、 ClearQuest、 Bugzilla 等。 BUG tracking system 是开发人员和QA 之间的纽带，开发人员和 QA 通过 BUG tracking system 联系着。 每个 BUG 有其类型和级别，预定的类型有 CrashData Loss, CrashNo Data Loss, Incorrect functionality, Cosmetic, Feature request 等 , 级别有 P P2 一直到 P6，它们分别代表。