我的阅读做业 --软件工程M1/M2总结

软件工程M1/M2总结

---

 

写在前面的话：

　　这学期的软件工程伴着考期的展开逐渐落下帷幕，回顾这学期的软件工程，我感受个人热情在一次又一次的失落中逐步消耗殆尽，每一个人对于这门课的体验都会有所不一样吧，能够肯定的是软件工程的方法论很是重要，于实践中的应用也很是重要。可是这是否就天然而然的衍生出咱们对于这门课程发自心里的承认呢？我认为这个问题还值得继续探讨。

进入正题：

　　这学期开始时进行了第一次的阅读做业，经过对于《构建之法》的快速阅读，我提出了对于软件工程方法论的5个问题。

　　这学期的软件工程课程临近尾声，回头来看这些问题都有了一个较为深入的认识。

 

　　问题1.第四章谈到了两人合做，在这个过程当中假若结对的两我的能力是相近的，如何达到高效的开发，若是两我的的能力是互补的，又如何达到高效的开发？

　　这学期的结对编程主要存在于两个场景。一个是在结对编程做业中实现一个四则运算的程序，这一做业带有强制性的要求咱们经过结对编程来实现；另一个是在团队项目中，因为M2阶段各类大做业纷至沓来，包括编译课设，数据库课设，C2，Android等，软工项目实际开发的时间相较于M1阶段要少不少，为了提升总体的开发效率而采用的自主的结对编程方法，即经过结对编程达到快速，高效的交流开发目的，从而防止由于交流问题而引入新的bug。

　　在经过一学期的结对编程实践后，我对于这一问题有了本身的认识，即不论两我的的能力是相近仍是互补，在结对编程的实践中深刻的交流相当重要，此外，假若两我的能力相近，能够由两我的共同承担核心功能的实现，而若是两我的的能力互补，则应当把功能切分为尽量相互独立的子模块，每一个人来实现本身较为擅长的模块，对于一样不擅长的模块实现则由学习效率高的同窗为主导，经过两我的之间的沟通来协做完成。

 

　　问题2.在第六章敏捷开发中，我认为软件设计的可扩展性对于敏捷开发至关重要，而软件的可扩展性应当从那些方面来考虑？即如何作到在需求不断变化的状况下，仍不至于不停地推倒重来？

　　在这一学期的实践中，对于软件的可扩展性有了一个进一步的认识，在我看来，在软件开发以前对于用户需求的详细分析相当重要，在这一阶段需求分析要尽量的详细和完善，要从用户的角度出发而非开发者的角度，考虑用户需求可能的变化，要尽量的为以后的设计留有余地。

　　软件框架构建的好坏每每取决于架构师的水平，对于已经归入考虑的基础功能则予以着重考虑，对于在构建阶段已经被用户抛弃的需求则须要进行深刻探讨，假若不存在继续实现的必要性，则将其从基本功能中删去，对于在构建过程当中用户提出的新功能则进行重要性判断，通常若是需求分析作的足够充分的话，这样的新增需求每每不是核心功能，而是附加功能，对于这些功能的实现亦归入框架搭建中考虑的范畴。

 

　　问题3.在第十二章谈到了用户体验，有时候确实存在用户体验和产品质量不可兼具的问题，如何抉择？

　　经过这一个学期的实践，我认为若是将产品的开发分红多个迭代周期的话，那么，咱们能够考虑先在M1阶段实现产品的基本功能，即知足产品发布的最小要求，即保证产品的质量，而对于用户体验的优化能够放到M2来作，固然，在M1阶段若是不进行相应用户体验的优化，那么至少应当为M2阶段进行优化提供必要的接口，保证在产品的总体架构上不会出现兼容性的问题。

 

　　问题4.在软件的开发过程当中是否时时须要具有有防护性编程的意识，这样可能使问题复杂化，或者仅须要按照设计规格来实现相应功能？

　　这个问题在实践中主要依靠契约式编程思想来实现，防护性编程思想当然重要，可是有时候并无必要时时对于参数合理性进行验证，不然会产生异常冗余的代码以及很是尴尬的编程体验。

　　然而不进行验证并不意味着会出错，在使用契约时编程思想时候，全部软件构建的参与者都会遵照相关抽象设计，即在函数的调用过程当中事先知足函数的前置条件以及后置条件的约束，在知足这些条件的状况下才认为软件的执行知足不变性，即软件的正确性才能有形式化的保证，才能经过形式化的手段来验证软件的正确性。

 

