第三次作业

这个作业的要求来自于：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178。

       在这个愉悦的国庆小长假，我仔细阅读了《构建之法》1-5章，对软件工程这门课有了全新的认识。在阅读过程中我产生了一些疑惑，并对问题进行多方查询，有了自己的见解和分析。

第一章：概论

        看完了这一章的内容，我重新认识了软件工程的定义，作者的观点是 认为“软件=程序+软件工程”，而一个扩展的结论是“软件企业=软件+商业模式”，我赞同作者的观点，因为现在的软件基本都是商业化软件，所以现在的软件都与商业模式有着不可分割的联系。软件工程主要包括了软件需求分析、软件设计，软件构建。软件测试和软件维护。实际上软件工程就是一个系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。软件的特殊性在于软件的分类上的差异，可分为三大主类，分别是系统软件、应用软件和恶意软件等。在软件开发的过程中遇到的特别难题也分为5个方面，分别是复杂性，不可见性，易变性，服从性和非连续性。这5个特性是瓦茨拉夫·拉里奇提到的。

       在这一章中，我看了这一段文字程序在高速运行，突然发生了一个异常，我们的程序能否正常工作，安然退出，并保证数据不被破坏？有了跟作者一样的问题。 我查了资料，有这些说法，用户手动杀死进程，依然会调用activity的onpause，onstop，onDestory方法，但是突然抛出未捕获的异常，并不会执行activtiy生命周期的任何方法，因此考虑在用户输入的时候，数据及时实例化进内存，然后在用户手动退出时(调用onStop方法后)进行数据的清除。根据我的实践，我得到这些经验在去年学期末的安卓大作业中，我做了个需要用jdbc连接数据库来对用户输入的数据实现操作，但是因为溢出问题，经常出现“程序闪退”的现象，再此之前，我输入的用户数据都不被保存，下次运行又需要重新录入。 但是我还是不太懂，我的困惑是在程序发生异常是，能否在保证数据不被破坏的前提下，让程序安逸退出。

第二章：个人技术与流程

       看了这一章的内容，我认识了单元测试的主要方法以及好的单元测试的评价标准，在小飞和阿超的对话中让我更透彻地了解了程序员的测试逻辑。在效能分析工具中的两种分析方法是抽样和代码注入。抽样的优点是不需要改动程序，运行较快，就可以很快找到瓶颈，但是不能得出精确的数据，也不能准确表示代码中的调用关系数。

而代码注入的缺点是程序的运行时间会大大加长，还会产生大的数据文件，也相应增加了 数据分析的时间。同时，注入的代码也影响了程序的真实运行情况。在2.3个人开发流程中，我了解了卡内基梅隆大学的能力成熟度模型是用来衡量一个团队能力的一套模型。CMU的专家们针对软件工程师也有一套模型叫PSP。

      在这一章中，我看了这一段文字处理空的字符串，长度为0 的字符串，都是空格的字符串......，有这个问题：有没有一个方法，能一次性解决这3个难题， 我查了资料，有这些说法：

以下是 Java 判断字符串是否为空的三种方法.

方法一: 最多人使用的一个方法, 直观, 方便, 但效率很低.
1：if(s == null || s.equals(""));
方法二: 比较字符串长度, 效率高, 是我知道的最好一个方法.
2：if(s == null || s.length() <= 0);
方法三: Java SE 6.0 才开始提供的方法, 效率和方法二几乎相等, 但出于兼容性考虑, 推荐使用方法
3：if(s == null || s.isEmpty());

根据我的实践，我得到这些经验，长度为0和都是空格的字符串和空字符串都是不同的判断方法。但是我还是不太懂，我的困惑是能不能将所有单元都聚合一起测试能省下很多时间。

第三章：软件工程师的成长

      看了这一章的内容，这一章的理论和知识点是评价软件工程师水平的方法，技能的方面。TSP对个人的要求，软件工程师的思维误区。在3.1的个人能力的衡量与发展中，了解了职业的定义以及工作的质量还有一个工程师的成长之路包括职业技能和工程思想。那么软件开发的工作量和质量怎么衡量呢？PSP认为有4个因素：项目/任务有多大？花了多久？质量如何？是否按时交付？在3.3的软件工程师的职业发展，可以看出队长职业的态度等级以及专与精的关系。发展路上的考证，面试也是成为一个优秀的工程师的必经之路。

      在这一章中，我看了这一段文字为什么一个高级工程师会比新手工资高那么多？除了比工作年头之外，软件工程师还有什么更好的方法来衡量自己的能力和价值？有了这个问题：怎么学还是使自己成为一名优秀的软件工程师，我查了资料，有这些说法：

------------------ 来自 322829 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/u011155153/article/details/51459315?utm_source=copy -------------

1.      需求分析能力

    对于软件工程师而言，理解需求就可以完成合格的代码，但是对于研发项目的组织和管理者，他们不但要理解客户需求，更多时候还要自行制定一些需求。

 

2.      项目设计方法和流程处理能力

    软件开发工程师必须能够掌握不少于两到三种的项目设计方法，并能够根据项目需求和资源搭配来选择合适的设计方法进行项目的整体设计。

 

3.      复用设计和模块化分解能力 

