最近做工程比较多，其实也就是实验室的事吧，以后工作了也是会工程任务比较多吧。

    为了方便自己积累经验，有很多工程性的东西是需要注意的，这些经验性的东西积累起来应该会给以后的工作带来很多好处。就像设计模式一样，都是一些处理相关问题的经验型方法，如果能很好地整理并且掌握这些经验，对很好的提高自己的工程能力吧。

    这次要讲述程序工作目录相关问题，不注意的话可能会出问题哦。

    比如说现在让你完成一个组件，如果用C++的方式来描述，就是说你要完成一个库，这个库可以是静态库也可以是动态库，让别人调用你。正好你的库程序需要读取配置文件，当然这个配置文件是你自己定义的。

    那么这个时候问题来了，你往往会喜欢使用相对目录作为寻找这些文件的路径。但是你的库如果被挪了位置呢？比如说同事把你的静态库文件挪到了他自己的lib目录下，而没有把你的库需要读取的配置文件一并挪过去，于是你的程序就无法定位到那些文件，于是出问题了。

    这个时候你的同事可能会要求你改，他希望你改成不依赖库所在位置，还能正常读取配置文件。

不好的解决方法：

    这个时候你可能会想那好办，我在程序里面加一句程序，将当前工作目录指向我之前放置这些配置文件的目录不就解决问题了嘛。比如说在C++中，你可以使用unistd.h头文件下的chdir来改变当前工作目录。

    仔细想想，为什么说这个方法不好？你想，别人调用你的静态库，那么很有可能他自己维护了一套相对路径。那么这个时候好了，你把整个程序的当前工作目录改变了，那完了，对方的那一套路径都乱掉了。于是调用你程序的人一牵涉到读取文件的地方，统统出问题了。

    其实就是说，被调用者的程序，最好是不要改变当前整个程序的工作状态，包括当前工作目录呀，至少如果改变了要通知调用者。

    你可能会想，那好吧，我每次修改当前工作目录之前，把原来的工作目录保存下来，等我执行完了我的程序再把当前工作目录改回去。当然如果你能保证这样调用不出问题，那也算是勉强可行吧，只要你愿意在你调用的地方都这样做。

一种妥协的解决方法：

    其实这个方法也没有什么特别的，但是从个人经验和可扩展性上来讲，我觉得都是不错的解决方法。

    首先你自己在写程序的时候，你要明确你的库有一个运行时目录，也就是你要读取的配置文件、程序运行的log或者其他程序依赖的东西都应该在这个目录下。那么好了，当别人调用你的库，你要让对方指定你的运行目录，也就是传递给你一个路径，你的模块运行的需要的东西都应该在这个目录下。

    于是好了，你的同事可以把你的库放到任何位置，只需要调用你函数时，正确指定你的模块运行时路径就行了。这样他就可以安心的把你的.so或.a文件移到他工程目录的lib目录下，并且另外指定一个目录作为该模块的运行时目录。这样你的模块的输入输出，写文件、读文件就都指向到了这个目录，有什么问题也能很好的排查了。

结束语

    这个问题你们有的人应该也碰到过，如果还没碰到的朋友，可以稍稍留心一下这种解决方法，就避免后面来回修改程序。

    当然这种经验的总结算不上什么高大上的算法，然而实际上在工程中，正是这一点点的经验，大大的提高了开发效率，帮助我们设计出更好的程序。

    如果朋友们有什么更好的方法来解决这个问题，欢迎一起讨论。谢谢。

在工程中积累经验 之 程序目录使用二三事