第三次作业

初读>1–5章

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

第一章：概论

　　囫囵吞枣的看完后，记忆最清晰的就大概是这三条公式吧。  

• • 　　　　       软件企业 = 软件 + 商业模式;
  • 　　       　　软件 = 程序 + 软件工程;
  • 　　       　　程序 = 数据结构 + 算法；

　　　三条公式由下至上， 仿佛如同一个地基到一座高楼一般，“数据结构” 和 “算法” 是基石，共同构建着着 程序 这块地基，而软件而是露在地平面之上的楼，商业模式则是楼内部的装饰。如此一想，仿佛开头提出的两个问题

1. 1. 　　　　为何要了解数据结构/span>
   2. 　　　　别人都把算法写好了，为何要了解算法/span>

 　　 心中有了答案，如果我的志向仅仅是用茅草和泥巴建成的土培房，确实是不用去了程序的数据结构。人言”熟读唐诗三百首，不会作诗也会吟。“，豪迈时吟一句“与耳同销万古愁”，悲愁时，叹一口：“自是人生长恨水长东！”，诗句纵然是前人的 ，可表达的情感·却是我们自己的！算法我想亦是如此，追求决策时间短就”贪心算法“，追求结果最好，就“动态规划”。

　　  不过这一章节最有趣的问题就是 “软件行业 赖以生存 的 软件 和 程序员 用来 安身立命 的 程序 是什么  其实很久以前，在上大学前我也有个疑惑  —-  为什么 程序员 要叫做 程序员，而 不叫软件员呢现在貌似有了自己的一些看法，我想大概是一个产品酝酿而生，程序员更多的关注是我要怎样去实现它，而忽略了我为什么要去实现它我觉得这是 软件 和 程序 的本质区别！ 因为有了为什么，就有了需求！有了需求 就有了用户！ 有了用户就有了其存在的商业价值。而这商业价值就是软件行业的生存基础，然而由算法和数据结构组成的程序并不在意这些。

　　如果说对于同一本书，一万个读者就有一万种想法。那么是否可以认为同一个商业价值，一万个软件企业就有一万种商业模式。作为大楼的内装修的商业模式则应该是大楼最核心的竞争力，决定着成败。结合1.2.4中有提到三点中的第一点： 研发符合用户需求的软件。回答练习的3-4的那个问题：

　　　　同一类软件是如何竞争的/span>

　　想起了作者所在微软公司的office和本土金山公司的wps。前者有交钱买断，也有每年交钱两种模式。后者则是免费使用，但要看广告。作为用户来说，对这类软件的需求，我不是很高，比如现在敲着的这段作业啊，作业啊，作业啊。所能用到的功能不是很多，使用的需求仅仅是为了应付而提交一份作业，如果都使用正版的话，wps虽然小，功能少，但貌似满足于我这类人的需求绰绰有余，其代价无非就是弹出广告而已，或者支付89元每年，尚能接受。但微软的office使用正版的个人版、学生版每年得花费398，而永久版得花费748是否难以让人接受。书中提到当通过实际的工作收集，推导，提炼需求。应来自于现实，而不是自己想象出来的需求，或者人云亦云的需求。office与wps相比，一个几百M不到，一个2个多g，在功能上自然是天和地的差距，推开window系统自带的office捆绑销售不说，正版为何难以在中国个体消费者中推行，是否是因为此类消费者不会为那些几乎不会用到的功能买单nbsp; 相比于专业版offcie来说功能确实要少的很多，但相比于个人需求来说确实又太大了。书中讲过乔布斯和iohone的故事：乔布斯将设计师认为设计的最小的iphone丢进水里，说iphone冒泡证明还可以再缩小iphone的体积，结果推出了新的iphone；想问，作为office来说，是否可以推出更精简而更廉价的版本那些需要不同拓展功能的人进行按需收费这种商业模式更加合理/span>

　　顺便想回答下3-3的问题：

　　　　软件是如何处理Bug的是如何更新版本的/span>

　　想不谈软件，就想谈下这本书的三个版本的前言，觉得跟软件的更新很想像。第一个版前言讲述了很多作者自己的经历，说实在话，我没怎么认真看，其中最吸引我的就是那几幅移山公司成员的图片，提起了让我对另外一本书《移山之道》的兴趣。如果把这个看成是软件的话，这里确实是如高效老师说法，很独特，很活泼，让我没有之前的软件工程的书看着的枯燥无味。虽然没读过前面的版本，真的打开了我对软件工程的兴趣大门，让我思考了很多问题。

