NFFS2开发小结

 

NFFS2是我的第一个从无到有，完全在自己手里诞生的公司用的Project。现在到了项目尾声了，也该做个总结了。
其实这个小结应该早就开始做记录，然后再汇总。只是真的在忙的焦头烂额的时候没心情也根本想不起来，现在项目接近尾声了，很多东西又都忘了。没办法，只能想起来什么写什么了——应当随时记录问题和心得，这算是NO.1经验吧！

NO.2 合理预测开发周期
这是最要命的感受。刚开始在项目Design阶段的时候，Waterman要Bob给出项目的schedule。Bob给出的schedule是年前（2月底）release alfa版，年后两周 release beta版（包括所有文档等）。事实上到本周结束（5.11）project才算release beta版的基本code，像文档更新、性能优化等等都还没做，更不要提porting的工作了。不是我们进度慢，实在是一开始把一切工作想的太顺利，特别是debug的时间，远远超出预期。Schedule没订好的后果就是整个项目相当于没有schedule，还一直做的慌慌张张。记得以前听的一个笑话：Application Engineer自己估算需要3个月的时间，报给Manager是6个月，Manager报给Boss就变成了12个月！当时觉得好笑，想着真能偷懒。现在回过头看，兴许这样做才是经验之谈呢！——当然，如果对Prj把握能力很好，进度估算很准的Prj leader除外。

NO. 3 理性对待功能追求
在Design阶段，应当尽量多考虑可能实现哪些功能。但是当计划应当实现哪些功能时候，就要理性分析，表求多求全了。一是增加开发工作量；二是增加系统复杂度；三是有些东西当时想着是好的，可是后来就发现没用了，很郁闷。
像NFFS2中做PLR时候，我出于保证WL的考虑，要把old的BSTB中的age信息copy到new BSTB中。等alpha版本出来我就后悔了——time和memory的开销挺大，作用却在Performance Test中体现不出来——也就是说不能让用户直白的感受到，等于媚眼抛给瞎子看-_-!后来更是因为其它地方的code变动让age copy这块跟着出现bug，索性一怒之下直接把call this function给去掉了。其实当时design时候想的很好，现在看来只是仅仅注重到功能这一点，没综合考虑的结果。其它还有支持多个设备，支持后台GC等等，都是前期设计有，后面没时间精力去实现了。
所以还是应当只在文档上体现以后可能会增加哪些功能，具体实现时候还是简单、量力而行的好。如果怕以后再加功能不方便，只要在interface上做好就行了。正面例子就是NFFS_Malloc代替malloc，一直没实际意义，最后在performance test时候派上用场了。

No. 4 Coding Tips
>基本头文件布局
三个最常用的头文件：common.h, userdefine.h和datatype.h几乎每个.c都要include进去。考虑尽量减少头文件分布，所以原本只有common.h和datatype.h，userdefine.h省略到common.h中。结果common.h和datatype.h一开始没问题，后来不停的加东西的过程中就出现了互相需要包含的死锁问题，只能把共同需要又不依赖其它文件的部分提取出来，叫做userdefine.h。
No. 5 Debug Tips
>测试small block number，忘了large
原本是为了方便，只设置了32个block number来测试，后来pass居然忘了在4096 block上跑，等到快要release时候想起来，果然又遇到问题。于是中间一段时间就浪费了。
结论：做到哪一步，下一步该做什么，一定要有临时记录，人脑是靠不住的。
>位对齐问题
一个位对齐的问题出在编译器的不同解释上：系统在VC上通过，在ADS上report读取错误。因为在struct中定义了uint8类型的数组成员，而且之前的其它成员并非4byte对齐。本来这样做是有意想节省struct空间，可是在VC上没问题，在ADS上却要求数组必须从4byte对齐的位置开始读取——造成2个byte的读取偏差。