| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/zjlg/rjjc20 |
|---|---|
| 这个作业的目标 | <通过阅读《构建之法》这本书学会独立思考问题> |
| 姓名-学号 | <朱宇柔-2019339930003> |
问题一：
-
如何避免“分析麻痹”？
分析麻痹：一种极端情况是想弄清楚所有细节、所有依赖关系以后再动手，心理上过于悲观，不想修复问题，出了问题都赖在相关问题上。分析太多，脚都麻了，没法起步前进，故得名“分析麻痹”（Analysis Paralysis）。
大牛问，果冻，你怎么还没去打水？
木桶有一个洞，咋办啊，大牛？
修哇，果冻！
用啥来修啊，大牛？
用粗麻神把它堵上，果冻！
麻绳太长，咋办啊，大牛？
用刀砍短啊，果冻！
刀太钝，咋办啊，大牛？
......
-- 引用自《构建之法》P48
思考：这种“分析麻痹”对于软件工程师来说确实是一种糟糕的思维，不仅仅是软件工程师这个职业，对于任何一个从事技术性职业人员来说，“分析麻痹”无疑是他发展道路上的一个障碍。然而，在这本书中没有说明如何去避免“分析麻痹”这种现象，或者对于已经有“分析麻痹”习惯的人如何才能渐渐改掉“分析麻痹”这种思维惯性。由于本人对“分析麻痹”有着深刻的体会，因此，我认为，“分析麻痹”竟然是一种很正常的现象，经常存在这样的现象，当发现自己需要填补一个问题时会出现一系列的连锁问题，最终可能迷失其中，发现自己还是太菜了，要把这些坑都填上了再来补那个大坑，这样导致的结果就是事情总是不拿按照预想的时间安排展开。总的来说，“分析麻痹”确实是一个很不好的习惯，那么如何才能避免“分析麻痹”呢？
问题二：
-
什么是一个优秀的软件开发团队？
什么是好的软件？一些同学认为，所谓好软件，就是软件没有缺陷（Bug），所谓软件工程，就是把软件中的Bug都消灭掉的过程。这的确是抓住了软件工程的一个重要因素。和软件打交道的专业人士都知道软件有“Bug”，软件团队的很多人都整体和Bug打交道，Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。
-- 引用自《构建之法》P15
思考：看到这个地方，我不禁在脑海中想到我们现在使用的大多数软件，如微信、腾讯视频等，都在很正常的运行，是不是这些软件自从开发运营以来就再没有出现过Bug，可以说是完美的软件，那么是不是一个软件团队只有做到开发出十全十美的软件才能够证实一个团队的能力呢？后来，我又在网上查到，2019年1月20日，黑灰产团伙通过一个拼多多过期的优惠券漏洞盗取数千万元平台优惠券，进行不正当牟利，针对此行为，平台在第一时间修复漏洞。我这才认识到，一个优秀的软件开发团队并不是会设计出一款十全十美的软件，因为世界上90%的软件工程师都会发现他们是在如复一日的修复Bug中度过的，一个优秀的软件开发团队是拥有能够迅速修复Bug的能力的，软件中的Bug也许会隐藏很久或者软件也会遭到不良人士的入侵，但是如果软件开发团队能够在第一时间修复Bug，那么这样的团队才算是优秀的。
问题三：
-
到底要不要一个代码复审者的存在？
问：这么说如果开发者做到完美,复审者的时间和精力就是一种浪费了？
答：不对,即使是完美，代码复审也还有“教育”和“传播知识”的作用。更重要要的是不管多么厉害的开发者都会或多或少地犯一些错误，有欠考虑的地方，如果有问题的代码已嵌入到产品代码中，要把所有的问题找出来就更困难了。大家学习软件工程都知道，越是项目后期发现的问题，修复的代价越大。代码复审正是要在早期发现并修复这些问题。
另外，在代码复审中的提问与回应能帮助团队成员互相了解，就像练武之人互相观摩点评一样。团队中有新成员加入时,代码复审能非常有效地帮助新成员了解团队的开发策略、编程风格及工作流程。
-- 引用自《构建之法》P74
团队复审是指对于两人的团队就某一程序实体进行的复审，团队复审的缺点在于：
1）什么时候开会做复审？不可能一个团队天天开会。要找到以诶给所有人都能出席的时间，并不容易；
2）牵涉的人员众多，理解程度不一，复审的速度和效果不能得到有效的平衡————太快则有人不懂，太慢则浪费许多人的时间；
3）正是由于成本问题，无法对所有的设计和代码进行深入的复审；
4）由于人员众多，有面子的问题。
-- 引用自《构建之法》P80
思考：在书中的P74页写到复审的必要性时，对作者的观点我是没有意见的，但是当一个主程序员写完自己的代码时，自己对整个程序的思路时清晰的，一个对此套程序思路毫无了解的人来复审程序时，会不会增加程序出错的可能性？或者由于对思路不理解，则需要主程序员对其进行说明，在者上面消耗的交流成本和时间成本未免页太大了些。在书中的额P80页又写到团队复审的弊端，确实是如此，复审的人有时候也会因为面子问题即使看不懂也假装看懂了的样子，复审者若不是程序员本身基本不会对主程序有很深入的人士和理解，与其做这样的复审还不如让主程序员自己来再一次审查。我认为作者在书中的这两处是表达了不一样的观点的，那么，在实际的软件开发团队中，是否存在一个代码复审者呢？他又是如何高效工作并找出程序漏洞的呢？