个人博客作业 1:就《现代软件工程》提 5 个问题
问题一:如何权衡分析麻痹问题
出处:
第三章《软件工程师的成长》中提到:“想弄清楚所有细节,所有依赖关系之后再动手,分析太多,腿都麻了,没法起步前进,故得名分析麻痹。”书中还举了个修木桶的例子。
初步问题:
关于书中的例子,我在上大学后就遇到了类似的问题。比如,为了打比赛或者做科研,经常遇到一个新的知识需要学习,这时就会发现,有许多前置知识,我将其命名为递归学习,当层数过多,就会让人有放弃的想法。
另外,在一个人的代码上加入新功能时,到底要先看到什么层级呢?是先把主函数的上层代码本身看明白(比如逐行输出来探究其功能),还是要一口气看到较低层(这里的底层指的是调库相关的代码就不需要进入去看了)?如果一口气看到最底层,投入太大且容易放弃;如果只看main函数的表面,可能会弄出相当大的问题。
查阅资料:
网上只查到了现象的分析和举例,并没有查到如何解决分析麻痹的资料。
个人提问:
以“在一个人的代码上加入新功能”为例,怎样做才是最好的呢?如何降低分析麻痹的影响?
问题二:结对编程的核心是什么?
出处:
第四章4.5《结对编程》部分提到了最初的结对编程是为了解决问题,不得已而为之。后面,书里又提到,结对编程可以让两人所写代码不断处于“复审”过程,也就是团队内部会复审,每段代码至少有两人思考过,降低出错率。
初步问题:
书中说最初的结对编程是为了解决问题,不得已而为之。我也认同这一点:结对编程是因为遇到了单人在有限时间内难以完成的开发任务时使用的方法。也就是说,结对编程的最大特点是多人针对一个任务去并行工作,这样可以更快完成目标任务。
可是,书后面又强调复审,我则产生了怀疑,既然结对是为了更快开发,复审算不算结对编程的核心?单人编程就没有复审环节,那结对编程的复审的性价比如何呢?
查阅资料:
结对编程中,两名程序员共同审查和编写代码,可以更快地发现错误和缺陷,从而提高代码质量。
个人提问:
资料上说了复审可以更快地发现错误和缺陷。我理解这个功能。但是,自己写的代码还是自己最了解,为什么不是本人复审?因为结对编程人数不算多,应该不会有生态损坏的问题。毕竟我认为速度快才是结对编程的核心。
问题三:创新和专家的关系?
出处:第6章《IT 行业的创新》中提到:“统计数据表明,70%的创新者说,他们最成功的创新,是在他们的拿手领域之外发现的。”书中举了很多例子,一个最简单的就是物理学家提出HyperText,导致WWW的诞生。
初步问题:
我认为,重大创新,也就是最成功的创新,往往是从0到1的,比如,神经网络的发明者获得了诺贝尔奖,这项发明要比后续的圈内重大创新(比如CNN,残差连接,RNN等)还要伟大一些。对于从0到1,有时候不一定需要非常专业的知识,尤其是某一个学科刚刚起步的时候。但对于从1到更多,则需要更多的知识了。
为什么70%的创新者说,他们最成功的创新,是在他们的拿手领域之外发现的呢?我认为,一些不需要很多专业知识的从0到1的创新是不挑发明者的专业的。
所以,从0到1的创新很可能是专业外的人发现的。考虑到专业数量以及研究方向数量极其庞大,如果发现者的领域完全随机,70%这个数字其实还是低了,应该是99.9%,所以,70%恰恰说明,专家也是从0到1的创新的一个重要条件。
个人提问:
In conclusion,成为专家会极大促进在这个领域的创新能力,是否正确?
问题四:成功的团队是否更容易创新?
出处:第6章《IT 行业的创新》中提到,颠覆性的创新会带来产品和市场的巨大风险,那些没有成功包袱的小公司反而能把颠覆性的创新带到市场。
初步问题:
“那些没有成功包袱的小公司反而能把颠覆性的创新带到市场”好像没有数据支撑。毕竟,有一种说法是“幸存者偏差”,即创新失败的小公司要么消失了,要么默默无闻。如果能调研清楚这个比例,也许会发现还是成功的大公司更擅长创新。
查阅资料:
网上很多帖子的结论是,小企业更容易创新。但并没有给出我在“初步问题”中希望得到的数据,只得到了基于自然语言的分析。
我认为,这个结论确实有待商榷。毕竟,提出“小企业更容易创新”是违反直觉的。违反直觉的结论更容易被关注,这样,人们就会倾向于提出这样的结论以提高影响力。
比如,曾有预言专家预言,非洲会出现世界强国,我认为这也是一个小trick,毕竟这样的结论是反差最大的,而随着时间的推移,这件事发生的概率又是很高的......
所以,数据才能说服我。
个人提问:
大企业更能创新,是否正确?
问题五:个人角度的讨厌创新对创新的影响是什么?如何避免?
出处:
第6章《IT 行业的创新》中提到:“不但大众不喜欢创新,甚至连创新者自己都不例外。”书中举了一个例子,一个花费毕生精力研究电报的创新者,会因为顾及自身利益而可能讨厌电话的发明者。
初步问题:
这个例子其实和我的心理预期不符。我认为,人们讨厌创新除了讨厌别人创新这个因素,还有讨厌自己创新这个因素。作为一个个体,人不爱学习和接受新的事物,我认为这可能会阻碍创新。
身边例子:
我有一个同学要上台讲PPT,需要背发言稿,我告诉他可以使用演讲者模式,并告诉他好处在哪。但他不愿意学,还是背了稿子。在我们已经会演讲者模式的人眼里,他学演讲者模式。这样,他不仅这次付出的总时间是降低的,并且对未来的演讲也有作用。这个示例可以套用一个俗语:磨刀不误砍柴功。
查阅资料:
短期确定性 vs 长期收益
人不愿意学新东西,往往不是“笨”或“懒”,而是一种时间折现偏好:人类倾向于高估眼前的成本、低估未来的收益。
学习新工具意味着:短期内要花时间和精力/学了之后的收益还不确定(比如可能暂时用不上)/失败风险让人感到焦虑
相比之下,背稿虽然笨,但确定可行。于是理性上学新东西划算,心理上却不划算。这是一种“心理能量最小化策略”:大脑在潜意识中选择最省认知能量的路径。
这个行为背后涉及几个典型的认知偏差:
(1)现状偏好
维持已知方法带来心理安全感,“保持现状”本身就让人觉得舒服。
(2)损失厌恶
学新技能时,人更怕“学不会浪费时间”这类潜在损失,而非期待“学会后更高效”的收益。
(3)即时满足
背稿立刻能看到进展;而学习新模式的回报要推迟。这让前者在感受上更有“成就感”。
(4)自我效能感低
有些人对自己学习新事物的信心不足——他们不是真的懒,而是“预期失败”,所以选择回避。
其他例子:开发者不愿从SVN切换到Git
2008年之后,Git 已经在全球开发圈成为主流,但很多老项目和老程序员仍死守 SVN。
理由通常是:“SVN 就够用了”、“Git 太复杂”、“我现在的流程很稳定”。
结果:团队协作受限/新人无法顺畅加入/工程效率远低于使用现代工具的竞争团队。
这其实不是技术问题,而是学习曲线带来的心理防御机制。当每个人都这么想,技术迭代就被“熟练者的惰性”锁死了。
个人提问:
关于创新的阻碍,也许是因为侧重点不同,书中貌似没有提到这一点。我个人倾向于认为,懒于使用新工具和懒于创新有很大关系。首先,懒于使用新工具意味着潜在的效率降低,这就导致速度低于其他创新者。其次,这背后蕴含着懒于思考新的东西的本性,应该也会阻碍创新。所以,在创新活动中,这种心态是否会阻碍创新?是否是需要有意避免的?如何避免呢?