Behind the Code

作者：yinwm
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明。

2010-03-14 大雪

难道真的2012？现在还下雪，还是鹅毛大雪。娘列~~

今天重温了一下进度，感觉还是有点紧张的，实在不行就只能砍掉一些需求了。现在给兄弟们的压力太大了，工作很辛苦。不过按照我的说法第三周效率会有一定的提高，因为测试用例大家已经熟悉一些了。不过这个还有观后效。

中午围观了一下上线流程，真是帅呆，累呆。

上线应该是包含哪些呢？

1. 各小组把代码提交到自己的分支
2. 把不同分支的代码（不同小组的代码）合并到上线分支（有些是从分支上线，在此并不讨论，这两种方式没有好坏之分）
3. 把上线分支的代码同步到线上环境
4. 把上线分支的代码合并到其他的分支

这里面说起来挺简单的，而且第三步我们已经有了上线工具可以做到，按道理应该是不难的。但是我们却花了至少一个小时才完成。真是杯具啊。

说起来我们在哪里费时间了呢？

1. 各小组代码提交到自己分支，很快。
2. 把不同分支的代码合并到上线分支，这个费时间很长。
   原因是上次的第四步没做好。而且我们每次都做这两步都是基于文件的（而不是基于提交或者 ChangeSet），每次挑选到底哪个文件（甚至哪个部分）要上到上线代码是一项人类体力与智力的考验。如果没有拜过春哥或者你不是从娜美克星来的你可得小心。
3. 使用上线工具，很快。问题也是基于文件的，但是现在还没有遇到问题。
4. 貌似这次又忘了？

这里面最耽误时间的是第二步。今天的花销其中95%以上都是消耗在这里。
个人觉得这里面的问题并不容易解决。比如我们总有一些文件不得不提交，但是这些文件却不需要上线。 这里如何解决呢？
最简单的办法当然是一次性用新的代码合并上去最好，但是如何保证合并后的代码没有问题呢？尤其是一些比如负责分发判断等代码，贸然的合并一定出现问题。而其一些常量定义的文件在多团队开发下，也一定会出现冲突的情况。

根本上我觉得现在上线和多团队开发还不是那么的爽，还需要大量的人力参与，可能还是开发模式的一些有待提高的地方。试想，如果linux也有我们这样的问题，那就真的没法混了。
这个我会好好的考虑一下如何推进。既要让效率提升，又要每次改动都让现行的开发人员平滑的升级，这并不简单。

程序开发是一个团队作战，我们需要明星战士，但是我们更需要一个能捏合整体的有效的方法。而且还要考虑到产品和运营的需求，在市场、产品、研发、积累等等方面做到平衡。管理，则应该是这个粘合剂，我也应该是这个粘合剂。