对日构建的新理解

以下为与cloundward 以及leon的msn群谈话实录：

cloudward@gmail.com (285273 ,22:24) 说:
一方面需要领导重视这个问题，关系到团队的工作效率；另外，需要很好的软件工程实践基础，以及对配置管理的精通。
cloudward@gmail.com (285273 ,22:25) 说:
csdn把文章丢了，所以才搬到 donews 上来
ginger547 说:
不是简单的把代码管理起来 找一个软件在固定的时间运行编译打包吗？我想的是不是太简单了
cloudward@gmail.com (285273 ,22:27) 说:
恩，远非这样。如何分包？如何自动同步更新构建产品？如何在构建的同时实现单元测试，代码覆盖测试？如何实现统一的配置部署环境？
cloudward@gmail.com (285273 ,22:28) 说:
这些问题对于小产品是看不到的，但是对于一个数十人、百人的团队，就是非常重要的问题。否则 小小一个核心组件版本的变化，即可影响大量上层模块的运行、调试。
cloudward@gmail.com (285273 ,22:29) 说:
另外，大型软件的测试是不能完全依赖 “测试部门的“，最好的代码质量控制是放在 开发上，从源头尽量保证代码的 质量。
ginger547 说:
你这样说我好象理解的更深刻了 你说的这个过程也很需要单元测试   你是指在构建的过程中 测试先行 只有测试通过的 才能构建 是不是
cloudward@gmail.com (285273 ,22:29) 说:
这样，就会引入“所谓代码审计“
cloudward@gmail.com (285273 ,22:30) 说:
另外，如果还要考虑对团队的开发效率进行测量，那么还会涉及“代码统计和分析“
ginger547 说:
你说的后一个问题不太好确定吧  比喻说有很差的程序员 可能需要100行完成的代码 高级程序员只需要10行 这个工作量 怎么确定
cloudward@gmail.com (285273 ,22:32) 说:
现在单元测试架构已经非常成熟了，难的是如何保证大家都去写单元测试，如何统一执行测试并得到可观的，对软件质量的评测标准。
ginger547 说:
你所谓的单元测试架构是指的 junit或者敏捷中的测试驱动吗？
cloudward@gmail.com (285273 ,22:33) 说:
个别差异没有意义，但是，你可以看到 类似模块的a组代码比b组明显高，而单眼测试通过率也高，那就是b有问题了。
cloudward@gmail.com (285273 ,22:33) 说:
对，测试驱动对于 真正的产品级研发 非常有价值
Leon (李梁) (288238,22:33) 说:
项目管理中强调的是“过程管理”，很多"质量"无法保证，所以只能从“过程”来保证。
ginger547 说:
leon好象说的不敏捷吧  敏捷不是重人轻过程的吗？
cloudward@gmail.com (285273 ,22:35) 说:
敏捷是“灵活的”但是，灵活的东西需要对 过程更精细的理解
cloudward@gmail.com (285273 ,22:35) 说:
本质上，两者没有矛盾，只是针对不同的项目，可能需要区别对待。
Leon (李梁) (288238,22:36) 说:
敏捷中，更加强调过程
ginger547 说:
有了单元测试用例 日构建也将更加准确可用 这是肯定的 可是想明白一个最简单的问题 那cloud你 到底在你的项目中 用了一些什么来保证 日构建的完成呢  你总结过吗
ginger547 说:
这个我就不太明白了 我看的所有的资料 都没有说到 这个观点 敏捷更重视过程！
cloudward@gmail.com (285273 ,22:37) 说:
做了就知道了！
ginger547 说:
？。。。 保密？
 
Leon (李梁) (288238,22:38) 说:
有些东西不太好解释
cloudward@gmail.com (285273 ,22:38) 说:
有些内容是需要体验的
Leon (李梁) (288238,22:38) 说:
软件开发是一个不透明的过程，每块就像一个一个的黑盒子
Leon (李梁) (288238,22:38) 说:
强调过程，就是尽量使这黑盒子变小
ginger547 说:
你们说的是敏捷吧 我现在最想知道是 你在 日构建过程中的实现办法 呵呵
Leon (李梁) (288238,22:38) 说:
变得可控
Leon (李梁) (288238,22:40) 说:
项目的管理和程序员的能力不一样，管理的方式也不一样。日构建不是适合所有的项目。
Leon (李梁) (288238,22:41) 说:
对整个开发管理的要求很高。如果强行执行“日构建”，很有可能搞个”肌肉拉伤“之类的 

