from http://kb.cnblogs.com/page/522043/
2015.05
英文原文:How a course in operating systems changed me
在普林斯顿大学有很多课程改变了我,就像COS 318(操作系统课程)。它极有挑战,耗时耗力,但是当我学完后回头想想,我很庆幸我选了这门课。
我当初选择这门课程的时候很犹豫,因为周围的人都这么说:
这门课毫无疑问非常难,但是不妨暂时放下你之前听到的对它的偏见。不学它并不会毁掉你软件工程师的生涯,但是如果你真的学过了它,你将会在很多方面获得启发。我选择操作系统课程之前其实十分讨厌系统底层编程,也很害怕参加这门课程。但是现在来看,我觉得选择它是我做过最正确的决定之一。下面是我认为这门课程对我作为学生,作为软件工程师和作为问题解决者所带来的启发:
我的经验和启发都是基于普林斯顿2013年秋季的COS 318课程来说的,但是这对其他本科操作系统课程也都适用。
毫无疑问,在写一个操作系统的时候,我们需要非常非常多的调试。如果你觉得你在算法课上的调试已经够难了,那你可以想想如果两次调试会产生完全不同的结果该是多么令你抓狂。
当你写的操作系统慢慢变得异常复杂了之后,你就不得不去寻找顺手的调试(debug)工具和一套科学合理的调试方法了。
在参加这门课之前,我觉得调试就是随手做一做的事情,根本不是写程序的一个正规环节。以往我调试的方法都是把所有我认为可能出错的地方都修改一遍看看,这是一种毫无技巧可言并且让人感到无聊的过程,我通常称之为“橡胶鸡调试法”(rubber chicken debugging)。在操作系统课程结束之后,调试从一门艺术变成了一门科学。我开始意识到原来存在一种科学省时的方法能够迅速精确地定位错误(bug),并决定应该采用什么样的修复方案。
这种调试方法在其他的课程或者经历中也十分有用。比如,我在Facebook做实习生的时候,我十分接受“亲力亲为”这样的代码工程理念。如果有些部分除了问题,那么就要立刻开始标记记录日志,然后一直记录查看,直到一个地方记录的结果和你所期望的结果出现了不同(这就是错误出现的地方)。这种思维方式只有那种高强度的编程课程,类似操作系统课程,才能给你的。
操作系统课程突然让我意识到了代码的性能问题。如果这个程序运行很慢,我就会停下来想一下:到底是什么是制约性能的关键因素?CPU?内存?硬盘I/O?理解了这些基础的东西让我在高层次编程的时候让代码更快,更简练。
人们通常都认为操作系统课程只有在底层编程的情况下才会有用。但是事实上并不是这样,只有用C和汇编写过操作系统代码的人才能够更好地驾驭高级语言。
我们的操作系统课程有一些协作完成的项目,两个同学一组。我十分幸运在协作项目中和我两个好朋友一起工作。这种一起面对困难的经历让我们成为更好的朋友,也让整个班级同学的联系更加紧密。
由于有这些协作项目,我们变得更加善于合作。团队工作很容易陷入这么一种模式:一个人编写代码,另外一个坐在旁边看写代码。在操作系统课程上,我们的做法更加高效:两个人分别负责不同模块的实现,然后互相检查对方的代码。团队合作同时也增强了我们版本控制的能力,这是一个好的实际应用Git的机会。
这是一个年轻程序员面临的最显著也是最难解决的问题:当我们遇到问题的时候,常常陷于费曼算法(Feynman Algorithm)
采用这个方法让我操作系统前一部分的项目苦不堪言。这门课让我不得不去找一个科学的解决问题的方案。我最后想到了一种通用的做编程项目的方案,而且我把这个方法也用到了其他的计算机课程上了。它包括三个步骤:
① 任务:在这个项目中我需要完成哪些目标?我非常看重任务驱动,所以在安排我工作的时候,我会做一份清单,上面有一些划分成小块的任务目标。拿烘焙蛋糕打个比方:
② 代码错误(Bugs):有哪些代码中的错误是已知的?在这个步骤中,我会跟踪代码错误和一些我尝试修复的东西。在早期的项目里,我把时间都浪费到了重复尝试可能的解决方案上和频繁遇到一样的代码错误上了。频繁追踪产生的代码错误和修复方案能够在接下来的项目中节约我很大一部分时间。
③ 问题:我有什么问题?在这部分,只要我遇到了问题,我都会把它们大致记下来。当我翻阅文档或者询问同学获得答案之后,我就会把我学到的知识记录在这。
有这么一个表格让我对我所做的项目抱有很大的信心。如果没有它,我可能现在还在花大量的时间在实验室里,虽然也可能有进步,但绝对没有我现在进步得这么明显。
操作系统课程确实是一门有挑战性的课程,但是还是建议能够参加这门课。它是我成为软件工程师路上提高最大的一门课。如果即使你学完之后甚至都不记得什么是虚拟层(hypervisor )了,你也会感谢它教会你的其他东西。
一些关于操作系统课程的其他观点评论:
联系客服