Principles of Computer System Design是一本针对计算机系统设计人员的著作。作者是MIT的Saltzer和Kaashoek。Saltzer是计算机网络中最重要的概念之一end-to-end argument的提出者，而Kaashoek也是在计算机和计算机网络中的很多重要概念上有所贡献。
计算机系统的设计在本书中被提升到了理论的角度。首次，计算机系统区别于其他系统的本质在于计算机的性能既受到了物理世界的限制，同时又可以在新产品进步时得到发展。这使得计算机系统的设计有着独特性，具体说来就是计算机系统设计的复杂度。本书的最重要目的就是将计算机系统设计中的关键技术进行抽象，抽取出本质的一些设计原则，而不是设计细节。在本书看来，最重要的降低复杂度的设计原则是模块化。实现模块化的方式有很多，这些就是本书的内容分章节的方式。以下就节选一些章节谈一下我的感想。
计算机系统的组织结构
计算机系统的组织结构一种层次化的想法。层次化的目标是使得下层的问题对上层进行透明处理。这样的原则在计算机和计算机网络的设计中被淋漓尽致地应用。在作者看来，这就是实现模块化最重要的手段之一。复杂的系统一定存在功能实现方式的选择问题。类似的工程问题可以具体问题具体分析，但在本文看来，他们的共同本质都是将具体的应用性问题放在上层进行解决，而将接近底层结构的问题放在下层进行解决。
利用通信进行模块化
利用通信的好处在于将模块之间互相影响的作用降到最低。这样可以降低错误带来的复杂度。当两个模块之间仅有的通信渠道是文本的时候就可以很好地定义每个模块之间的接口。不然的话，如果可以让一个模块直接接触另一个模块的操作，那将很难区分出错的是这个模块本身的操作还是另一个模块在这个模块上施加的操作。一种最重要例子就是因特网。在因特网中，所有机器都是只能通过数据包的文本信息就行通信。虽然因特网的安全问题广受诟病，但假设另一台机器可以对一台机器进行直接操作，那肯定会带来更多的安全问题。
利用虚拟进行模块化
虚拟的最重要贡献在于如何在当模块和模块共享同一些资源的时候进行模块化。当模块和模块用同一个资源时，就需要有一个资源管理的机制，使得模块在操作一个资源的时候不用考虑是否会影响其他模块的资源。这种虚拟化的最明显例子是计算机操作系统的进程管理机制。不同的进程就是一种使用同几个资源（内存，IO，CPU等）并且需要独立进行运行的模块。
我的研究方向就是计算机网络，而计算机网络是最重要的几个计算机系统之一，所以本书的动机让我激动不已。Saltzer在1990年的划时代论文中提出了end-to-end argument是计算机网络的基础原则之一。这个原则是为了合理分配功能的实现。在计算机网络的领域看来，end-to-end argument已经是非常本质的原理，而在本书的理解中，end-to-end只不过是众多原则中的一个特例。
by banana.totolv
一、用户使用情况报告
1、都在哪里推广了你们的产品：
我们在紫荆1#楼由电机系学生会进行了推广，使用包括海报以及学生会内部推广等等手段。但是由于电机系学生会面临期末考试，不能在期末考试附近耗费大量人力试运行这一个网站，所以该网站虽然已经正式运营，但是暂时先不进行大量的推广。
因此，为了保证电机系的学弟们能够平安地度过期末考试，我们也无法按照老师的要求在水木bbs的新软版发布自己的软件。
但我们除了自己测试以外，还联系无77等兄弟班级的同学进行外部评测，有超过50人使用后给予了反馈。
这些反馈中绝大多数中肯地赞赏网站的简洁，当然也对大量尚需要改进的细节给出了建议。
2、有多少人下载，多少人使用：
显然下载量不是我们的指标，而至于使用量，由于网站没有正式运营，也无法统计。但是我们至少邀请了多于50人进行了简单的评测。由于我们的网站本来就是电机系学生会的项目，其主旨便是服务一个系的同学。所以我们认为评测充分，而且根据用户的反馈我们预期将会有相当多的同学使用我们的网站。
3、用户反馈如何：
用户反馈有长有短。长篇大论出自某些热爱评测的人之手，绝大多数用户都只是简单地在三言两语之中描绘出他们对该网站的初步印象以及意见。
User 1:
这个网站很具有实际意义。之前很多次想买水果吃，但是一直都不想出去，毕竟有的时候呆在寝室习惯了就不想出门。后来出现了水果吧，学生会负责统计我们需要水果的数量、日期等，这个时候我就开始每周找学生会负责的同学订购。并且每周学生会同学都会准时送给我们，这个让我感觉确实方便了很多。后来听说有了一个网站让我们进行内部的使用评测，估计后来会应用到我们订购水果上，因此我很高兴能够参加这次的评测，自己使用的结果如下：
首先我打开了网站，“天天吃水果”五个大字映入眼帘，加上一副水果的图画感觉挺亲切的，然后我打开了登录注册的页面，成功完成注册后我开始正常的水果订购了。
在订购页面，我看到了许多种水果，有苹果、梨、香蕉和西瓜等，每一种水果都有相应的图片和价格，我看了一下感觉价格很合理，就西瓜而言比市场价低一些，也许具体的价格在网站正式推广的时候会做一些调整吧。订购水果只需要改变后面的数量就可以了，即可以按上面的按钮进行增减，也可以自己输入相应的数量，在输入数量后后面的价格也自动变了，挺人性化的，能让我们及时发现订购了多少钱的水果。我选了3斤苹果和2斤香蕉以后拖动网页到了下面的地址信息，然后我填了自己的姓名、地址联系电话等，另外我发现这个居然可以自己选择开始送水果和最后送水果的时间，并且可以选择在周几送，这样在我有课的时候就可以选择不让他们送，感觉这样很方便。另外我也注意到了备注信息，由于总价是10.8元，自己没有零钱，所以在备注信息里面加入了“我只有100元，麻烦带零钱找我”。填完上面的信息进入了确认的网页，确认网页上我仔细看了自己需要的水果清单，确认完毕以后生成了一个自己的List，然后我可以查看和维护这个List，比如我想删除某一个订单的时候可以很轻松进行删除，在订单的管理上自己觉得这个网站做得还是比价不错的。最后没有看到付款的地方，估计这个应该是和水果吧结合起来然后进行货到付款吧。。。
在我使用了这个网页进行水果订购以后，我发现了下面几个优点和不足的地方，首先是优点。
- 网页的界面设计很不错，图片看上去很亲切，logo很赞，同时网页的颜色和布局都挺不错的；
- 注册环节很方便，同时我自己测了一下如果我注册过一个用户名，然后注册另外一个是不能成功的，看上去这点做的不错，注册也比较快，不会浪费太多的时间；
- 订购水果的时候很方便，上面基本囊括了平时所需要的所有水果种类，订购的时候感觉数量修改很方便，比较人性化；
- 选择送水果的日期和星期这个创意很好，这样我就可以在自己想取水果的时候让他们送了，这个和紫荆公寓送水的人对比起来好很多啊；
- 在管理自己的订单上比较不错，我可以很方便地删除订单，这样就可以避免自己填错以后不知道怎么办了；
- 网页容错性不错，自己小测了一下还没有发现有什么很大的问题。
下面是使用过程中决定可以改进的地方：
- 水果种类太固定了，如果还是用这样的设计方式，水果种类一旦变多那么网页就会显得很累赘；
- 选择送水果日期的时候，最好还能选择时间，比如我下午有课就不想下午送过来，这样应该好一点吧；
- 这个网站仅仅是做校内水果的销售，如果能推广到更多的销售就好了，比如一些事物啊或者其他什么日常需要的东西，有时候太懒而不想自己去买这类的，希望能扩展这个网站的范畴，不仅仅局限在卖水果上。
- 网站几乎全是英文的页面，个人感觉希望能改成中文版的吧。。。
User 2:
网页界面清晰明朗，有亲和力。对我们这样第一次上“水果吧”的人还是有一定吸引力的。对我们用户来说，网购的第一感觉往往很关键。
网站的水果种类很全，基本上囊括了时鲜的水果，据此选择和下订单也很方便。由于平时很少碰到以水果为主题的网购站点，“水果吧”给人印象不错，有眼前一亮的感觉。
建议：由于是第一次接触水果网购，我们最担心的还是水果的质量（是否新鲜）问题，而在“水果”吧上我们得不到更多的信息，希望水果信息能够更加透明（可以实时上传些水果的拍摄图片）。
User 3:
在上个月问卷调查的时候我就知道了有这个“水果吧”，今天来逛了一圈，谈谈自己的几点想法：
1) 面建议更丰富些，只是校内平台的话，内容还差强人意，如果要对外作推广，还需要更吸引人的网站内容。
2) 然的使用界面很适合我们这些宅男（O(∩_∩)O……），这点很喜欢。另外问一下是不是只有长期定制的方式呢？我希望能够尝试定制，有时还需要改变水果类型，这样可以吗？
网站上看不到你们开发团队的信息，希望能对你们的开发过程和成员有更多的了解。
User 4:
用了一下，流程简单，异常方便，赞！只是网站为什么一会儿中文，一会儿英文。
User 5:
用这个网站貌似的确可以天天吃水果，但是每天每种水果至少订一斤……有木有一个一个买的功能啊！有木有啊！
User 6:
方便是方便，就是粗糙了一点。至少也得给我们看一下每个水果的详细图片吧。那么小一个图片咋看得出这个水果好不好吃喃……
User 7:
一个页面就搞定所有的功能！太快捷了！
User 8:
这个网站要说订购水果本身这个任务还是能够完成的，也还算精简方便，就是外观配色上差了一点。而且水果就那么几种，感觉太单调了。如果能够提供更多的选择的话我还是会考虑长期用这个网站的。
User 9:
注册了一个账户，下了几个订单，过程还算流畅。只是看不到更多水果的照片以及水果的详情，感觉不是很放心，害怕网上的和实际的差距较大。另外修改订单太不方便，必须先把前一个删除，重新下订单。这一点有点不可理喻。
User 10:
用了一下网站，大体不错，细节待斟酌。感觉的确是一门课程作业的质量：）
User 11:
操作挺快捷的，下了几个订单，发现不能够对订单中的水果的状态进行跟踪，也不能看到它人对水果的评价，无法判断商品的质量。以后一定要加上这些功能啊！
User 12:
该网站出人意料地把购买水果的所有流程整合在了一个页面上，一目了然不需要跳转便可以完成购买水果的整个流程。注册、登录、购买、查询的设计都遵循着最简化的原则，使得整个网站的所有操作都意想不到地简单明了。虽然网站已见雏形，细节还非常值得推敲。
User 13:
下单是没有问题，只是很好奇要是送到我寝室的时候寝室没人怎么办？
4、用户使用情况和原来的估计有什么异同? 为什么?
我们认为用户可能会更多地抱怨网站的购物体验，但是意想不到的是用户对于网站购物体验基本满意，但是最为担心的是所购买水果的味道质量的保证以及水果送货等物流问题，这告诉我们网站本身的技术不是最大的难关，把这个水果网站运营好，重要的是建立起强大的货物渠道以及物流资源。
二、beta 阶段的postmortem 报告
1、每个成员在beta 阶段的实践和alpha 阶段有何改进?
Team Member 1:
1、 （时间安排）在alpha的团队中，不够积极主动抢着做简单的任务，而复杂的任务（苹果UI以及pdf详细解析）由于时间安排（那个时候还有pair project和individual project）多次没能在PM预期的时间中完成，最后充满挫败感，心灰意冷之际放弃Alpha项目。而在beta的团队中，我吸取教训，合理安排时间，提前认真学习简单的html，css，java script，diango以及dreamweaver，同时与PM及时沟通，汇报进度，最后在UI上能够为团队做出实实在在的贡献。
2、 （沟通交流）在alpha团队中，没能及时向PM反馈自己的意见，没能主动适应alpha团队中的氛围。在一个自己不喜欢的氛围里，我没有选择真诚地交流，而是选择了躲避，这也是alpha失败的原因之一。而Beta中，我尽量勇敢地说出自己心中的意见，在团队沟通上取得了良好的效果。
3、 （任务合理）在alpha团队中，自己总是在做一些自己觉得不靠谱的任务，而靠谱的任务自己又没有争取到，导致的结果就是自己在不能完成复杂任务的失落感与挫败感中挣扎不前。而在beta团队中，有一些超出自己能力范围又没有时间学习的任务，我和PM沟通之后选择了放弃，而集中精力快速完成了一些我能够简单上手但是又不那么trivial的任务，最后为团队做出了更大的贡献。
Team Member 2:
1、Beta版时对技术的掌握程度比alpha版时更加好，不像alpha版时的一头雾水。
2、Beta版时对自己的具体分工也更加地清楚。
3、UI部分使界面变的更漂亮。
4、除了开始的网页，还增加了其他的几个网页，使网站更加完善。
Team Member 3:
alpha阶段我参与了django前段的设计。在重新分配belta阶段的工作后，我负责渠道和外围调查的，工作包括照澜院、超市和水果摊的市价和销量调查，询问进货渠道，以及对（潜在）用户的网络问卷调查。而这方面的工作一直是有延续性的和时效性的，可以说从belta阶段开始后开始就一直在进行。
这方面的工作是简单而繁杂的，主要分三个方向，一是每周去照澜院、超市和水果摊，并询问摊主每种水果的销量和市价，以方面我们对此作出反应；二是和经管学院联系进货渠道，这方面我主要负责一部分联络工作；三是和一些认识或不认识的朋友进行一些简单的问卷调查，以总结用户的喜好和建议。工作难度不大，但颇有些工作量。
2、每个成员在beta 阶段的实践和alpha 阶段有何改进?
1、 放弃deadline driven的方式，而是合理安排好时间，提前动手。
2、 人员分工更加明确，通过切割网站的方式使得工作原子化，每个人都可以认真工作。而不像alpha的时候大量工作堆积在少数人手中使得工作安排较为模糊。
3、 沟通方式更加注重朴实刚健的语音以及当面交流，淡化了email等貌似现代的通讯手段在team communication中的作用。
4、对整个网站的设计情况要有清晰的了解，与底层要有充分的沟通，不要写出不符合整个工程的无用的代码。
3、12条敏捷开发原则中，团队做得最好和最不好的各列举两点
团队做得最好的两点：
6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
10: Simplicity--the art of maximizing the amount of work not done--is essential.
做得最不好的两点：
3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale
4: Business people and developers must work together daily throughout the project.
4、对照 The Cathedral and the Bazaar (大教堂和集市), 你的团队开发模式是哪一种, 优势/劣势在哪里?
我们的团队是cathedral模式，因为我们必须要从无到有搭起一个全新的网站，而Bazaar模式要去的成功的必要条件是至少要以一个可以运行的原程序作为起点在其基础上大家一起加工。
另外我们的工作模式是在每个人通过自己的终端通过putty连接到服务器进行工作，所以如果所有人都任意地修改同一份代码，网站本身难以成形，而且会出现访问权限的问题，这也是我们选择cathedral模式的另一个原因——每个人都在完成自己部分的部分工作之后交给特定两个同学进行修改。
优点显而易见，能够保证每时每刻总有一个成形的网站可以运行，而且不会突然被污染导致网站崩溃。
但缺点是每个人不能完全地领会整个网站的代码框架，所以在完成自己的一部分工作之后，整合到整个网站的工作会变得非常繁琐而且没有效率。
三、beta测试报告：
在beta 阶段的实践和alpha 阶段有何改进
bata版的测试基本沿用了alpha版本的目标，有一定的改进。改进的主要方面在测试手段和流程上，有了很大程度的提高。beta版的测试报告详见
http://www.cnblogs.com/banana-totolv/archive/2011/05/30/2062612.html
1. 测试目标
本项目的测试目标主要是网站GUI的正确性，我们需要用各种各样变化的输入来对页面的反馈进行监测。比如，登陆界面的测试主要集中在登录正确性以及注册的正确性，又比如，水果选购的页面的测试主要集中在订单确认的正确性。
组内的测试工作虽然由少数同学完成，但测试的目标都经过了PM和主要成员的认可，所以测试目标具有一定的针对性。
alpha版测试与beta版在目标上的区别是更加强调了GUI正确性。在alpha版中，我开始希望用test-driven的方式进行开发，但遇到很大的困难。一方面，自己不是作为主要开发人员，对django的代码并不熟练，无法写出很高效的测试程序，可能反而会增加其他人的负担。另一方面，在alpha的开发过程中，很多功能虽然一开始确定，但后来又经过了多次修正，所以没有办法得到一个完整的spec。起先我想自己写一个spec，但组员觉得固定的spec可能无法对实现难度有所把握，对于我们这些初级开发人员要求太高。比如，开始我觉得登录密码过于简单这个问题可以在alpha开发时作为一个spec，但其实这个问题到了beta版的时候才得以解决，原因如下。alpha版开发的最大难点之一是登录/注册程序，只有董沛同学对django这一块的内容比较熟悉，但这项任务开始时是由吕曰洲同学接手的，所以花了很长时间也没有完全解决，这个问题就一直拖了下去。
beta版较alpha版更强调GUI的另外一点主要原因是对于开发过程的更深入理解。一开始，我希望将课上所学的模块化测试应用到我们组的测试工作中，但在网站开发几个月之后，我发现我们网站程序很难产生明确的模块接口。比如，我们开始计划将网站的数据库，页面，以及逻辑完全分开，这也是django架构所支持的，但后来发现虽然这三者可以分开，但无法得到详细的接口。一方面，模块之间都是使用不同的语言，比如页面用的js，而逻辑用的python。另一方面，django虽然自带有模块之间的功能测试，但这样的测试需要各个模块的程序满足一定的需求，而这些需求很多是对于各个组员的额外要求，在时间不允许的情况下，我选择放弃这样的测试方法。
在beta版中，测试主要集中在了GUI正确性的优势有三点：首先我意识到我们网站的页面有着一贯清晰的接口，比如，水果的订单数量一贯是一个变量名。虽然这些变量的后台实现经常会发生变化，但由于变量不会变，所以自然而然地有了清晰的测试接口。这样一来，我不用约束同组同学遵守一定的spec，也可以保持我的测试程序不变，而且即使变量名发生了一定变化，我也可以很快修改测试程序。其次，GUI正确性有专业化的工具可以使用，比如HttpUnit，这样我也可以进行自动化测试（详见第二节）。最后，GUI是我们网站对于用户的唯一界面，也是管理员操作数据库的唯一接口，所以它的正确性非常重要。所以强调GUI的正确性符合我们网站的实际需求。
综上，测试目标在alpha版和beta版中虽然主要目标相同，更强调了GUI的测试，而弱化了test-driven的比例。
2. 自动化测试
自动化测试的最重要动机是希望能测试网站的流量承受能力，这一点是alpha中所不能做到的。虽然这一项测试最后没有得到什么结果，但自动化测试带来的好处却帮助了GUI测试取得了成功。
流量承受能力测试是为了防止发生DoS攻击，从网络安全的角度看，这时网站最重要的问题之一。在alpha版本的测试中，我主要进行了网站在各个用户环境下的使用情况。其方法是用各种浏览器，在各个操作系统和各个浏览器设置下进行测试。这种手动的测试方法显然无法满足流量攻击测试的要求。为此，我找了一些自动化的软件进行尝试，但将同时访问人数设到10000还是没有发生问题。后来在请教PM的时候，他说django框架可能已经防止了这些情况。因为django是一款通用的网站编写程序，所以肯定考虑了诸如防止DoS这样的通用需求。
虽然DoS的问题不需要测试，但我却发现了自动化测试的很重要好处之一：可以批量进行测试，并保存测试过程。
批量测试的重要性在于可以对某一功能的各个情况在很短时间内逐一进行验证。在测试中，我使用的HttpUnit，HttpUnit这是一个基于java的类包，可以模拟几乎所有浏览器的行为。同时HttpUnit的测试用的是java代码，所以可以用循环的方式对操作中的参数进行调整。比如，在以下代码中，用户名的参数用的循环生成，而密码则用的是随机数生成，这样可以批量十次测试登录这一功能在不同输入下的反应。而同样的测试如果人工进行需要手动输入10次，非常耗时。
for (int i = 0; i < 10; i++){
String username = i + "testnewcomer";
form.setParameter("username", username);
form.setParameter("email", username + "@gmail.com");
Random r = new Random();
String password = String.valueOf(r.nextInt(10000000)); //随机生成一个1-6位的数字密码
form.setParameter("password1", password);
form.setParameter("password2", password);
requestLogin = form.getRequest();
responseLogin = browser.getResponse(requestLogin);
System.out.println(responseLogin.getText());
}
保存测试结果的好处在于，如果测试的结果进行了一定改进可以立刻进行测试。这一点在有效密码测试中得到了一定的印证。首先，用测试程序发现某一接口有问题，其次，针对这个问题找出错误的根源，进行修正后，用同样的测试程序进行测试（见第4节）。
3. 生成测试样例
在上一部分中，我介绍了beta版测试最重要的自动化测试。我希望自动化测试可以找到GUI中的问题。这一步的关键是如何生成测试的样例。这也是beta版相对于alpha版的最重要改进之一。在alpha版中，有一个test matrix的测试计划，这其中包括各个变量和参数的可能取值，这些取值之间是分别独立的，所以需要测试的次数就是所有可能性的乘积。但在自动测试中，这样的目标显得太弱，很快就能实现，更好的目标应该是利用自动测试批量的特点生成尽量有代表性的参数和变量取值，用程序检查得到的结果。
拿水果选购功能测试为例。每种水果的选购数量和选购日期的取值都可以任意，这其中会发生的问题需要通过程序随机地选择可能的值进行组合验证。
for (int i = 1; i <= 10; i++){
numberList[i] = r.nextInt(5); //对每种水果，随机选购一定数量
form.setParameter("number" + i,
String.valueOf(numberList[i]));
price += uprice[i-1]*numberList[i]; //实际价格
System.out.println("number" + i + " is " + numberList[i]);
}
requestBuylist = form.getRequest();
responseBuylist = browser.getResponse(requestBuylist);
String totalPrice = responseBuylist.getTextBlocks()[11].getText();
String[] contents = totalPrice.split(" ");
double responsePrice = Double.valueOf(contents[contents.length-1]); //网站反馈价格
System.out.println("实际价格"+price+"，反馈价格"+responsePrice);
if (Math.abs(responsePrice-price) < 1){ //允许正负一元之间的误差
System.out.println("Pass!!");
passCount++;
}
4. 改进方案
针对测试结果进行改进也是beta版相对于alpha版的一个重要提高。alpha版本由于时间过于紧张，错过了进行改进的时间。在beta版中，测试的结果得以部分地被改进采纳。比如，过于简单的密码问题在5.29号的日志中已经被纠正。当用同样的测试程序（见第二节最后的程序）进行测试的时候，结果返回就是希望的结果。
改进方案的提出可以是由测试人员给出，也可以是开发人员自行给出。在我们网站的django架构下，最好的方式是由开发人员自行解决。因为代码并不分开，所以需要进行改进的部分可能同时在进行其他功能的开发。其实这也是我们组经常出现的问题，代码文件并不多，但是有很多人需要进行修改。所以这个时候测试人员如果直接提出代码修改的方法甚至自行修改，将会对其他开发人员的工作造成不必要的影响。
读书报告
——《windows编程启示录》
计70 龚逸 2007013214
这学期的软工课上，我向邹欣老师借了《windows编程启示录》一书，英文名是《The Old New Thing》。这本书不仅仅介绍了windows的一些知识和如何在windows下开发软件，更是告诉了读者为什么windows会是现在这样的，也就是这个操作系统发展的轨迹。作者通过介绍windows发展的历史，给予读者软件工程方面的启示，因为windows操作系统恐怕是20年来最为重要，用户人数也是最多的软件吧。书中讲述的历史对于正在上软件工程课程的我受益匪浅，下面是我对全书的回顾和自己受到的一些启示：
用户界面
为了提高用户体验，这么多年来，用户界面始终是windows非常注重的一个问题。用户界面从一开始的设计到后来发生了非常大的变化。
例如我们大家熟知的windows左下角的开始菜单，一开始并不叫“开始”，而是比较自然地叫做系统，而且左下角也不是只有一个菜单，而是有三个，另外的两个是搜索和帮助。最后windows把这三个按钮合到了一起，保留了其中比较重要的一些部分。此时，就有人想到了应该将“系统”按钮上的文字改为“开始”。这样，这个按钮就好像是在说：“嗨，请按这里。”在进行了这个简单的修改之后，从测试结果中可以看到系统的可用性得到了极大的改善，因为现在当测试人员想要做一些事情时，他们就知道该去点击什么地方了。最后“开始”菜单中放了所有重要的功能，甚至把关闭计算机也一起放到了“开始”中。
书中类似此类的例子还有很多很多，总之，不断地提高用户体验是一个漫长而又艰巨的过程，自己在alpha、beta时感受也非常深。
安全
作为一个操作系统，它的安全是非常非常的重要的。文中列举了一些windows曾经出现过的漏洞，主要是多个用户之间如何共享数据以及隐藏文件方面的问题，还有就是最核心的窃取密码的问题。Windows中的调试代码也能成为被攻击的漏洞，倒是令我万万没有想到。
看了这些内容后，我也开始思考我们网站是否安全。
兼容
软件开发中还有一个很重要的问题，就是兼容的问题，这个问题也使windows大伤脑筋。书中出现了许多兼容时出现的问题以及解决方法的例子，这里列举一个：
许多人都在呼吁抛弃16位DOS和16位windows的兼容性子系统。但是windows却没有这么做，原因是这样的，安装和开发团队的成员们曾经到世界各地去访问一些公司，了解这些公司在各自的业务中是如何使用windows的，然后他们发现在这些公司中存在着一个相同的问题，这问题是与这些兼容性子系统是相关的，这些公司仍然非常依赖它们。
每个公司都有自己的业务流水线（LOB，line-of-business）应用程序。这些程序用来处理公司每天的业务，如果没有LOB程序，那么这些公司将无法运作。例如，在微软公司中，两个关键的LOB程序就是错误跟踪（defect tracking）系统和构建系统。
正如微软的错误跟踪系统和构建系统一样，在一个大公司里面，大多数的LOB程序并不是商业软件，而是由公司内部根据公司的业务流程和工作方式开发的软件并且被视为是商业机密。例如，在金融服务类公司，趋势分析软件和趋势预测软件就是这家公司的核心竞争力之一。
LOB应用程序是非常关键的。如果windows的升级会破坏某个LOB应用程序，那么所有的工作都将无法继续。因此这家公司将不会升级windows，因为没有任何公司会希望去失去一个对他们的业务至关重要的程序。最关键的是这些LOB程序中有许多都是16位程序。
“税收”
“税收”问题的性质是你需要实现某个功能，但这功能并不是为你的模块带来好处，而是给软件的整体带来好处，如何使你主动认真地去实现它呢。
我们的team工作时也会遇到这种的问题。
书中介绍了很多的“税收问题”，以及它们的解决办法，其中的一个问题是电源管理，这个问题是之前我所没有想到的，原来用户在考虑一个软件时还会注意它的耗电量，而且软件与软件之间的耗电量差距还会有这么大。
一些启示
书中的最后一章是“一些可笑的故事”，记录了很多windows开发的过程中遇到的可笑的故事，有些故事给了我一些启示。一个小小的问题，一个小小的修改都可能会使软件出现一些可笑的问题。
总体来说，由于自己正在进行软件工程，了解世上最大的软件工程——windows的开发过程和其中遇到的问题，对我自己的工作，有着很大的帮助。
Book Report: THE SOUL OF A NEW MACHINE
Zhengdong Zhang
What’s a good
man in a storm like? The prologue of the book draws a astonishing picture. The
ship is winding in the billows, and the storm is howling. Almost all the
travelers get thrown out by the rolling ship, and their mood is terribly in
doom. But Tom West is an exception. In contradiction to his colleagues, he takes
beer however hard the ship is rolling with a grin in the face that never twists.
He do not sleep for four nights. Everybody else, including an psychologist, gets
quite curious about when he will crash after staying up for four whole nights, but
to their surprise, West just snapped, compared with his own job, these four
nights are just easy days in a vacation.
As it turns out,
that unbelievable harsh guy is an engineer building computers. For him, fighting
with storm on a solo ship in the endless sea without any sleep for four nights
is just fun. Then after all how harsh would his job, making computers, be? Actually
it takes the author a whole book to answer that question roughly.
The competition
between the companies are always fierce, which makes every competitors in the
market nervous all the day. In 1980’s, DEC published the ever first 32-bit
computer and temporarily beats the opponents. IBM and Data General thus get
quite anxious about building a faster computer. For the two followers, the goal
was clear, the deadline was set tight , but the task was so challenging that
nobody in the company knew clearly how this faster 32-bit computer would look
like. The pressure for competition itself already made the life of building
computers harsh.
But competition
did not happen just externally, the fight between different teams within the same
company is also fierce. In Data General, West’s project, EGO, was canceled in
the middle because the annoying political issues. Without any doubt, this
internal competition would significantly reduce the resource each team could
apply, and simultaneously some resource would be allocated to multiple teams
for the same purpose, which was an unnecessary waste. Moreover, these political
issues hurt a lot the enthusiasm of engineers. That made the task of building a
computer even tougher.
In addition, the
typical characteristics of engineers increased the difficulty of managing a
team composed of such geeks. In general, these people were majorly egotist and
did not care much about other people. In a sense, they were simple and they
would talk whatever they wanted to and did not care the feeling of other people.
Dealing with these geeks was no easy task and that resulted in tense peer
pressure.
But even if all parts
of the working environment were nice and comfortable, the task of building
computer itself was so challenging that programmers must sign up for the job.
Perhaps there were always periods in which the programmers work day and night
without talking to anybody and just focused on one specific problem. That
problem might be the micro-code for the ALU that required the programmer to
completely think like a machine, also it might be a bug that came out of nowhere
without any rhyme or rhythm(say the miss of a nand gate somewhere, or just the
chips being dirty). These bugs were extremely difficult to trace. The
programmers had to leave all they usually appreciated behind work: parents,
family, children, hobbies or whatever was important to them other than the
work. Arguably if you signed up too many times, you would lose everything. And
also these work largely harm the health. These partially explained why the engineers
were usually young and old ones were pretty rare.
Then why on
earth talented engineers would devote all their life to such harsh jobs? Why
would they give up their comfortable daily life and program all day and all
night? Various engineers mentioned in the book raised the same answer
consistently.
Freedom comes
first. Only in data general they were given mental freedom to create and design
their own product and there was no need for them to work hard on the trivial
and boring routine tasks. Not like IBM where all the employees were well
dressed in suits, engineers in Data General just wear casual T-shirts and
jeans. They virtually felt they were not hired by the company, but by
themselves. They had a wonderful feeling that they were their own boss. Even
though that was just a feeling, not reality.
Self-satisfaction
also made the boring life before computers interesting. The programmers thought
they were not work on a product of a company, they were creating something out
of nothing----New ways of writing microcode for the new ALU, new instruction
set, new software and finally a new machine that nobody ever knew. In the
process of building, they may get stuck somewhere. But once they overcome that
through hard work and creativity, they would enjoy an overwhelming feeling of
success and self-satisfaction. For them, that happiness, though just existing
in an instant, supported them to go through all the unknown problems and guided
them to the final goal step by step.
So after all,
what’s the soul of a new machine? The book told answer implicitly in a series
of stories of different engineers: Tom West’s management of the whole team and
fight with the boss, Carl Alsing and his microkids, Wallach and many hardboys,
and so on. These characters gave a clear plot of what made them tolerate so
much pain and insist working. The soul of a new machine, is the soul of engineers
that build the machine, is the harshness of the job and the brave hearts that finishes these jobs, is a
mix of all unknown possibilities and a hard process of searching and selecting
among these possibilities.
But what
impressed me mostly was the end of the story. After Tom West managed to build
EAGLE and persuade the boss the make EAGLE into product, his boss just kept
talking about the coolness of the machine without even mentioning West and his
team. In the beginning, EAGLE was almost canceled because of the political
issues. But the bosses in the end seemed completely forget the bad things they
had done to the machine and just blew up in front of the media. There was a journalist
that interview Tom West, the father of the machine. But she just asked whether
this person had anything to do with the machine.
Not long time
later, the whole EAGLE team broke up. Tom West left the company and many of the
team members switch to other parts of the company. When the new machine was
out, there was already no glue that could put the team together. Each team
member fight with each other on how many contribution each made to the new
machine. This was really sad. Only the project would put all these egotists
together, and finish of the project was the death of the team agglomeration. The
break up of the beam was naturally the consequence.
