Postmortem of Individual Project-----By Yishi Xing

上周提交了个人项目，殷老师针对所有人的结果做了一些反馈，听完觉得收获很大，现在这里对自己的完成情况也做一些小结。

做项目的核心一句话就是“细节决定成败”，这一次是深深体会到了，因为从这句话分析自己做出来的东西只能说是满目疮痍。首先得从项目要求说起，这是做一个东西最基本需要遵循的。不得不非常遗憾的说，我在这一点上做的非常不好。殷老师不管是在上课，邮件，还是MSRA组织的live interview上都强调过对项目要求刨根问底这件事情，但是我仍然没有去做，这大概是在学校流于应付完成任务了事的坏习惯所致吧。尽管已经明确提到统计词频的“词”的要求是至少2个字母组成的英文单词，我最后仍然我行我素的认为’a’是一个单词；第二，要求也明确提到命令行下的输入参数是“可执行文件名，根目录名，通配符”的形式，但是我最后直接用了“可执行文件名，根目录”作为输入参数，不仅违背了要求，还给老师测试程序带来了麻烦。如果说不清楚项目要求对于个人项目只是个人的失误，那对于团队项目则会造成毁灭性的损失，所以说做项目不仅仅是要关注核心算法的实现，外围接口和许多细节上的设置也必须给以同等的留心。

除了对项目内容的关心不足以外，我做这个作业暴露的另一个重要问题就是对于代码的管理很不到位。做的还过得去的地方是变量命名和代码格式，我觉得这应该算是最基本的要求了。做的不好的第一点是注释。看别人代码的时候总是抱怨别人不在改写的地方写好注释，实际到自己身上也是一样的问题。词频统计的递归遍历文件夹部分我就写得很乱，几乎没有注释，搞得后面输入参数错了也懒得再改。注释的好处还是很多的，不仅是对看代码的人，也对写代码的人本身修改带来方便。第二是错误处理上面几乎是一片空白，只有在fopen这种函数上有写error产生的处理，像是输入参数中路径名、文件名不存在这种情况下的错误处理我都没有考虑。第三是magic number的问题，我发现这是我写code上的一个顽疾，总是图方便随便拍脑袋就写出一些匪夷所思的数字在代码段里面，还不写注释，这样不管是自己后来修改还是别人看都会有障碍。第四则是warning的处理，有很多函数都有一般版本和安全版本，visual studio会用warning的方式提醒应该更换哪些函数。殷老师还提到实际工程项目上面大家常常会把warning当作error看待，以保证最终delivery的稳定性，我觉得这种做法在以后可以作为一种参考标准。

其实，就连最终打包提交的内容我也没有弄对，实际上应该将整个solution中删去obj和pdb等自己build产生的临时文件删掉后全部提交。而我只是提交了可执行的exe文件和源文件，这又暴露了我的经验不足。

还有一项很大的收获是使用visual studio的功能profile来检查程序的时间主要消耗在哪些位置。还有一个感觉就是以我目前的水平估计代码量和时间方面其实很不靠谱，虽说代码行数最后估计得确实差不多…时间上则估计得非常不准，在结构和算法部分实际上花的时间比估计少挺多的。这还是代码写的太少的原因，只有通过不断地一次一次的训练才能找到感觉。

 

 

Work items	Time Estimation	Actual Time
Algorithm and implement   language decision	3*2h	~1h
Structures and Classes design	1*2h	~1h
Implementation	2*4h	~1*4h
Debug	1*4h	~1*4h
Optimization	2*2h	<2h
Total	24h	~12h