{工程}{杂谈}10GB源代码下的工程问题
Kenny Yuan
这是一个发生在平行宇宙的事情，那个世界同样有太阳系，同样有地球，也同样有中国和美国，最重要的，他们也使用计算机，也用源代码来生成机器码。
在这个平行宇宙的地球上，有一个叫做Miracle的公司，有一个叫Master的产品，这个产品使用UPM公司出品的DirtyUnpack作为管理源代码的工具，这个源代码管理工具支持一种叫做Sight的快照方式，在正确配置了BOV的情况下，Sight的大小为400多GB。这400GB中包括源文件，第三方工具，第三方库，多语言工具，各种脚本，各种语言的资源文件（LMX格式），也就是说，安装了操作系统和基本开发工具之后，有了这个Sight之后就可以完成所有的开发事项了。
在某一个Sight下，源代码大小11,180,425,539 Bytes（在不重要的数据位上加了扰动，导致这个值比真实数据要略小一些），这个数据是在统计.h和.cpp文件后，用bc计算得到的。其中有少量文件是symbol link，懒得做uniq了，因为我也没有统计.c文件，其它的脚本文件等也都没有统计，原因很简单：DirtyUnpack这个源代码管理工具运行得太慢了，仅仅统计这两项就花了1/365光年（注意：这是平行宇宙，光年在他们那里是时间单位，嘻嘻）
现在来考查一下巨大的源码带来的问题
1、IDE问题
和咱们的地球一样，在那个平行宇宙里，程序员中的大多数还是喜欢IDE。这么多的源码文件，没有办法全加到project中。比如HugeHard公司出产的BlindWorkshop开发工具，如果添加这么多文件进入工程文件，会几个小时也无法打开工程——也就是说，当你上班到了公司时，打开这个工程，等到工程打开了，你就可以去吃中午饭了；下班时关闭工程后，你得加班4小时等着它正常关闭。
2、编译问题
10GB的源码，编译起来是个大问题，要非常慎重地在根目录对clean目标进行make。编译的依赖性问题在这种情况下，也成了一个大问题（如：规划哪些源码需要重新编译）。另外，如何加快编译速度，也算是一个不小的挑战。
3、阅读问题
如果你想要修复Flies（平行宇宙里不叫Bug），或者想要添加新功能，肯定都需要先读懂原有的（部分）代码。设想一下：为了完成某一项任务，你需要有一个必须要理解的内容集合，包括：源文件，架构，接口等。如何让这个集合的内容最小化，形式上更合理化，也是一个不小的挑战。设想一下极端的情况，如果想要修改一个小东西，得要先读懂全部这10GB的源码才能动手——这种情况是肯定不能接受的。但有没有可能将这个集合限制在一个相当小的范围内呢？比如：一个文件夹内？甚至一个文件内？
4、查找问题
在那个平行宇宙中，有一个非常强大的CloseBinary的CLI，叫做Linics。许多在这个地球中存在的工具，在这个CLI下面也有。比如find|xargs，再比如cat/cut/grep/sed等。
有时候，可能会需要在源码中遍历查找些东西，比如，当你在修改常量前，往往会想先知道这个常量在哪里正在被使用，而这个常量是在一个非常公共的头文件中定义的。于是你需要查找大量的文件来定位这个符号。但是，这个DirtyUnpack的Sight，是一个从网络访问的动态Sight（snapshot类型的太大了，要400GB，软盘没那么大空间），这种动态的sight速度是不够快的，如果在较高层次的目录上进行查找，往往需要1/356光年的时间才能完成。（前面已经说了，平行宇宙，“光年”是时间单位）
……
嗯，暂时先说这几条。其实这几条已经能够让人感觉到非常不爽了，有时候某些原来很容易做到的事情却变成了“不可能完成的任务”，比如：一条几个小时才能完成的grep命令，在我看来，如非特别必要，一般是不想去跑了。
说这些的东西的目的也很simpe，很naive：对于大型的项目，有些理念是不一样的，在接触了那样的限制条件后，才能体会得到。在这些项目中，从架构设计到编码规范，都和平时接触的小项目有所区别（我原先工作的都是30-60MB源码这样的小项目）。这里的许多东西，不是故意为了特立独行而发明的，实属是被逼无奈才不得已而为之。“历史的包袱”在这种生存期长达10几光年的项目中也很沉重（为什么C++的编译器不能随便抛弃东西？）。
嗯，期待“结论”或者“启示”的TX们可以关窗口了，本文就是讲故事，到此为止了。某些怀疑论者也不要找我求证了，都说了这是平行宇宙发生的事情了……
P.S. 还得多说一句，“大”不代表“好”，只不过有时候，这个“大”是一个既定事实，你不得不去面对。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
Tiny fool
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Phone: 13520711089
Twitter:http://twitter.com/tinyfool
银杏泰克科技有限公司-专业的站内搜索引擎提供商
http://www.ginkgotek.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
qiaojie
Mikster.Z
--
EX - EMBEDDED SYSTEM DEVELOPER
SOFTWARE ENGINEER
Name : Mikster
Lv, Cheng Gong
久远
或者使用Unix的风格，编译为一个个的程序，利用进程间的合作来完成任务。
总之就是分治。
如果一个超级大的项目不能通过这样的方法降低复杂度的话，那个项目一定走错方向了我觉得。
On 7月27日, 下午1时20分, Kenny Yuan <yuankain...@gmail.com> wrote:
> {工程}{杂谈}10GB源代码下的工程问题
>
> 这是一个发生在平行宇宙的事情，那个世界同样有太阳系，同样有地球，也同样有中国和美国，最重要的，他们也使用计算机，也用源代码来生成机器码。
>
> 在这个平行宇宙的地球上，有一个叫做Miracle的公司，有一个叫Master的产品，这个产品使用UPM公司出品的DirtyUnpack作为管理源代码的-工具，这个源代码管理工具支持一种叫做Sight的快照方式，在正确配置了BOV的情况下，Sight的大小为400多GB。这400GB中包括源文件，第三方-工具，第三方库，多语言工具，各种脚本，各种语言的资源文件（LMX格式），也就是说，安装了操作系统和基本开发工具之后，有了这个Sight之后就可以完成所-有的开发事项了。
>
> 在某一个Sight下，源代码大小11,180,425,539
> Bytes（在不重要的数据位上加了扰动，导致这个值比真实数据要略小一些），这个数据是在统计.h和.cpp文件后，用bc计算得到的。其中有少量文件是sy-mbol
> link，懒得做uniq了，因为我也没有统计.c文件，其它的脚本文件等也都没有统计，原因很简单：DirtyUnpack这个源代码管理工具运行得太慢了，-仅仅统计这两项就花了1/365光年（注意：这是平行宇宙，光年在他们那里是时间单位，嘻嘻）
>
> 现在来考查一下巨大的源码带来的问题
>
> 1、IDE问题
> 和咱们的地球一样，在那个平行宇宙里，程序员中的大多数还是喜欢IDE。这么多的源码文件，没有办法全加到project中。比如HugeHard公司出产的B-lindWorkshop开发工具，如果添加这么多文件进入工程文件，会几个小时也无法打开工程----也就是说，当你上班到了公司时，打开这个工程，等到工程打开-了，你就可以去吃中午饭了；下班时关闭工程后，你得加班4小时等着它正常关闭。
>
> 2、编译问题
> 10GB的源码，编译起来是个大问题，要非常慎重地在根目录对clean目标进行make。编译的依赖性问题在这种情况下，也成了一个大问题（如：规划哪些源码-需要重新编译）。另外，如何加快编译速度，也算是一个不小的挑战。
>
> 3、阅读问题
> 如果你想要修复Flies（平行宇宙里不叫Bug），或者想要添加新功能，肯定都需要先读懂原有的（部分）代码。设想一下：为了完成某一项任务，你需要有一个必-须要理解的内容集合，包括：源文件，架构，接口等。如何让这个集合的内容最小化，形式上更合理化，也是一个不小的挑战。设想一下极端的情况，如果想要修改一个小-东西，得要先读懂全部这10GB的源码才能动手----这种情况是肯定不能接受的。但有没有可能将这个集合限制在一个相当小的范围内呢？比如：一个文件夹内？甚至一-个文件内？
>
> 4、查找问题
> 在那个平行宇宙中，有一个非常强大的CloseBinary的CLI，叫做Linics。许多在这个地球中存在的工具，在这个CLI下面也有。比如find|x-args，再比如cat/cut/grep/sed等。
> 有时候，可能会需要在源码中遍历查找些东西，比如，当你在修改常量前，往往会想先知道这个常量在哪里正在被使用，而这个常量是在一个非常公共的头文件中定义的。-于是你需要查找大量的文件来定位这个符号。但是，这个DirtyUnpack的Sight，是一个从网络访问的动态Sight（snapshot类型的太大了，-要400GB，软盘没那么大空间），这种动态的sight速度是不够快的，如果在较高层次的目录上进行查找，往往需要1/356光年的时间才能完成。（前面已经-说了，平行宇宙，"光年"是时间单位）
>
> ......
>
> 嗯，暂时先说这几条。其实这几条已经能够让人感觉到非常不爽了，有时候某些原来很容易做到的事情却变成了"不可能完成的任务"，比如：一条几个小时才能完成的g-rep命令，在我看来，如非特别必要，一般是不想去跑了。
>
> 说这些的东西的目的也很simpe，很naive：对于大型的项目，有些理念是不一样的，在接触了那样的限制条件后，才能体会得到。在这些项目中，从架构设计到-编码规范，都和平时接触的小项目有所区别（我原先工作的都是30-60MB源码这样的小项目）。这里的许多东西，不是故意为了特立独行而发明的，实属是被逼无奈-才不得已而为之。"历史的包袱"在这种生存期长达10几光年的项目中也很沉重（为什么C++的编译器不能随便抛弃东西？）。
>
> 嗯，期待"结论"或者"启示"的TX们可以关窗口了，本文就是讲故事，到此为止了。某些怀疑论者也不要找我求证了，都说了这是平行宇宙发生的事情了......
Hongzhang Liu
2009/7/27 Mikster.Z <china...@gmail.com>:
机械唯物主义
如果复杂度没有这么高，那么应该把代码里面的数据分离出来（比如把业务逻辑当成是数据），
抽象成单独的几个核心模块编译。
然后用动态加载的方法，提高编译效率。
如果真的没有办法提高编译速度的话，那么应该把coding和编译分离，
程序员coding完毕后，检查代码提交到代码仓库，然后到一个编译服务器上编译，
测试人员在编译完成后进行测试工作。
关于代码查找，可以用索引的方式来优化速度，比如etag,ctag之类。
On Jul 27, 1:20 pm, Kenny Yuan <yuankain...@gmail.com> wrote:
> {工程}{杂谈}10GB源代码下的工程问题
>
> 这是一个发生在平行宇宙的事情，那个世界同样有太阳系，同样有地球，也同样有中国和美国，最重要的，他们也使用计算机，也用源代码来生成机器码。
>
> 在这个平行宇宙的地球上，有一个叫做Miracle的公司，有一个叫Master的产品，这个产品使用UPM公司出品的DirtyUnpack作为管理源代码的工具，这个源代码管理工具支持一种叫做Sight的快照方式，在正确配置了BOV的情况下，Sight的大小为400多GB。这400GB中包括源文件，第三方工具，第三方库，多语言工具，各种脚本，各种语言的资源文件（LMX格式），也就是说，安装了操作系统和基本开发工具之后，有了这个Sight之后就可以完成所有的开发事项了。
>
> 在某一个Sight下，源代码大小11,180,425,539
> Bytes（在不重要的数据位上加了扰动，导致这个值比真实数据要略小一些），这个数据是在统计.h和.cpp文件后，用bc计算得到的。其中有少量文件是symbol
> link，懒得做uniq了，因为我也没有统计.c文件，其它的脚本文件等也都没有统计，原因很简单：DirtyUnpack这个源代码管理工具运行得太慢了，仅仅统计这两项就花了1/365光年（注意：这是平行宇宙，光年在他们那里是时间单位，嘻嘻）
>
> 现在来考查一下巨大的源码带来的问题
>
> 1、IDE问题
> 和咱们的地球一样，在那个平行宇宙里，程序员中的大多数还是喜欢IDE。这么多的源码文件，没有办法全加到project中。比如HugeHard公司出产的BlindWorkshop开发工具，如果添加这么多文件进入工程文件，会几个小时也无法打开工程----也就是说，当你上班到了公司时，打开这个工程，等到工程打开了，你就可以去吃中午饭了；下班时关闭工程后，你得加班4小时等着它正常关闭。
>
> 2、编译问题
> 10GB的源码，编译起来是个大问题，要非常慎重地在根目录对clean目标进行make。编译的依赖性问题在这种情况下，也成了一个大问题（如：规划哪些源码需要重新编译）。另外，如何加快编译速度，也算是一个不小的挑战。
>
> 3、阅读问题
> 如果你想要修复Flies（平行宇宙里不叫Bug），或者想要添加新功能，肯定都需要先读懂原有的（部分）代码。设想一下：为了完成某一项任务，你需要有一个必须要理解的内容集合，包括：源文件，架构，接口等。如何让这个集合的内容最小化，形式上更合理化，也是一个不小的挑战。设想一下极端的情况，如果想要修改一个小东西，得要先读懂全部这10GB的源码才能动手----这种情况是肯定不能接受的。但有没有可能将这个集合限制在一个相当小的范围内呢？比如：一个文件夹内？甚至一个文件内？
>
> 4、查找问题
> 在那个平行宇宙中，有一个非常强大的CloseBinary的CLI，叫做Linics。许多在这个地球中存在的工具，在这个CLI下面也有。比如find|xargs，再比如cat/cut/grep/sed等。
> 有时候，可能会需要在源码中遍历查找些东西，比如，当你在修改常量前，往往会想先知道这个常量在哪里正在被使用，而这个常量是在一个非常公共的头文件中定义的。于是你需要查找大量的文件来定位这个符号。但是，这个DirtyUnpack的Sight，是一个从网络访问的动态Sight（snapshot类型的太大了，要400GB，软盘没那么大空间），这种动态的sight速度是不够快的，如果在较高层次的目录上进行查找，往往需要1/356光年的时间才能完成。（前面已经说了，平行宇宙，"光年"是时间单位）
>
> ......
>
> 嗯，暂时先说这几条。其实这几条已经能够让人感觉到非常不爽了，有时候某些原来很容易做到的事情却变成了"不可能完成的任务"，比如：一条几个小时才能完成的grep命令，在我看来，如非特别必要，一般是不想去跑了。
>
> 说这些的东西的目的也很simpe，很naive：对于大型的项目，有些理念是不一样的，在接触了那样的限制条件后，才能体会得到。在这些项目中，从架构设计到编码规范，都和平时接触的小项目有所区别（我原先工作的都是30-60MB源码这样的小项目）。这里的许多东西，不是故意为了特立独行而发明的，实属是被逼无奈才不得已而为之。"历史的包袱"在这种生存期长达10几光年的项目中也很沉重（为什么C++的编译器不能随便抛弃东西？）。
>
> 嗯，期待"结论"或者"启示"的TX们可以关窗口了，本文就是讲故事，到此为止了。某些怀疑论者也不要找我求证了，都说了这是平行宇宙发生的事情了......
Kenny Yuan
1、这些源码不是平坦组织的，有很深的层次，比如第一级就分成了两部分：“业务相关”和“核心组件”。这样子一上来就能进行“二分”（实际上，还有资源等一些文件夹，暂且不提）。
在这里多说一句：好的文件夹命名可以让人一路毫不犹豫地点击下去，最终找到想要找的源码（最好的情况，是让那些对系统只有一知半解的人凭直觉也能猜中），这就要求文件夹的名字、数量和层次比较讲究、符合习惯和约定。
2、在二进制程序的组织上，也是跨机器的多进程按协议通讯的，模块多数也是动态加载的（SO和DLL），但是不能运行时替换
3、有些轮子的确是重复发明的，但是不太多，也不是重要的东西。最重要的那几个轮子是统一的，比如隔离运行平台的公共代码
4、一般情况下是不会去搜索全部源文件的，之所以要搜索，是偶尔会碰上组件间的隔离得不够好，或者层次的抽象被打破的时候（一般也不是在最顶层搜，呵呵） 当然，搜索文字的困难也是一个并不那么重要的例子而已。
在我看来，这个产品并不是特别优秀（只从源码角度考察），但在我看来它是一个不错的例子，可以用来体会某些东西吧。我拿出来这个例子，也是为了说明阅读代码的问题——在代码量巨大到不可能让一个人都读懂的情况下（甚至通读一遍都不可能），以下这些对理解代码就显得格外重要：1、系统的结构设计；2、内部规范的实施。
在规范的制定和结构的设计中，“简单、符合直觉”这两条很重要。如果想让别人能够理解这个系统，这两条是代价最小的途径。
Kenny Yuan
qiaojie
pongba
组里还有维护过大型代码基的朋友都参与讨论一下吧，毕竟拥有这类经验的人似乎不多，网上的详细和深入分析也相对较少..
{工程}{杂谈}10GB源代码下的工程问题
这是一个发生在平行宇宙的事情，那个世界同样有太阳系，同样有地球，也同样有中国和美国，最重要的，他们也使用计算机，也用源代码来生成机器码。
在这个平行宇宙的地球上，有一个叫做Miracle的公司，有一个叫Master的产品，这个产品使用UPM公司出品的DirtyUnpack作为管理源代码的工具，这个源代码管理工具支持一种叫做Sight的快照方式，在正确配置了BOV的情况下，Sight的大小为400多GB。这400GB中包括源文件，第三方工具，第三方库，多语言工具，各种脚本，各种语言的资源文件（LMX格式），也就是说，安装了操作系统和基本开发工具之后，有了这个Sight之后就可以完成所有的开发事项了。
--
刘未鹏(pongba)
Blog | Mind Hacks
http://mindhacks.cn
TopLanguage
http://groups.google.com/group/pongba
Zhiming G
amuseme
qiaojie
刘杨
perform without thinking about them.
—ALFREDNORTH WHITEHEAD , 1911
所以我很同意久远兄（很多朋友也表达了类似的看法）的意见，平台是水，应用是船，水涨船高嘛。
Shuo Chen
qiaojie wrote:
> 分布式编译可以缓解一下编译的速度问题，但是最后一步链接还是没法实现并行，工程大了以后链接也会非常慢。
>
>
>
Jun Yang
另外有些好奇，这么庞大的项目是经历了多长时间的发展才达到眼下的规模的呢？
在整个项目的发展过程中，是不是也经历过若干次大型的重构，结果还是发现无法避免眼前的规模问题？
或者说，出于商业角度的考虑，并没有作过大的重构？
另外，这样的项目，你们是怎样进行相应的文档管理的？
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
doitian
On Jul 28, 10:59 am, 刘杨 <liuyuyangf...@gmail.com> wrote:
> 兄弟你说的太好了，关于这个问题我引用一句名人名言大家看有没有道理啊：
> Civilization advances by extending the number of important operations which
> we can
> perform without thinking about them.
> --ALFREDNORTH WHITEHEAD , 1911
>
> 所以我很同意久远兄（很多朋友也表达了类似的看法）的意见，平台是水，应用是船，水涨船高嘛。
> 2009/7/28 Zhiming G <gaoz...@gmail.com>
realfun
--
代码发芽网： http://fayaa.com/code/ （无需插件支持blog代码高亮，100+种语言，30+种高亮主题）
游戏发芽网： http://fayaa.com/youxi/ （华容道、数独等在线游戏及求解、图解）
我的Blog: 半瓶墨水(http://www.2maomao.com/blog)
Follow me @ http://twitter.com/realfun
