关于第二次阅读作业中"银弹"“大泥球”等的个人理解

     这几天时间比较充裕，就一点一点的借助英语翻译(毕竟英语不好)阅读了一下老师建议的论文作品。感觉他们的思维和我们的是不在一个角度上的，在我们看来，编写代码的任务仅仅就是实现了设计文档中的功能，而这些在课程设计中往往能满足要求，但是在长远方向看和软件优化的角度来思考，我们的设计都是极其糟糕的。。。。。

     大师的角度中，程序员实现软件最最本质的东西，就是软件在概念抽象和应用于电脑上的两个方面，软件在概念上的抽象性设计解决方案是很困难的，而软件施行与电脑上也是具有挑战性。在大师的启发下，我对4个方面的困难有了如下理解：

      1.复杂性：软件设计的解决方案中计算步骤不可或缺，人为的抽象化活动则往往复杂化了软件开发的进程，对程序员来每个人都有不一样的构思和抽象，在我们的代码实现中，往往只涉及到简单的算法步骤就能得到时间的优化，然而对于每种不同的实际情况，算法对应的时间资源消耗也会有好有坏，至于考虑优化再优化的算法，则往往要综合各种可能的情况和计算，这对于我们来说是很困难的。

      概念层次是一种极其抽象的层次，对于真正实现的代码来说，概念模式中还得涉及很多数据间的利用依赖关系和流动控制，概念层次上的完全解决时不可能的，对于大工程来说则更加困难。

      2. 隐匿性：我们无法正确评估尚未完成的代码工程，因为其结构没有完全显现出来，作为团队开发方面则往往不能及时沟通协商，在之前的个人和团队编程中，我们往往在完成了代码的编辑任务和个人的开发模块后在综合调试慢慢完成代码的，但是这样实际上也是不太科学的方法，如果在进行的同时能够及时在结构和计算方面有所总结改正，则代码的质量也能得到提高，但是这样的方法对于我们来说异常困难。

      3.配合性：对于大型软件，由于时间和环境在实际中的变化可能会对各个模块的接口等等沟通部分产生改变，维护其一致性则往往使人们头疼。对于课程的编程训练往往不会有这种顾虑，但是在实际的软件开发中，模块编程之间的配合协议以及按实际情况变化的同步性也是代码质量的体现，子系统的配合一致性往往在环境的变化之中很难维持。

      4.易变性：软件的应用毕竟不是一成不变的，而是针对与某一种需求的情况下实现的，但是在实际情况下，人群需求、硬件、应用领域等环境因素的变化往往会导致软件的适合要求的性质大打折扣。我们也会说软件的实现往往对于某些既定的需求设计来说达到了比较完备的要求性，但是在变化的另外一种环境下不优化的，应对这种变化的软件易变性也是一个困难。

      在个人项目和结对项目的过程中，我们则注重算法功能的实现，对于算法的优化来说，我们也只是有所涉及，但是这只是局部的解决方案，例如在单词统计的cpp中我的算法解决了老师提出的要求，但是在面临大数据的查询的时候就会消耗很多的时间资源，而且代码的算法也不是最适合解决问题的优化算法，所以没有什么实际的用处。在电梯的调度方案中，两个人的编程之间也不是有足够的交流，只有在代码连接的时候发现了很多问题最后花了较长时间来改正。以上4个方面都使得软件开发的难度加大。对于目前比较统一的编程语言、软件，附属困难得到了很大的改进，对于现在我们的能力而言，稳固算法方面的知识，培养良好的合作意识和沟通能力，学会举一反三，多多早软件开发方面考虑以上4种情况，相信对于我们的能力锻炼和软件的开发质量都有提高。

      在回顾我自己写的代码，也和“大泥球”差不多了。大泥球的定义，则是指随意化杂乱无章的系统，体现在代码随意堆砌拼凑，往往会对软件开发带来难度以及很多错误。我们每个人的目标，无非于写出逻辑思维严密，结构紧凑，易于阅读维护的代码，这样利于多人合作编写软件的相互沟通和代码的维护和风格良好。但是我们也要说，不可能每个程序都是完美无缺的，就上述的易变性来说，我们设计的作品往往能较好的映射于一种用户需求，往往实际情况的变化又会使我们的设计产生BUG，而且在软件设计的本身也得产生并解决很多bug。所以对于避免“大泥球”式的软件设计带来的时间效益的负面效果，我们也得有所反思：

       对于用户的需求得做到全面的分析，考虑到特殊情况，其解决方案在保证解决上述问题的途中也要具有灵活性，而不局限于当前的需求。

      代码风格要清晰，每一部分都有规定的需求而不是添砖加醋。能够对编程语言和环境有深刻的认识，学会利用现有的资源简化代码。

       软件开发室要有足够丰富的沟通交流动态的发现问题并解决，对于每一个阶段能够正确做到每一部分的评估。

       综合来说，准备不充分，碎片式增长，缺乏技巧、交流都是“大泥球”的因素。

       多在优化和测试方面下功夫，我的词频查找代码中3个不同需求查找的方法显得冗余，并且不能灵活运用其中的类库的格式简化，导致时间需求大大增加。在团队设计方面，对于算法理解的不充分使得算法在解决大部分问题方面满足要求，但是对于特殊情况就gg了。所以在算法设计-代码编写-调试测试3个流程阶段都应该有所研究并优化。

       现阶段对于软件开发来说，本质的问题仍然存在没办法消除，但是人们也在积极研究各种有利与开发和调试的方法，比如统一的编程环境和编程语言以及时间片共享，高级语言则使我们专注于方法上的设计而不用关注底层汇编方面的信息，高级语言实现概念模型的理念虽然舍弃了部分效率（对于低级语言来说），但是使得软件开发变得简单。而对于不同编程语言的编程环境中也给予了很多编程的库类和框架，我们进行引用既能简洁代码，也间接统一了模块之间的接口等，是个人模块的完成以及模块对接提供了很大的方便。这对于我们来说有很大的启发意义。

     最后对于软件工程方法论的理解，文章上说，方法无形，但是不能形而上。我理解到，代码的行数体现出代码的简洁性，但是不能完全说明开发人员的能力，而开发的软件成功的度量似乎是能否完成预期的需求目标，但是很少有人知道项目活动成功失败的内在，实际的软件也是复杂的并且没有规律的。我们在编写代码的时候也会遇到其中的问题，考虑不完全导致算法的漏洞，沟通不完全导致调试的困难，对于每个编程者来说，我们都应该通过不断的尝试和实践提高自身的职业素质以及能力，文章最后强调建立一个学习能力和适应能力都很强的组织，我觉得也就是说软件工程的开发本身就存在着很多变数，环境、需求、思考方向以及合作组织的不同都可能导致软件工程的很多困难，所以不能简单的按代码以及功能方面的评估来全局的评价一个人或者团体。我们也不能太依赖于团体，团体中大家分工协作完成各自的任务，不断交流完善达到优化，这不仅仅是一个实践的过程，一个作业的完成，也是个人能力的提高和软件质量的体现，对于我们来说，及时提高自己的算法设计能力和代码编程能力，及时做好自己份内的工作，同时团队之间达到相互适应，及时磨合，软件工程的效果才能越来越好。

      对于结对编程来说，我和队友在分别实现代码理解和代码编写的两个阶段中相对比较独立，缺少模块接口一致性以及算法研究方面的探讨，导致最初设计的算法效果并不太好。而在第二次设计的时候我们则仔细研究了源码，明确了接口方面的定义实现并且相互学习了双方的优点，我的代码编程能力得到了提高，同时对算法的理解也有了新的认识，队友的编程风格也有了提高。总之，软件开发方法论是一个抽象的概念，没有确切的准则，只有自身的约束以及团队间的时应以及配合的重点是要实际践行的。    

     所以回顾了自己开学来编程的历程，我也存在许多的毛病：

     1.算法的设计不够完备，不能做到“三思而后行”。

     2.代码的优化还有待提高，减少冗余，使用同一的库，框架等。

     3.缺少交流，团队项目在算法的设计实现方面都应该吸取各家精华，并且有良好的规范保障软件开发的流畅。

     希望在以后的程序编写中自己能做到尽量优化，避免”大泥球“，多多参与团队项目，学习提高自身能力，及时交流，及时评估，提高软件开发速度兼并质量；培养创新思维，有所突破，一步一步走向专业化。