第一次做项目的总结报告。现在看起来，有些问题稍显幼稚，有些问题也能有所借鉴。将总结进行到底！

--------------------------------------------------------

１、对于设计review的时候，如果感觉review人的设计对其他类似机能有借鉴的意义的话可以通知相关的人，采取自愿的方式参加。

好处就是：可以让其他类似的机能的设计节省时间，或者也可能为被review人提出一些建议，当然这也是活的方式，主要还是权衡利弊，再作决定是否实行。我觉得有必要考虑这个问题。尤其是对新加入项目组的人，对有些做法不熟悉，避免同样的事情要对不同的人都说一遍。

２、项目总结对于一个有长期类似项目的项目组来说是非常重要的，而且有关总结也应该有一个统一的管理，以便以后项目组人员的调整引起一切要从头开始的局面。这也对每个人的发展有很大的帮助。

项目开始的想法没有落实到位：

1、每一周都要进行担当对自己对应的模块的式样讲解：

    没有落实到位的原因可能有两条：①时间的问题，也是主要的问题。②还是leader自己没有考虑好这样做是否对本项目以及以后的项目有多大的帮助，而没有信心将这件事落实到底。

2、对式样理解的问题列表：

    这个是leader的想法不错，但是担当没有彻底的落实，导致以后作工程的时候出现比较多的试样理解上的问题。

    对于试样理解的问题主要有两个原因：①担当自己的原因，讲解试样的时候就没有完全理解或是当时理解了，后来没有不时地回顾试样的要求，导致以后的试样理解不足产生的问题点。

    这应该是主要的原因。②日方的试样的设计不足导致试样的变更，这个可能也是不可避免的，不可能一步设计到位。这方面导致的问题，担当也要负责任，因为没有对自己的试样跟踪到底，掌握试样的最新变化。

３、关于checklist的使用：

checklist个人认为还是很有用的东西，它可能会包含很多的经验、大家通常会犯的错误，如果用上的话就会避免很多问题的出现。但是我们这次项目用的不多。

如果可能的话就将各种可以产生成果物的工作完成后都可以有一个checklist来遵循进行检查。这样每个担当就不用老是记着干完每一件要check什么项目。人总是有大意的时候。所以，如果有checklist担当只要养成一个做完一件事后，对照checklist进行检查就可以了。

４、编码规约的执行问题：

对于编码规约要彻底的执行，这个问题要担当主要，也是codereview的一部分内容。这个对于有过项目经验的人应该不是什么问题。对于刚刚接触项目的新人要特别的注意这个问题了。

５、对于一个大的工程，要事先将各个子系统的编码类名等统一风格。

６、干活不能干一半啊，还不如不干呢！

自己的东西自己负责，自己进行check。要是被别人检查出来，就是你的无能！！！！！

无论时间多么的紧也要坚持这个习惯，一定要自己检查一遍，就像检查别人的成果物一样。你就是leader！！！一定要有这个信念。

７、统一建工程，必要？

８、Vss的利用要统一，统一管理source文件和class文件。

９、要尽可能的早定文档的名称，模版，页眉页脚的格式内容。否则就会耽误担当的时间来统一已经很乱的各式各样的文档了。

１０、       共享问题，如果发现问题是共通的，或是有共通的可能。要发mail和大家共享问题现象和解决方案。

11、关于vss上共通文件的管理：

①本机做一个别名文件，存放自己追加或者变更的配置信息；

②将VSS上的配置文件checkout到本机（一定要获取最新版），然后将别名文件上的内容合并到该文件上去，及时checkin。

③对于共通的文件一定不要长时间的checkout，否则会影响其他人的工作。

１１、       写代码的同时，要将log加上。Log也应该在整个工程开始之前统一一个做法。

１２、    关于测试的问题：

感觉我们的测试总体水平还是很一般，急需提高，同时我们的责任感也急需提高。单体测试的结果不理想，水平问题也只是占一部分，最重要的还是我的责任感的问题。要对自己做过的东西负责。

各种一览的利用：

1、问题一览

2、残件一览

----------------------------------------------------------