　　作为一个从事模块任务的软件开发工程师，他需要对他所面对的特定功能模块的复用性进行考虑，而作为一个系统分析人员，他要面对的问题复杂的多，需要对整体系统按照一种模块化的分析能力分解为很多可复用的功能模块和函数，并针对每一模块形成一个独立的设计需求。

 

4.      整体项目评估能力

    作为系统设计人员，必须能够从全局出发，对项目又整体的清醒认识，比如公司的资源配置是否合理和到位，比如工程进度安排是否能最大化体现效率又不至于无法按期完成。

 

5.      团队组织管理能力

　  完成一个项目工程，需要团队的齐心协力，下面为大家介绍一些技术性的指标和因素：

　　（1）工作的量化 

    没有量化就很难做到合适的绩效考核，而程序量化又不是简单的代码行数可以计算的，因此要求技术管理人员需要能真正评估一个模块的复杂性和工作量。 

　　（2）对团队协作模式的调整

    一个优秀的软件开发工程师应该能够根据程序员之间的能力水平差距，以及根据项目研发的需求，选择合适的组队方式，并能将责权和成员的工作任务紧密结合，这样才能最大发挥组队的效率。 

    由此可见，想要成为一名优秀的软件开发工程师，除了具备专业素质之外，还要有一定的管理能力，所以，在学习的时候一定要注重全面发展。

------------------ 来自 322829 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/u011155153/article/details/51459315?utm_source=copy ------------- 

但是我还是不懂，我的困惑是怎么判断自己是否已经成为一名合格的软件工程师？

 

第四章：两人合作

       在第四章的内容中，我大致了解了现在主流的代码风格规范，其大致表现在缩进、行宽、括号、断行与空白的{}行、分行、命名、下划线、 大小写、注释。代码设计规范主要表现在函数、goto语句的限制于使用、错误处理、断言，还了解了具体如何处理C++中的类。在4.4代码复审中，认清了代码复审的意义以及代码复审的步骤实现，代码复审的核查表主要包括概要部分、设计规范部分，代码规范部分，具体代码部分，效能、可读性和可测试性。为什么要结对编程？一对程序员肩并肩、平等地、互补地进行开发工作。他们并排坐在一台电脑前，面对同一个显示器，使用同个键盘，同个鼠标一起工作。他们一起分析，一起设计，一起写测试用例，一起编码，一起做单元测试，一起做集成测试，一起写文档，等等。结对编程能提供更好的设计质量和代码质量，能带来更多的信心，高质量的产出能带来更好的满足感，结对能更有效的交流，相互学习传递经验，分享知识，能更好的应对人员流动。两人合作的不同阶段：萌芽->磨合->规范->创造->解体。

       在这一章中，我看了这一段文字团队内部不可能没有矛盾。但是矛盾不是一开始就爆发的，它有自己的生命周期，有不同的发展阶段......有了这个问题：对于不同的阶段产生的矛盾，是否都能够和解？，我查了资料，一篇名为程序员的生存定律https://blog.csdn.net/surgent777/article/details/49662245 中写到了程序员如何在职场中生存，以及矛盾的化解。

但我还是不懂的地方是化解了工作上的矛盾，但是人心的隔阂怎么才能化解。

 

第五章：团队和流程

        看完第五章的结对编程，两个人好交流意见，产生分歧不大，换做是团队合作会怎么样呢？会不会尚未从结对编程中脱离出来，对团队合作感到混乱，不会分工，不便于交流？所以我们要学会需找合适的团队合作模式和开发流程。书本上提到了很多的团队合作模式和开发流程，都各有优缺点。仅仅从校园合作的角度出发，我认为使用功能团队模式更适合彼此合作交流，而开发流程在校园合作阶段，容易被忽视或是考虑的不全面，大伙要着重培养。看了很多软件团队的模式，有主治医生模式，明星模式，社区模式等等。以及功能团队模式，有官僚模式。开发流程有写了再改模式等。看完还是没能理清团队如何合作，团队里的每一个人负责什么。但是时代在变，信息在变，我们的需求也在变，这个时候我们就由最初的瀑布模型变形发展成了圆形模型，在这个模型中我们可以随时根据客户的要求更改需求分析，并编写出更符合时代需求的程序。

       在这一章中，我看了很多的软件团队模式，有了这个问题：如何更好了认清团队？管理团队？我查了资料，首先团队合作有很多模式，我们应该确立我们的模式，这样才能更好的分配任务，并且对团队的每个成员利益最大化。我觉得我们的团队更像是交响乐团模式，大家都有各自的有点，但是更要跟随指挥的节奏，这样才能把曲目演奏好，同样的，我们的团队也能把合作项目完美的完成。但是我还是有不懂的地方，就是要怎么样确立我们的团队模式？

总结

        通过这个国庆的小长假，我阅读了《构建之法》1-5章，收益不小，让我更清楚的了解到了软件的概念，软件的定义以及软件生产过程中的各个阶段的主要内容和手段，还有一个优秀的软件工程师的成长和培养，以及团队之间的协助和配合对于软件开发流程的重要。软件开发的各个流程都非常值得重视，一个好的软件和坏的软件在其生存过程中已经奠定了它的价值。书中以阿超、国栋、小飞、小李的多次对话内容更能让我以程序员的角度面对和考虑问题，我觉得这点是比较好的。