　　如果把修改看成消灭Bug的话，第二版与第一版的变化只是填补了之前的漏洞。

　　第三版以一个免费书箱的小故事开头，和作者给我的互动，感觉是我与作者最亲近的一次，仿佛作者就在我身边传教一样。

　　单从这三个版本的前言来看，我觉得从吸引力来说   第三版 > 第一版 > 第二版,为了验证我的猜想，还查阅了豆瓣上的评分，由第一版到第三版的评分分别是 8.6  8.1  9.2。

　　我想软件也是如此吧，版本的更新可能是修补了旧版本的bug，也可能是增加的新的元素。对于一个软件的版本，一般新元素是质的变化，是版本小数点左边的变化，而修补bug则是小数点右边的变化。

第二章：  个人技术和流程

       单元测试，资料是指对软件中的最小可测试单元进行检查和验证。其中，最令我不解的就是这“最小”的定义！以前人们认为原子是最小的，却可以拆为电子和原子核，电子和原子核的运转是否是算成更小的单元，而更小的单元原子核也可以拆分成不同的夸克，我想问如何去定义自己的单元模块，单元 过小 会不会像小飞说的，人们忙着写单元测试，没时间开发间的度量如何取舍/span>

　　理解了很多单元测试的优点，和应该注意的事项，同时也对其无能为力的地方进行了了解。面对这样无能为力的地方又有什么小技巧吗有就是，有的时候，一些接口是别人的，我需要将我的交给别人运行，或者别人的要放在我者运行，而别人的数据又不知道安全与否，又该如何进行单元测试呢上查阅，这种问题要提前沟通，商量和约定。但是假设对方未按约定进行数据处理，而且对方的单元的要放在我的单元里运行或交互，一旦出现问题便很难解决，因为无法知道是那边出了问题。这时候我自然要假设对方数据的安全性，但是如果两边都做了同一个数据的单元测试，却又感觉影响工作效率。

　　在作者向我们提了一个问题：

　　　　面对飞机被炸开的洞，飞机程序应该考虑覆盖这种情况吗/span>

　　我觉得应该要，但不用这么细微，因为很多时候很多细小的东西难以考虑到，而且只用考虑到飞机出现意外的情况如何应对仅可，而不一定要具体的考虑是哪一种意外。飞机的意外有很多种，我想飞机的设计者也没有可能考虑到所有意外情况，应该是将意外分级别归类，进行处理，如：轻微受损正常飞行完再检修，一般受损就近机场降落，严重受损，紧急迫降。单元测试是否也可如此/span>

　　当作者谈到我们最明智的完成了老师作业时，仿佛人生第一次从老师中找到了知音，确实如此。但是随后的一步步说明，给我敲响了很大的警钟，期末的大作业是无法满足后面提到的任何一个需求。正如作者所讲，我自己的一个类过于臃肿，往任意一个方向拓展，修改都不如推倒重来，可拓展性是极差的。如何去拓展这些伴随着我之后的学习而找到答案吧。

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

　　作者说，什么样的数据能说明一个软件工程师的技术和能力量能力的参数有那些作者看来，有五方面的成长

　　　　　　积累软件开发的硬知识，

　　　　　　积累问题领域的丰富经验

　　　　　　对通用软件设计思想的理解和软件工程思想的理解

　　　　　　提升职业技术

　　　　　　实际成果的结果

　　　再结合https://www.cnblogs.com/xinz/p/3852177.html中如何评价自己的成长，曾经一度自我感觉良好，感觉学的还可以，却在第一部分就被问题难住了，基本每一个问题都触及到了我的知识盲区，仿佛我什么都不会。然而我已经大三了，再过两年就要走出学校这座温柔的象牙塔了，闯荡江湖。对自己深表担忧。以前，如苦海行舟，东划划，西划划，如无头苍蝇，而这些问题让我知道了很多不足，当计划大学剩下的时光当如何利用了。在软件工程师的误区中感触很深，写大作业时常也有类似的想法，常想用老师教的方法豪情万丈，最后却又不得不接受现实，明白要从脚下做起。才发现我所了解的不过是魔方的第二层，对口诀了解，知其然而不之其所以然。在习题1中问我会选哪一种医生开刀看病：

　　　　　　a　　 刚在书上看病，开刀严谨，时不时还要看书。。。。

　　　　　　b　　富有创新，想拿你做新技术，刀法的试验

　　　　　　c　　经验丰富，游刃有余的医生

　　　　　　d　　无认证，但号称有秘方，可治百病。

