回到自己的问题

虽然程序不是那么多,但是分了很多单独的模块。每个模块有单独的solution,包含对应的src, test之类。每个模块有单独的目录。在chromium里面,非常普遍的做法是一个目录下包含上百个文件。感觉这样的话,改变程序的时候查找起来会不是很方便。也许是因为每个人只负责几个或者几十个文件。这样,负责的人也就很清楚。现在自己的麻烦是

1。每新建一个项目,就得设置很多path。如果是library,要设置include path。如果是test,还要设置library path和libs。

2。对library的头文件引用比较多。这样,如果library里做了一些文件的改动,其他项目的文件也会受到影响。

3。不知道怎么自动的集成各个模块生成一个统一的lib。 

好像主要也就是这两个问题。

对于第一个问题:核心类库模块的开发,使用project dependencies来解决引用。构建一个统一的solution。里面包含各个模块的projects。

对于第二个问题:每个模块单独构建一个头文件,包含所有必须引用的头文件。所有模块都使用整个类库的namespace,不用自己的namespace。

对于第三个问题:一个简单的方法是新建一个项目,包含所有必须的源文件。另外一个办法是使用scons脚本来构建。

对于应用,构建一些vsprops,包含通用的libs路径之类。 

vsprops

http://stackoverflow.com/questions/111631/visual-studio-solutions-multiple-project-how-to-effectively-propagate-project-p

//继续研究chromium

chromium里的任何项目都没有设置include path,而头文件的引用都是以src为根目录。那么include path到底是在哪儿设置的呢? vs环境也不可能设置这个。调查了一下,发现这个:Inherited Project Property Sheets。所有项目都设置了这个属性。这个属性对应有很多的.vsprops文件。而vsprops又是什么?网上的信息并不多。msdn讲的也很少。

http://msdn.microsoft.com/en-us/library/a4xbdz1e(VS.80).aspx 

开始那个问题,也就是include path在哪里设置的?就是在这些. vsprops里面设置的。任何的project文件可以引用多个.vsprops。vsprops其实也就是项目设置。可以设置include path之类。至于library path和libraries,chromium的做法是全部用project dependencies。每个solutions里面都单独设置denpendent projects的目录,并包含哪些projects。dependent project全部设为static library。

再回到.vsprops。一般来说对于本身项目,建立一个common.vsprops,里面设定本身项目的include path。而这个path一般回到chromium的src目录。对于libs的话,如果在solution里面包含对应的项目文件的话,就不用单独设置path。如果没有包含,比如googleurl使用libxml,那么,就引用libxml里面的一个using_libxml.vsprops,这个vsprops同时也可能会被其他项目引用到。那么使用libxml的include path在哪儿呢?就在using_libxml.vsprops里面。是这样的:$(SolutionDir)..\third_party\libxml\include。这么做有一个危险,那就是其他也使用libxml的项目的solution file的目录必须是对的,也就是,保证$(SolutionDir)..\third_party\libxml\include能正确找到libxml的include文件夹。由于大部分项目又都是static library,所以libs也就不用设置,只要include path设置就行了。 

chormium

很早就想下载下来看一看

今天终于抽空

也是因为新换的电脑,空间比较大

这个东西原始文件就有一个多G

感觉学到很多东西

最感兴趣的是项目是怎么组织,编译,测试的

最近这些问题搞的比较头疼

现在的做法是分成很多小的modules,每个module都有单独的solution,单独的src, test目录。这样做起来感觉写程序任务清晰了很多。不过问题是modules间的包含引用比较麻烦,总得设置一堆的includes,lib之类。另外,这样的划分对部属不是很好。觉得部署的话应该单独生成一个大的lib或者几个,而不是一堆小的lib。本来想找一个类似ant的工具,写配置copy, build之类。但是c++里面没有好的对应的工具。cmake好像只负责生成编译环境的项目文件。这两天看到scons,感觉很有前途,用python写脚本。然后发现chrome也用scons,id公司也用。scons的tutorial里的samples都很简单,没有介绍一个大项目里面怎么应用。于是索性把chrome的源代码下载下来了。简单的研究了一下:

1。用visual studio开发。项目文件里面没有任何的include或者lib设置,完全基于dependencies。//没想到可以这么做。真是弱啊。

2。单元测试文件都和源代码放到一起。基本上每个源代码文件都有一个对应的unittest文件。单元测试都只有源文件,没有头文件。不同的项目用了不同的测试框架。大部分是gtest,但也有其他的。

3。很多文件都有前缀名,比如render_view_host,render_widget_host,render_widget_host_view之类。也许这是在项目开始的时候没有设定render的目录,后来也就通过加前缀名来组织了。

4。browser项目没有namespace。v8源代码主要是v8::internal。googleurl的namespace比较多,但都是独立的。 感觉namespace比较乱。