ginger547 说:
那有什么必须要的知识吗？ 比喻说 cloud刚才说的 单元测试用例是必须要用的了 还有什么 一个很大的ant build吗
cloudward@gmail.com (285273 ,22:43) 说:
好的日构建，都是自己根据需要研发的。虽然业界有些产品，比如Finalbuilder,ant等，但是，这些本质上是提供一种工具，而工具如何灵活运用到研发上，需要精心设计。
cloudward@gmail.com (285273 ,22:44) 说:
你需要熟悉各种工具，ant, perl,php , javac, cmd script等。
cloudward@gmail.com (285273 ,22:44) 说:
另外，设计者本身需要对 大团队中的 协同问题有非常深刻的理解
cloudward@gmail.com (285273 ,22:45) 说:
比如，分包，如何划分更合理
Leon (李梁) (288238,22:45) 说:
工具很重要，但是不是最重要的。
ginger547 说:
看来这个日构建对项目的贡献很大 可是要求也是颇高啊 怪不得cloud要说 必须大项目才有意义呢
cloudward@gmail.com (285273 ,22:47) 说:
大-->分包-->分别构建-->解决依赖关系-->解决构建时间关系-->解决代码质量-->解决项目协同-->解决项目管理
cloudward@gmail.com (285273 ,22:48) 说:
这是一个不断可以提升的过程
ginger547 说:
在代码日构建的过程中 也需要解决代码质量的问题吗？ 我感觉这点有点牵强
cloudward@gmail.com (285273 ,22:49) 说:
非常重要
ginger547 说:
洗耳恭听
cloudward@gmail.com (285273 ,22:50) 说:
代码的质量包罗哪些呢：1,风格/命名 2. 注释 3.逻辑严密 4.错误引用 5.接口依赖/耦合过重 6. metric 等。
cloudward@gmail.com (285273 ,22:51) 说:
这些问题 多数只能在源头控制，功能测试是无效的
cloudward@gmail.com (285273 ,22:51) 说:
团队的技术力量/经验参差不齐，如何控制？
cloudward@gmail.com (285273 ,22:52) 说:
这是现实的问题
ginger547 说:
你的意思 还是集中在 在构建的测试过程中 可以发现一些源头问题 我这点明白了
cloudward@gmail.com (285273 ,22:52) 说:
可以发现大量的源头问题
ginger547 说:
其实我感觉这个日构建的过程中 是对开发人员的一种不信任 是象老师似的 每天检查你的作业  日构建过了一个合格的老师 保证每一个学生每天提供的代码都是正确的可运行的单元测试通过的

cloudward@gmail.com (285273 ,22:54) 说:
对，你理解很正确，摆脱人为因素，给出一个公平和科学的监测手段。
Leon (李梁) (288238,22:55) 说:
"日构建"就是"过程".
ginger547 说:
我感觉软件开发的整个过程中的管理完全采取的是西方的思想，采用的是：假设你不对，你做的不好，我采用一种措施来证明你做的对，你做的好的过程。
cloudward@gmail.com (285273 ,22:57) 说:
难道你有更好的“东方式”解决方案？
Leon (李梁) (288238,22:58) 说:
尽量减少黑盒子在过程中的长度，强调“过程”不是能改进质量，而是尽量提前发现问题。
Leon (李梁) (288238,22:58) 说:
所以在强调“过程”的同时，也要强调优秀的人才
Leon (李梁) (288238,22:58) 说:
这也很重要
cloudward@gmail.com (285273 ,22:59) 说:
敏捷的含义，所以在于对过程的精确理解，从而未雨绸缪。我的同事有个很好地比喻，叫“小步快跑”
ginger547 说:
呵呵 现在还不敢说 其实我也很同意这种办法 中国式的老好人的方式不适合在高智商的开发人员之间使用  就应该假设你是敌人 我来证明你确实是朋友的态度  而且使用的检测手段越是毒辣 得到的结果越是正确
Leon (李梁) (288238,23:01) 说:
这个好比在汽车组装厂，螺丝拧紧，这个过程就是扳手扳360度，你的过程做到了，就假设你的质量达到了。
ginger547 说:
发现并修改问题不就是从另一个侧面改进了软件质量吗
ginger547 说:
那我问一个更模糊的问题 用什么来证明过程的正确性呢？ 难道是让假设好用的车跑两圈 没问题就是好用的过程？ 这也就是为什么有试车环节的原因吗？
Leon (李梁) (288238,23:02) 说:
你说的是最后一个过程了。
Leon (李梁) (288238,23:03) 说:
我们假设， 汽车流水线假设500个过程，每个都走一遍，每个过程的输入输出结果按照文档要求了，汽车最后下先一定能开出厂。
Leon (李梁) (288238,23:04) 说:
过程也是在不断的优化和调整的。
ginger547 说:
这我就清楚了  其实过程也是允许出错的 第一辆车 也肯定不是生产出来就能跑的 呵呵
Leon (李梁) (288238,23:05) 说:
对
Leon (李梁) (288238,23:05) 说:
这就是所谓的“过程改进"