　　要是我选，我自然会选择第三种，最稳妥，最安全，最值得让人信奈。但是这便更让我疑惑了，之前看过《window编程设计》第五版的一些，很多人认为是编程圣经一般的书。开始看真可谓是味同爵蜡，可以说是噩梦吧，又多又难，对于一个初学c的人，更是一脸懵逼。一开始理解 “handle” ，回调函数 这些花了很多时间都难以下咽。至今依旧记得其中一句话的大概意思：  “不要过多的去咀嚼每一块知识，不求甚解反而能学得更轻松，走的更远。”， 感觉其并不是不无道理，开始过多的深入了是否会一叶障目，不见泰山之全貌。对于书中的原理机制，该书作者说实际上即使是已经写了几年windows程序的人，也可能并不怎么能背下来DIB，api，时常也是用到再细查。而这种看病的方法仿佛是第一种边看书边下药，对此深表迷茫。

第四章：　两人合作

　　书中提到结对编程，感觉原来和一个舍友写大作业也确实是这样做的，一起想一个问题，提出自己的看法，对于同一个模块我们共同书写，但是感觉这种在学校里难以推行。因为老师是要给每一个人打分的，当老师问道我们的大作业的时候每个人写了哪些时，这种结对编程感觉难以划分，因为仿佛我们涉猎了全部，但大作业毕竟是作业，按量给分。和同伴分开写后，虽然是完成同一个作业，但是事先划分好谁要写那些，仿佛另外一半又事不关己，只要做好我自己的就行了，不能对整个作业有所了解，这也并非老师的预期吧码的阅读很难，两个人的风格不同，比如，我喜欢下划线命名，而他喜欢驼峰命名，双方看对方的代码是否会觉得别扭，阅读别人写的代码时，确实难以理解，而自己也尚未考虑到这些。

　　自己写代码，时常感觉代码保质期短，过三天尚能记得，但是三月之后，仿佛读别人写的代码般，有时写大作业，还未完成，便已经开始腐烂。是否保证了这些书写规范，代码就没有那么容易腐烂言，代码腐烂的原因有很多，不同的书写风格，多人同时修改同一模块。而其谈到解决方法就是多沟通。对于一份需要补丁的代码，多沟通，确实能够解决这些问题，但是，之前windows曾出现一些严重bug这种特殊时期，微软能在几天内修改并补上这个bug，又是如何做到的代码不腐烂而高效的沟通/span>

第五章：　团队和流程

 　　文中所说，一个团队成员各自分工，相互依赖，有一致的目标，且有各自不同的分工，在领头开展一个全新的项目时一定要选择合适的团队模式。

　　本文让我了解知道不同流程有不同流程的局限性，但是流程走下来，有不同的人经手，需求调研和最终设计软件的人可能不是同一批人，一些职位也是应运流程而生，诸如产品经理，系统架构师之类，每类人负责不同的地方，他们又是如何交接的呢软件工程的思路，将开发软件按一定的流水线进行工业化开发，但是人并非机器，加工和转述会出现很多问题。

　　有这样一个游戏，由第一个人获取一长段话，然后转述给下一个人听，如此循环反复，直到最后一个人将他听到再讲出来，看和第一个获取的那段话是否相近。但结果往往是大相径庭。

　　软件的流程视乎也是这样，老板提出一个新的想法，或者从客户手中拿到一份订，然后跟产品经理讲述自己宏伟的梦想，产品经理听完后按老板的梦想，进行调研，提出了若干需求，架构师根据这些需求后进行分析，设计出框架，然后让底下的码农进行更细一步详细设计和编码。这其中，从客户到最终的实现者，经手了这么多手，软件设计出来最后是否也和客户需求大相径庭该如何避免这些流程中的交接问题呢如习题6说，现代软件工程分为4个阶段

　　和pm吵架 -> 和设计吵架 -> 和测试吵架 -> 和用户吵架

　　对此深表疑惑，之前平安银行曾有个笑话，产品经理和程序员吵架，前者要一个根据随便的一个手机壳变换主题的软件，而后者认为前者异想天开。但现在仔细想想，前者似乎更懂需求，却不懂技术；后者懂技术，却难以找到需求，都是因为自己涉及的知识面所致。假设产品经理懂技术，知其不可行，便不会提这样的需求。但是这样，又需要你编码的人干嘛呢佛又回到了那个破桶的死循环。

转载于:https://www.cnblogs.com/destinymingyun/p/9748993.html

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34422 人正在系统学习中 相关资源：wax_tasks:使用蜡Wa处理收集数据的实用程序任务-其它代码类资源…

来源：Angela?cc