【Dongle】【机房合作】之个人感谢

        从2016年5月16日到2016年6月5日，历时21天，工时289个小时，与小伙伴一起完成了一次合作开发机房收费系统。这个过程中肯定少不了磕绊，但最终我们三个都向着做好这个项目前进，共同商讨，一同调试问题，一起完善。这个过程中充分展现了合作的轻松。

        整个过程我将它分为前中后期四个时期，每个时期都存在一定的问题，当然更多的是收获和学习。

过程

前期

        前期是最重要的，也是用时最长的一个阶段。这个时期有两个工作。

        首先是查，查相关的机房合作项目，这里不是去看代码，而是去咨询机房合作的注意事项，学习合作开发的经验，从而能够准确高效的完成项目。

       其次，就是针对文档有一个全面的详细的设计。好的项目离不开好的设计。而一个好的设计，在这里就需要小组内共同参与了。做为组长，我并没有比组员对机房合作有更深的设计，思路比较古板，故而，采用小组内共同讨论，可以有更合理的设计。

       在这个阶段中，我们存在的主要问题就是对于UML图的认识存在异议和对设计模式的运用不清楚。在UML图上，我们三个每个人都有各自的理解，主要是针对B层设计存在异议，经常因为B层的设计讨论半天，然后也没有什么结果，从而浪费了时间。在设计模式上，有主张多用设计模式，有人则不敢用，也有人是不知道怎么用，从而是谁也说服不了谁的结局。不过，由于我们意识到时间问题，从而最终想到统一想法，先设计出来看看，这才没有产生更坏的结果。

       所以，在这个阶段中，我个人认为，项目开发讨论时可以有的，但是不能不注重效率问题，当想法得不到认可时，先去设计出来或者多去考虑别人的想法，试着去统一，而不是浪费太多的时间在争吵上。

中期

       中期就是代码部分，通过前面UML图的绘制，用EA生成代码，这少了我们重新写框架的过程，从而在很大程度上提高了效率问题。只不过，在代码中我们容易犯一个错误，就是没有完全按照生成的类和方法写，可能今天想到这个方法没有，就填上，后天想到那个方法没有再补上，等到写到后来的时候，才发现，原来方法是存在的，自己补充的是多余的，而在这个过程中存在了时间浪费的问题。计划中代码时间是3天，结果用了5天，超出了计划60%，从这能体现出亮点：一是对于分工认识不到位，基本还是走的个人路线；二是前期准备不足，对于详细的内容设计不足。

        不过也通过这个代码，学习到：尽量先将自己前期设计好的写，毕竟前期的设计中一条线是成功，不会出现明显性错误。如果确定是忽略了什么，应该记录下来，积极反应，可能一个人理解不了，多个人能理解。如果是都认为存在问题才可以修改。

后期

       则是项目代码完成，进行调错的过程。在这个期间，我们能更好的发现自己编程中的问题。

       比如在用户界面，考虑步骤，对用户的输入或选择忽略限制条件，经常容易导致数据无法继续进行，说白了就是数据类型设计的不合理，对于用户该输入什么，不该输入什么说明的不充分，从而导致用户操作了得不到想要的结果。

       并且，在调错的过程中，异常经常出现，然后导致项目终止，才发现原来没有异常处理的过程。如果用户因为各种原因导致系统崩溃，难道还要让用户看到内部代码的异常？这明显是不合适的。所以异常处理是有必要的。

       所以，从这个调试阶段，能够 发现我们并未站在用户的角度去设计系统，虽然实现了用户的要求，但是实现这个要求，完全是按照“我们”的思想设计，从而导致系统脱离用户，最终只会导致用户不接受这个系统，付出得不到回报，因为用户认为这个系统不值得有回报！！！

时间

       这个环节是将我们在合作上所花费的时间记录下来，以便我们能够更好的了解我们的效率问题。

       通过上面数据显示出，我们在合作上面肯用时间，努力去做好它。只不过，看着时间的积累，也暴露出一个问题，那就是效率问题。

