10GB源代码下的工程问题

【文件属性】：
文件名称：10GB源代码下的工程问题
文件大小：20KB
文件格式：DOC
更新时间：2012-12-02 06:01:27
C++, UI, LISP, MMA, Psychology 这是一个发生在平行宇宙的事情，那个世界同样有太阳系，同样有地球，也同样有中国和美国，最重要的，他们也使用计算机，也用源代码来生成机器码。 在这个平行宇宙的地球上，有一个叫做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们可以关窗口了，本文就是讲故事，到此为止了。某些怀疑论者也不要找我求证了，都说了这是平行宇宙发生的事情了…… P.S. 还得多说一句，“大”不代表“好”，只不过有时候，这个“大”是一个既定事实，你不得不去面对。