软件基础第二次作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/zjlg/rjjc20
这个作业的目标	通读构建之法，提出三个困惑
姓名-学号	高晟慧-2018330301141

第一个问题

我看了这一段文字

是虫子(Bug),还是肉芽?不同的人有不同的答案。软件行业也有一句著名的笑话:这不是缺陷,这是一个功能(I's not a bug, its a feature )多人认为有Bug就是质量不合格,没有Bug就是质量完美,其实这也未必。移山软件学院的小芳同学穿了一条新的牛仔裤,她的同学果冻看到后就善意地上前提醒:裤腿上有两个洞,赶紧去退货!这是bug,还是feature ?我们在大街上看到很多不同品牌的汽车,这些汽车出厂时都通过了行业的质量标准。但是你问路人哪些车的“质量好”,很多人会告诉你有些车的质量大大好于另外一些车,那为什么还有人买那些质量“不够好”的汽车呢?对于某些顾客来说,某一类的汽车满足了他们的需求,他们就会买。
--引用自《构建之法》P17

事例：伙计取下壁上挂的一块乌黑油腻的东西，请他们赏鉴，嘴里连说："好味道！"引得自己口水要流，生怕经这几位客人的馋眼睛一看，肥肉会减瘦了。肉上一条蛆虫从腻睡里惊醒......伙计忙伸指头按着这嫩肥软白的东西，轻轻一捺，在肉面的尘垢上划了一条乌光油润的痕迹，像新浇的柏油路，一壁说："没有什么呀！"顾尔谦冒火，连声质问他："难道我们眼睛是瞎的？"大家也说："岂有此理！"......肉里另有两条蛆也闻声探头出现。伙计再没法毁尸灭迹，只反复说："你们不吃，有人要吃--我吃给你们看--"店主拔出嘴里的旱烟筒，劝告道："这不是虫呀，没有关系的，这叫'肉芽'--'肉'--'芽'。"方鸿渐引申说："你们这店里吃的东西都会发芽，不但是肉。"
我查了资料，有这些说法：有人认为，有危害的就是bug，有好处的就是feature。也有人认为不符合需求的都属于bug，也就是缺陷，这些是需要解决的，如果测试人员没有发现，遗漏到生产环境，这是事故！
我的思考与疑惑：客户使用软件中出现Bug，比如闪退，游戏中人物跑出地图，物体位置偏移等问题设计者通过处理Bug，软件才会有不断的优化，客户才会选择你，同时客户的需求不断产生，设计者通过满足客户需求，对软件进行升级。就像当今手机的发展，每年不断地推出新款，不断会有人去更新自己手里的手机，也像书上的例子牛仔裤上有了两个破洞，有时并不是裤子破了，而是特意这样设计的，所以应该如何区分这是Bug还是feature呢？有些Bug可以任它存在，可以变成feature，那这具体的标准又是什么呢？

第二个问题

我看了这一段文字

一种极端情况是想弄清楚所有细节、所有依赖关系之后再动手,心理上过于悲观,不想修复问题,由了问题都赖在相关问题上。分析太多,腿都麻了,没法起步前进,故得名“分析麻痹"(Analsis Paralyis)下面是工程师果冻和项目经理大牛之间的对话":
木桶有一个洞,咋办啊,大牛?
修哇,果冻!
用啥来修啊,大牛?
用租麻绳把它堵上,果冻麻绳太长,咋办啊,大牛?
用刀砍短啊,果冻!
刀太钝,咋办啊,大牛?
磨刀啊,果东
磨刀石大干，咋办啊,大牛?
拿木桶去取水啊,果冻!
木桶有一个洞,咋办啊,大牛?
...
--引用自《构建之法》P48

事例：犹如书上事例，有时我在平时学习思考中遇到问题，找解决措施，继续追根溯源，可能又回到了原来的问题，不能解决源头的问题，就无法打破这种“死循环”。初学C语言时，按照书上的例子一点一点写函数，每个函数只考虑自己的功能实现，丝毫不顾及与其他部分的调用配合，在功能增加，函数增加的时候，参数总是要修改很久，有些甚至结构都要修改，到头来可能还是要返工。
我查了资料，有这些说法：第一点，对于需求分，弄清楚用户想干什么，要经过多次的沟通并且参与到业务的流程，沟通过程。第二点，框架设计，需要分析主流框架，技术栈，编程语言，团队或个人已有的技术储备，代码托管方式，产品自动构建，基本上就是可靠性，易用性，可扩展性，安全性，可维护性；第三点，模块设计，开始分解功能需求，划分代码模块，理清模块依赖关系，接口关系，原则是低耦合，高内聚，可复用，可扩展。
我的思考与疑惑：我知道了软件的模块之间存在着各种复杂的依赖关系，又因为软件的易变性和不可见性，各个模块之前的关系更加难以定义清楚。当面对软件的维护和修复任务时，面对纷繁复杂的系统，困于其中的依赖关系，无法前行，短时间也无法将整个框架流程看清楚。对于要解决一个全局性的问题，应该怎么避免上述问题？如果遇到这种“死循环”，应该怎么打破？

第三个问题

我看了这一段文字

每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中,因为有随时的复审和交流,程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样,程序中的错误就会少得多,程序的初始质量会高很多,这样会省下很多以后修改、测试的时间。
--引用自《构建之法》P79

事例：相声也是两人合作，却也面临拆对的问题，团队合作总会遇到“猪队友”。
我查了资料，有这些说法：两个人配对成功，就像合作生意一样，1、双方足够信任。2、双方足够了解。3、双方能否包容。4、当意见不一致时，双方能否一起解决达成共识。
我的思考与疑惑：两个人的合作，不可能是一帆风顺的。第一，两个人合作，势必有一方水平高于另一方，就算两人互相督促，互相进步，但两人难免会有差距，而程序质量取决于水平较高的一位，那么双方的付出或者资源肯定不会平均，水平较高的一位是否会有一些矛盾？第二，结对合作中，任何一成员都影响项目，“猪队友”可能一开始不会被察觉，合作很愉快，但是中途或者后期发现队员开始有懒惰懈怠或者其他问题后，那么这个项目是需要将就一下继续完成还是直接独自完成还是找一个新队友重新磨合？