5。没有用boost库

6。文件名全部是小写加下划线。大部分项目文件的都放到同一个文件夹里。以前缀来分组。比如base里面。

7。v8提供一个单独的头文件。include/v8.h。有两千多行。用户使用v8只需要调用这一个头文件。实现则完全是另外一套。

8。用scons来构建编译。每个项目都有单独的scons脚本。也都不复杂。

还有很多东西。慢慢看吧。 

trade off

其实是一个非常头疼的东西

但是也是编程过程中碰到最多的一个东西

XP里面提倡怎么简单怎么设计,不要过分的设计

说起来很简单,其实很难把握

一方面要追求好的设计,一方面又不能过分

另外还要测试驱动

好的设计就得遵循一些基本的原则

比如面向接口,比如srp,比如可替换原则

一旦过分追求这些东西,又会导致过多的类,过度的抽象

另一方面,最简单的设计又是什么?

这个似乎也没有人说。

改善设计的基本方法是refactoring

不过,设计很容易扩大

比如,对于一个问题,很自然的想法是设计出一个非常好的解决方案或者改善现有的方案

而任何试图改善解决方案的设计都会导致更多的问题要解决,也就是要单独花很多的时间

不仅要更新一个实现,还要测试,还要修改受影响的代码 

而如果不改善呢? 也许现有的蹩脚方案总是让人不舒服,做起事来总觉得麻烦

那么到底是改善还是不改善呢?

而实际的约束是,过几天就deadline了

所以呢,那就先不改了,把deadline熬过去再说吧

不过呢,一般过了deadline人也就轻松了,又没有改变代码的动力了

而这个时候代码的质量已经下降

下一个deadline来到的时候,代码的质量又继续下降

到最后呢,不改不行了

怎么办呢,只有趁着deadline还不是那么紧的时候做refactoring或者改善设计了。

其实小的设计改动很方便

不过大的就会很麻烦了。

 

分门别类

最近搞robot的程序,本来觉得很简单的idea,结果越整越多,还不见完。也许是因为更加测试驱动了吧。有了测试,感觉确实好多了。确保每个零件都没问题。测试驱动带来的另外一个好处是模块化。其实对research发paper也有很大好处。现在感觉任何一个项目都要划分这么几个模块:

1.核心的数据结构模块。领域的概念,以及领域的基本逻辑。

2.io模块。一旦数据结构变得复杂,需要读写文件,定义文件格式。io就最好单独划分出来。也方便以后更改。

3.算法模块。算法非常易变,而且有可能会有不同的算法实现相同的问题。核心的数据结构相对来说变化小得多。

4.demo模块。对于图形图像,这个非常非常必要。图形图像的很多东西都没办法拿cppunit来测试的,必须的人看结果才行。demo主要也就是visualization。

5.simulation模块。这个可以生成ground truth来测试算法,以及其他的任何模块。

每个模块都要写单独的测试。

其实robot程序里面还包含其他的方面,根据任务来划分。比如图像处理,特征提取等等。这些和robot分开来,另立模块。 

乱七八糟

最近很忙,cvpr到底只搞了一篇,还是暑假的稿子。robot信誓旦旦要搞出来,结果程序越编越多,目标就像海市蜃楼一样,总觉得就在眼前,可是每走一步,总还是那么远。记点儿家里的事情:

准备让老爸签证的,但是材料寄丢了。下次得用快递。明年初再让老爸签吧。

嘉嘉已经会翻身,不过还不会连续翻。笑的时候能够偶尔发出声音了。睡觉还是很好,但是吃奶比较调皮。

旧的sony电脑坏掉了,买了台新的hp,4G内存,250G硬盘,算上税,减去rebate,合计680左右。速度很快,键盘很好使。感觉工作效率提高了很多。

老婆治了颗牙齿。最近有点儿过敏,经常打喷嚏,也没感冒。很多人在美国住上几年都会得这毛病,以前wang zheng也是。准备以后下午早点儿回来,陪老婆出门走走。

chen li结婚。谈了好几年,终于结了。据说伴娘在婚礼上昏倒,两次。

感恩节快到了,今年又在michael家。不知道michael现在怎么样。在婚礼上碰到pozhou,问他工作的事情。他说现在失业率比01年还高,如果有任何的面试机会,一定要尽全力的把握住,没有挑选的余地。他说michael也想去microsoft。michael现在在freescale,听说要裁人。

最近油价下跌的很厉害,已经不到两美元。老婆说这不是好兆头。

 

mrpt

the design is not good

very big classes, violate single responsibility principle

circular dependences, bayes and slam

big functions

interfaces are not clean

hard to reuse

defined a lot of macros

hard to maintain and debug

too many non-necessary comments

the layout of code is not consistant, data definition and function definition are interwined