　　问题5.在团队合做中，成员之间须要良好的沟通来完成，有没有什么必要的沟通原则和技巧？

　　在博客的回复中助教谈到了“unconscious bias”，在查阅相关资料后我了解到：无心识偏见的产生是由咱们的环境和自身经验所决定的。因为咱们的思惟是在不断地处理信息数据，而当咱们对问题的分析过程当中若是缺少相关的数据，那么咱们无心识的偏见就填补了这一空白，从而影响了咱们相互之间的沟通效果。如今已经有愈来愈多的科学家研究无心识偏见和咱们如何防止它的负面影响对于咱们决策的危害。

　　在我看来，无心识偏见对于沟通的影响很是严重，在咱们进行沟通以及对于事物进行价值判断的时候能够经过对于相关领域作出相应的充分研究以后再作出判断，而非凭借着无心识偏见作出所谓“经验上”的判断。

 

软件工程中概念的再认识：

　　经过这一学期的软件工程理论的实践，我对于其中一些概念有了更加深入的认识，主要包括有：

• No Silver Bullet：强调软件工程自身的复杂性以及多变性致使软件工程不一样于摩尔定律所描述的硬件的增加速率那样，使得咱们可以有肯定的可期待的通用的优化方法可以使软件生产率获得成倍的提升。

• Big Ball of Mud：强调代码只是杂乱无章的堆砌，没有进行结构化的设计，致使在开发的后期出现许多错误和缺陷，能够采用以下方法避免大泥球：在软件设计阶段首先须要关注软件的特性和功能，而后集中在架构和性能，使得软件设计之初就避免产生问题或者方向的误差。其次，在编写软件时要及时解决出现的小问题或者原型概念等等，这样不会使得问题堆积致使后期的没法修改。

• The Cathedral and the Bazaar：描述了两种软件开发模式，其中大教堂模式的软件开发让程式除错的时间大幅增长，由于只有少数的开发者可参与修改工做。市集模式则相反。

• A Generation Lost in the Bazaar：描述了集市模式致使的一个悲哀的现实：成堆的权宜代码被一群盲目的根本不知IT架构为什么物的所谓IT“专业人士”永无休止地复制着，粘贴着。针对这一现象最有效的解决方式是：所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一我的，不能是几我的——二重奏除外。个人理解是针对软件的架构师必需要负责整个软件的生命周期，由于，软件的开发人员可能更迭，若是架构师不负责软件的维护，那么后续的开发人员对于软件很难有一个良好的把控，只能不明因此地沿用前人的代码，而没法对于已通过时甚至错误的代码作出适当的删改，致使软件的碎片化，以及文中指出的那样对于早已过期的Fortan编译器兼容性的检测。

•  Waterfall Model：在《构建之法》第五章(P107)谈到了瀑布模型，瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，而且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，最终获得软件产品。瀑布模型的突出优势是：可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增长更多的功能。每次迭代必须通过质量和集成测试。瀑布模型的突出缺点是：因为开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增长了开发风险，此外这样的开发过程难以适应用户需求的变化。

• Agile Methods：在团队项目开发的过程当中用到的敏捷开发的思想主要有：采用迭代的方式来对于不可预见过程进行控制，采用SCRUM进行软件开发的进度管理。把一个项目分红若干个为期两周的迭代阶段，每一阶段为一“冲”（sprint〕。天天有一个短会，这样管理者能对项目有近距离的观察与控制。

 

知识点回顾：

　　对于软件工程项目实现过程当中的各个阶段：需求、设计、实现、测试、发布、维护，每一个阶段都学到了不一样的知识点，归纳以下：

• 需求：需求阶段主要的知识点是需求分析的“NABCD”模型。
• 设计：设计阶段主要的知识点是典型用户和场景分析以及功能说明书和技术说明书的撰写。
• 实现：实现阶段主要的知识点是对于实现流程的把握 。
• 测试：测试阶段主要的知识点是几种测试方法，包括单元测试，回归测试，以及场景测试。
• 发布：发布阶段主要的知识点是对于项目的回顾与反思（postmortem）。
• 维护：维护阶段主要的知识点是接受用户的反馈，并进行软件的维护。