阅读代码，画图，然后重构，单元测试……搞定了数据库部分。

　　被数据结构的细节所纠缠。由于性能原因，无法使用通用数据库平台，只能自行开发一个数据服务。用各种酶在不同修饰条件下，对几十G 蛋白质数据进行酶切，得到肽离子，建立索引（即使最小的库，都有将近九千万条，而且每新增一种酶或修饰，数量还要翻倍），然后用文件映射方式，通过共享内存提供服务。

　　其实我很欣赏系统最初的体系结构设计。但是由于1.5版deadline很紧张，老板施加了巨大的压力。为赶进度，工程师编程顾不上接口和重构，产生了大量的耦合和拷贝，弄得整个架构动弹不得。我接手后，只好回过头用几倍的时间阅读和重构代码，何苦呢？

　　彻底重新设计了数据访问类，用一个纯虚父类做接口，隔开其他部分。每种具体实现方式作为一个子类，比如目前读取共享内存的代码。还打算把1.0版不通过索引的数据访问方式代码也移植过来，实现另外一个子类，提供给系统内存小于1.5G的用户。

　　固定了接口，新版本就可以再实现其他数据访问方式，比如通过关系型数据库和Web Service提供数据服务。用关系型数据库的话，为保证效率满足Web应用，就必须用集群或网格了。这种情况一般都考虑Oracle，但涉及到老板的银子……听说Google采用MySQL，很希望知道他们的方案。

　　今天跑通了单元测试案例，用的是马（Horse）的蛋白质库，不加任何修饰。Debug版访问所有肽链一遍，2.266秒。以前还真没对付过这种级别的海量数据。

BTW：早上去了趟所里，玩了玩曙光3000，酷。

　　士气很高，可能因为pFind开发进度顺利吧。算法层的单元测试案例完成后，就可以放心把各个模块留给博士们独立开发了。开始画应用层SDK的业务流程。周四下午拖着别人开会。傻乎乎的外行问题、写写擦擦的白板、乱七八糟的稿纸。周五整天都在修改Visio图。每30分钟拿着修改稿跑去访问（或者说骚扰更合适）一圈，好累，总算把系统业务流程严谨地定义到白纸黑字上了。下周被其他项目拖住的工程师也能过来了，要启动新的里程碑了，嘿嘿。

　　交流真是一种技能。很多时候，你以为懂了，达成一致了，其实没有。必须把细节清楚列在纸上，拿给人家看，被认同，这才算数。

　　例子太多了。比如我找几个博士聊过很多次后，仍然以为蛋白质片段匹配的误差分析，是各种质谱类型对应不同的统计图；直到在业务流程上写注释，才意识到可能有误解。跑去一问，原来所有质谱都应该提供多种误差分析工具，只不过生物学家针对每种质谱类型有不同侧重。实际上，调查对象已经多次明显表达出这个意思了，但我的耳朵一直在按软件工程师的思路去听。系统分析像是深入陌生的专业领域签合同，应该始终提醒自己，与领域专家的交流要虚心，提问要细致再细致，总结文档要明确再明确。

　　BTW:老板原则很“完美”，不仅要求牛paper，还要实现真正可用的商业级系统。纸上漂亮的模型遇到实际数据不一定管用，实验室的博士生真比别处辛苦。