最进在开发和维护一个文件服务器。刚开始的时候是随行开发，也没想那么多。（好吧，我在为自己找借口）
由于文件服务器的初级版本已经进入到生产环境的集成测试中，在同事拿着文件服务器部署的过程中，出现了很多问题，配置不够集中，说明文档不全面，Balabalabala。。。。。
之前的设计是外部想文件服务器发送一个创建文件请求，文件服务器在自己的目录下创建一个文件，并把文件路径返回给调用者。随着有时间回顾之前的代码，问题出现了，业务条件（文件路径）已经和文件服务器的持久层绑定在一起。Wo ca ,惊掉下巴，这是老子写的代码吗？怎么这么烂！！！what。。。。。
咋解决呢，第一个想法是，改变现有的业务处理接口，即外部发送文件创建请求，文件服务器创建文件后，文件服务器返回给调用者一个文件id，这样就解耦了，文件服务器的文件存储结构就可以随心而动、随意而行了，Ya Mie Die!Donot stop!~
还有一个替代方案是创建一个映射层，这样就可以兼容之前兄弟们的代码了，即文件服务器在对内部文件进行移动操作时要在数据表里保存移动之前的文件路径和移动之后的文件路径。之前的请求仍然可以按照路径的方式来请求文件服务（文件内容读取、创建文件等），当服务器接受请求后，从参数中获取请求的文件id，当发现文件id不存在时，则获取文件路径参数。然后在数据表里查询文件和映射路径（看请求的文件被射到那里去了），如果文件存在则把当前对文件的操作映射到目标文件上，如果不存在就前请求服务返回文件不存在的信息。
今天最大的收获不是找到了解决问题的方法，而是。。。。。。（总结我还没想好——）
有了这两种方案后，我想，还是彻底的通知业务层把业务中这个文件的路径都改成文件的id吧，这样文件服务器多简洁，多清爽啊，毫无测漏啊！
我就和大家说，要是那么小改动一下，赢下大不大！
大家balabalabala (省略一万字)， 不行！！！！！
谁叫我人品不好呢，最近装孙子中，认了！
但回头想一想，第二种方案才是最贴切实际的，你不能指望不管你之前设计的好不好，底层服务在发生变动时，要以兼容的角度考虑这个问题，然后在后续的版本中彻底解决冗余问题。这才是解决问题的王道，和老兄本人活着的方式一样，不要给他人添麻烦。
好吧，在最后感谢我的对手和朋友，感谢你们让我愈发强大，谢谢。