阅读笔记之No Silver Bullet
本文中，作者的观点是没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍（1986）
作者列举的原因是 代码的完成分为两部分： 抽象（建模）和 代码实现。根据我个人的理解，就是 设计和实现的过程。作者认为实现过程的速度相对来说比较好的提高，但是 设计的过程很难提高。而根据设计过程在整个项目中占的比例要大于1/10，所以得出结论没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。
我认为，作者的见解相对来说是比较合理的。实现的过程是人与机器的交流，只要有很好的规范（并且人人都严格遵守），利用一些工具或者其他方法，实现的过程效率很好提高。
而设计的过程很难提高我认为原因有如下：
是人与人和人与现实世界之间的交流，而人的思维是很难描述的。
现实世界是非常复杂的，要理清现实世界的关系非常困难。
现实世界是变化的。
这些观点造成了提高的难度。
但是，我也认为由于作者10年的期限，使这篇文章过于悲观。作者认为难题在于设计，也就是说人类的思维。我们很明显的能感觉到计算机出现的不到70年时间对人的思维的改变，因此，作者很巧妙的说了时间的期限（10年），我认为，10年或许很难在设计方面取得突破，但是人类终将找到属于软件工程的Silver Bullet。
阅读笔记之big ball of mud
大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。
我觉得，造成大泥球的主要原因是设计的问题，程序的设计者在实现代码前没有对程序的整体有一个很好的理解，造成程序的很多细节没有办法统一。程序员不知道自己的每部分代码的详细的任务，不知道某些东西应该在什么地方处理。造成程序冗余，结构混乱。
有时候，代码的初学者会遇到这种问题（好吧，我承认就是我），写完程序以后调试很久都没有完成。到最后自己完全重新的码一次代码，不但非常快，而且很快就ac了。究其原因，是因为第一次写程序没有对程序有一个深刻的理解，所以第一次的代码混乱不堪，调试工作很难进行。而第二次写代码，明确知道了程序的结构，因此写起来称心应手，错误也非常少。
记得在面向对象课程的时候，老师非常强调程序的封装性。可以说，好的封装性和没有大泥球的要求相似。都是要求每个代码段（类）都能够准确的完成既定的任务，合理的分配程序的任务。
对于这个问题的解决，我觉得设计文档是一个很好的工具。有时候我们自己觉得设计完成便开始写代码，这样没有落实到纸上，我们就很难发现一些没有考虑的细节。而设计文档能够帮助我们理清思路，更好的规划自己的程序。同时，设计文档为我们的交流提供了很好的介质。在计算机组成原理大作业的时候，我就感觉到了设计文档的重要性。有时候，看似很难的问题，用设计文档一一说明，就能明确的知道自己要干什么，要达到什么目标。对于一些看似很简单的题目，设计文档能够帮助我们看清自己的设计还有什么不完善的地方。
从团队项目来看，设计文档的重要性更加明显，设计文档是交流的工具。在第一周写软工的时候，我根本不知道自己的输入是什么，该输出什么。无从下手。有一份设计文档，这些东西就轻而易举的解决掉了。
阅读笔记之Worse is Better
在IT世界，有很多现象很奇怪。VB绝对是个垃圾的语言，但是他战胜了Delphi；IE绝对是个垃圾的浏览器，却占据了国内浏览器的鳌头；MySQL的数据库特性绝对不如PostgreSQL，但是市场占有率遥遥领先；MacOSX操作系统的优秀毋庸置疑，但是Windows是绝对的霸主。（引子某学长博客，觉得写的很好）
个人认为，worse 和 better 这两个词描述的是两个方面。Worse是相对于设计者而言的，或者说是非常专业人士而言。而better是使用者的感受。Worse is better 这个理论反映的是设计者和使用者的代沟。这个代沟的产生有很多方面：
历史原因：无论MacOSX多么优越，但是他的出现年代远于windows，人们已经习惯了windows，觉得操作系统就应该是这样子。MacOSX就很难战胜windows。人们不愿意改变已经适应的事物，是这个现象的很重要的一个原因。
用户体验原因：很多设计者认为好就是利用好的技术。但是对于使用者而言，易用性的重要性要远远大于技术的重要性。有很多软件内部代码非常好，效率很高，但就是没有“成功”，究其原因在于没有理解用户的需要，用户觉得软件缺乏亲和度。软件自然就淘汰。
Money：个人认为360是个彻彻底底的垃圾软件。但是他的易用性非常好。并且，准确找到了人们对于好软件的定义：免费。。。。
综上，造成了很多Worse is Better的现象。
最后，鸣谢有道词典，英文阅读好难。。。。