【工作感悟】完整项目的第一个里程碑感想

三个月的试用期结束了，说实话，对于转正方面的事，一点感觉都没有，闯哥和生哥他们没事还谈论一下转正的事，而我根本没仔细考虑过，也许真的没什么关系吧，除了可能加点工资，然后把医疗保险等各种各样的卡发下来，也就不会有什么特别的了吧。麻烦！

经过2个月的努力，又一次得到了同事的肯定，感觉自己像火影里的鸣人，异常期盼着同伴的认可，所以在 cf  和 anxinboyin 给我以鼓励和肯定的时候我都非常的激动。

        黄金周过去了，我们的项目也进入了第二个里程碑，在短暂的调整之后，又要开始紧张的“战斗”了。说实话，这一阶段学到了很多东西，我记性超级烂，所以一定要记下来。

<需求>
        如果要评出大学期间最讨厌的专业课，那我一定会毫不犹豫的说是“软件工程”，原因很简单，跟政治一样的东西，作为一个工科的专业，我想谁也不会愿意去背那些不痛不痒的理论知识。然而，进入公司后，原来以为最不重要的东西，现在发现是最重要的。如果一个项目，没有软件工程的管理，将会是何等的混乱！其产品的可靠性，也就可想而知。
        软件开发的第一个流程就是需求分析，上大学那时候觉得需求、设计、编码、测试这几项中最简单的就是他，客户说什么，我们做什么就行了呗。现在想想，当时的想法幼稚的可笑！经过了这次“实战”，才明白为什么需求分析要占到整个项目15%的工作量，我们平时与机器打交道，写出的程序对，机器就会给我们正确的显示；错，机器就会给我们Error、Warning或者崩掉。但是需求是要和人打交道的，别人想要的东西，我们不可能马上完全的理解，如果觉得这样就可以了，我们理解的差不多了，然后就去设计，可能会发现我们设计完了，开始写代码的时候，有些需求我们没考虑，而这些被要求的功能，可能颠覆我们之前的设计！QCD中的Q和D都不容易保障！如果不仔细分析需求，那么很可能错过一些隐藏的需求，造成后期的风险。
        再者，需求分析是要指导设计的，不能完全体现功能需求的设计，即使他再有弹性，再漂亮，也不是好的设计，因此需求分析的“粒度”就需要十分的明确，不能在需求文档中写那些含糊其辞的东西，要尽量简洁，也要绝对详细，用一句同事们经常说的话，随便来过来一个人，看你的文档，就知道你要做什么！这就是需求分析的“粒度”的标准。

<设计>
       由于我们工具的特殊性，所以在第一个里程碑结束后，我们的设计和最终成果物的Demo已经出来了，先说设计！
       设计是一个反复推敲的过程，而设计的优劣，最直观的体现就是他是否能够在变化面前，能够从容的应对！因此我们在设计的同时要考虑实现现在需求里的东西，也要考虑以后可能加入到需求里的东西，这个尺寸需要拿捏的比较恰当，只考虑实现当前需求，会造成我们的设计在变化面前，像飞在天上的风筝一样脆弱；过分考虑以后的需求，又会造成我们的设计大而全，没有重点，又过于复杂。这时候就需要设计模式，需要OO的帮助，更需要经验。最近在看两本书《深入浅出设计模式》和《深入浅出OOAD》，获益匪浅，也把一些东西付诸实践，比如我们的设计就用到了单件模式，而实现单件模式的方法就是通过一个代理模式的思想做到的，这样提高了效率，规范了动作，两者兼得！我和 anxinboyin 作出这样漂亮的东西后，着实兴奋了一天！
       不得不提到的是在设计阶段 anxinboyin 的一个理念就是规范动作，让拥有相似数据段的类型拥有一致的数据结构，这样在处理时可以将耦合程度降至仅对这段数据，而不是整个对象，（呵呵，这句好像不太容易说清楚，打个比方来说，一个对象需要某种服务，而使用这种服务，需要向提供服务的类型传入数据，而这些服务在一定程度上像模板方法模式一样是一组纵向的方法，因此把数据块的各段规范一下，在解析时，就可达到模板方法一样的效果）
       在设计阶段另一个工作重点就是编写设计文档，这时就要利用UML和流程图来表达自己的思想，文档要规范，不然就会给以后的维护带来困难。因此在写文档时必须注意命名方式的统一，绘制UML图和流程图的风格的统一。还有就是多用图来表达自己的想法，因为40页以上的设计文档，字看多了，谁都会头疼。

<编码>
       代码要从三个角度来讲：
       1.最简单的就是编码风格的统一，这时需要依赖编码规范，要让项目中多个人写的代码，就像一个人写的代码一样“整齐”。变量的命名，函数的命名方式要让人能够“顾名思义”。代码的逻辑要简单，不太容易理解的地方一定要加注释。
       2.效率，效率问题往往和代码的复杂程度有一定关系，高效率的代码往往不容易理解。这就需要折中，有两个小技巧可以借鉴，用do while（false）来避免多个return；在多情况判断的时候将可能性大的放在前面。
       3.最不容易做到的放在最后，他也是一种style，这个style并不像编码规范那样肤浅，但是却非常重要，有些书可以借鉴《Exception C++ Style》《Effictive C++》等，利用书中提到的原则进行编码，可以让我们的代码更加健壮！（在写这条的时候，我担心这种感悟是不是有点大了，但是仔细想想，由于自己看过的C++方面的书很多，水平不高但也不是初级，加之同伴 anxinboyin 水平比较高，我们在编写Demo的过程中已经大量的用到了上面提到的两本书中的原则，因此这条也不算太“大”，呵呵）

<同行评审>
       第一次听说这个词是一篇介绍 Boost 库的文章里，当时翻译的好像是什么“同僚复审”，整的好像很高深的样子，到底是什么意思我到现在也不确定，但是在开发过程中，我们使用的“同行评审”，确实是提高我们产品质量的好的手段。
       俗话说“三个臭皮匠，顶个诸葛亮”，把我们做出来的成果，不论是文档还是代码，拿出来让其他同事看看，检查以下，这样就可能把其中的一些隐含问题找到，“一个”人考虑的方面可能不会很全，“一个”人的经验也不会比大家的经验总和高，所以这种review绝对会提高我们产品的质量。

<原因分析～缺陷预防>
       在评审中发现的问题，可能并不仅仅是这一个人的问题，别人也可能会犯同样的问题，所以我们需要“原因分析”，这并不是在批评某一个人犯了多么“低级”/“严重”的错误，而是告诉大家，这样的错误是如何产生的，以及如何做能够避免这样的错误，这就是“缺陷预防”。有的时候可能找不到本质问题，但是只要把问题“留档”，总会有一天把问题的本质揪出来！

<CMM>
       当初我不理解为什么要规定CMM的5个等级，现在终于明白了，其实我们做过的同行评审，原因分析和缺陷预防都是从CMM中得来的。我们老大说过，要把自己提升到全局的高度去看问题，才会有进步。管理为什么重要，我想亲身经理一下都会有体会。

        期待phase2的进步！