效率

       效率为什么会存在问题，又是如何产生的，应该如何提高效率？

why？

       网搜一下，效率（efficiency）是指有用功率对驱动功率的比值，同时也引申出了多种含义。效率也分为很多种，比如机械效率（mechanical efficiency）、热效率（thermal efficiency ）等。效率与做功的快慢没有直接关系。而这里我们主要是介绍一下工作效率，这个在网上也有介绍。

       工作效率，一般指工作产出与投入之比，通俗地讲就是在进行某任务时，取得的成绩与所用时间、精力、金钱等的比值。产出大于投入，就是正效率；产出小于投入，就是负效率。工作效率是评定工作能力的重要指标。提高工作效率就是要求正效率值不断增大。一个人的工作能力如何，很大程度上看工作效率的高低。

 那么为什么会存在这个问题呢？原因在于我们对工作细节的不重视，从而导致点点滴滴的原因导致工作效率出现问题。

How？

       回想到合作的点点滴滴，我个人认为产生效率的因素有以下几点：

       首先，计划模糊。再开始之初，只是做了大概的计划，比如文档什么时候完成，代码什么时候敲，测试什么时候开始什么的，没有认真详细的去设计每一天该做什么。每天的工作是摸棱两可的，任务是不确定的，没有规定每一天具体的工作，从而导致每天需要大量时间考虑需要做什么，应该做什么，应该完成什么等。

       其次，有心无力。对于机房合作的七层，我们都有了一定的了解，但是在重构的时候总感觉代码还是重复率比较高，希望可以再重构一下。想法是好的，但是不知道该怎么去实现，尤其是在B层设计的时候，我们小组前前后后讨论了有三四天的时间，一直确定不下来。最后我们设计的是按照方法分，但是现在系统设计完成之后，发现这样也并不合适，因为方法太过散乱，从而导致B层类“泛滥成灾”，我不知道给系统的会造成什么影响，但是就我自己去找，都感觉有点累，相信电脑也会累吧。而这恰恰反映了一个问题，那就是知识量。由于身为组长的我对于七层理解不够好，导致出现这种问题，责任怪我。所以这个时间段造成的浪费，我该负全责的。

       然后，隐形拖延。在机房合作中，有时候总会出现拖延的症状，并且每次都认为那是合理的，故而每天开始想好的计划，这一天的结束仍旧完不成，一个人完不成，其他层也就需要放缓速度，从而导致全组拖延，造成时间的浪费。

Solution

        根据上面总结的效率产生因素，做出对应的解决方法：

       第一，计划清晰。不仅仅要计划概况，还要在每一阶段中计划好每一天的工作任务。最好每天结束前找个时间开个小组会议，总结一下当天的工作。

       第二，博览群书。这里不仅仅是只是读书哦，更多的是我们去查查相关的设计思路，可以去问做过的或做过类似的项目的人，或者去网上查查，总有人也会存在相同问题的。项目启动前的必要了解是不可或缺的！

       第三，实行责任制。每天规定必须完成额任务，完成有奖，反之有罚。如果出去工作了，这肯定不只是这么友善的处理了，可能公司就因为你的一个完不成给项目拖延了时间，从而导致公司亏损，那时候公司让你“辞退”都是好的了。所以这个每天工作任务是必须要完成的。当然，前提是安排额或被安排的任务是合理的，如果不合理，及时调整或向上反映，不要不声不吭的，那样出了问题，都没地方“哭爹喊娘”的了。

       第四，积极活跃。积极的人，每天都会按时完成工作，并且还可以学习其他知识，还能为团队其他人带来正能量，能够间接为项目按时或提前完成做出贡献。

       第五，劳逸结合。做事，比较忌讳一直不停的做一件事，那样极容易产生烦躁、厌恶的心情，合适的作息时间，可以让我们保持充足的活力投入到工作中。所以，有个时间管理软件是不错的主意哦！