一直心心念念这个阅读作业2，却一直拖着没写，是因为基本全是英文……看得真是醉了……分分钟会睡着啊……唉，果真还是功力不够，还是要多看多学习。就我印象深刻的说一些感想吧，想到哪儿写到哪儿吧，也没有构思。
No Silver Bullet 一文中Fred Brooks提到所有软件创作都包括了本质性工作（essential task）和附属性工作（accidental task），前者的困难最难解决，原因有：
Let us consider the inherent properties of this irreducible essence of modern software systems: complexity, conformity, changeability, and invisibility.
complexity：复杂性，essential task主要指去创造出一种由抽象的软件实体所组成的复杂概念结构，由现实世界到抽象世界本就是一件不简单的事情，还要将其概念结构梳理得非常清晰，这一点在我们在结对项目中已经尝到恶果了，由现实中的电梯到虚拟环境下的电梯，我们并没有充分地分析其每一项的功能细节如何转换，而是大致确定了一个方向，就写一步看一步，以至于在调试的时候异常痛苦，所发现的问题都是因为之前的考虑不周。但是在这次的团队项目中，我们吸取教训，在具体的分工和写代码之前，将我们构想的app的具体结构、功能、界面转换等以绘图的方式呈现出来，这样就把复杂性很大的一个工程通过抽象划分为一个个小工程，不仅是便于分工，更使我们团队中的每一个人对我们的整个项目有一个清晰的概念，也有利于之后的协调性。
conformity：配合性，在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。对于我们而言，团队一起做一个app，因为每个人的编码习惯不同，需要分工写代码的人保持一样的编码习惯更是不太现实，这也就需要我们在前期essential task中协调配合好，事先告知搭档自己所需要的接口信息，工作时亦要互相沟通。
changeability：易变性，软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。正所谓计划赶不上变化，《移山之道》一书中也提到，在做一个项目的期间，需求也会不断的变化，我们的团队项目也一样，有时可能会因为难度影响或时间关系，改变一部分功能的需求也是在所难免，无需抱怨，这更是提醒我们在编码时应该充分考虑这一点，使代码模块化，易修改易维护，提高可读性这些都是我们应该注意的。
invisibility：隐匿性，尚未完成的软件是看不见的，即时我们所说的抽象的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。我们正式充分考虑到其隐匿性，所以在项目初期便用一部分时间来将我们构想的app的具体结构、功能、界面转换等以绘图的方式呈现出来，虽并不能完全弥补这一缺陷，但总是能更直观更清晰地说明问题，是大家清楚自己要做什么，而不是茫然地去猜测一切。
至于Brad Cox和Fred Brooks对于银弹有没有的讨论，我感觉对于现在的我们暂时还并没有太大的意义……好吧，其实我是不太理解他们的用意。
Big Ball of Mud：
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expendient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have errded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
简单的说，大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷，这样的话说起来真是羞愧啊，忽然感觉我之前写的代码怎么好像都是这样的呢，写代码之前缺少很好的前期设计，只是心中隐约有个大方向，就开始写一步算一步了，“代码的堆砌和拼接”，这样的描述一点也不为过，big ball of mud的现象在我们的结对项目中体现得更加明显，我和我的partner在前期设计讨论期间，只是从实际电梯的角度为虚拟电梯做了一个设想，并没有对细节做太多的考虑，导致之后的调试出现很大的问题，而且问题在最后的deadline之前也还没有解决，不得不换用调度方法为先交上作业而执行了plan B，吃一堑长一智吧，虽然我感觉我之前在写代码也是这样，可能是因为代码量少，简单，而且是代码都是一个人写的，而并没有出现太大的困难，而这一次痛苦的经历着实令人难忘，因此在之后的项目项目中，还是应该注重前期设计，关注软件的特性和功能，然后集中在架构和性能，使得软件设计初步就避免产生方向的偏差。
总的来说，感谢老师让我们阅读这些资料，感觉收获很大，自己平时的话可能并不会主动去看这些，特别是英文的，虽然这些阅读材料中还有一部分还没有看懂，可能是能力有限以及开发经历太少，还无法体会更多的精髓。但目前来说，有收获就还是好的，我想，等我再码上个几万行代码回来看这些，又会是不一样的体验吧。