阅读作业之二
首先我想说，每次看到满满一页的英文甚至连排版格式都没有的时候，我就想用chrome浏览器的自动翻译功能……
关于No Silver Bullet
这篇文章写了软件工程的本质和意外。其实对作者所说的软件工程我还没有太多的体验，因为目前我做过的工程还基本停留在大作业水平，不管是规模还是难度都比不了工业中的软件。但是对作者所提出的观点，我表示双手赞同。
也许是手敲代码的方式实在枯燥，人们一直没有放弃对软件开发的silver bullet的寻找和期待。要么希望编程语言能智能到像平时说话一样这样程序员只要输入需求或者流程图就能自己生成一个软件（“图形编程”和“自动编程”），要么寄希望于人工智能。关于这些，作者已经很明确的说明他的观点和依据，这样的编程语言或者图形化编程也许会解决程序员一些非本质性的困难，但是不能改变整个软件开发的复杂度，而且它们也许会给程序员带来新的麻烦。（其实我一直在想，如果某一天，人只要说一句话就能对计算机进行编程的话，那么程序员这个行业也就没有存在的价值了，为什么程序员要用自己的幻想让自己下岗呢~~）
软件工程中不仅包含技术问题，在软件规模达到一定程度后就会出现管理问题。所以单纯依靠编程语言的进化并不能带来多少改变，相反我们应该从更实际的角度出发，做出一些真的能改善软件工程行业的举措。比如培养出顶级的架构师，给每个程序员成长锻炼的机会等。
我十分同意作者的观点。在这学期的软件工程课中，我们的teamwork已经完成了alpha版的开发，在真正动手做之前，我觉得这个工程量很大，不知道从何下手，但是真正开始做，一旦把整个程序的架构搭建好后（这个特别感谢PM的辛苦工作），再加上被daily scrum逼得每天都要写代码的时候，就发现原来觉得很庞大的工程已经一点点写出来了。回顾整个过程，我觉得写代码反而不是最困难的事情，分析需求、设计程序的架构、各个模块之间的协调、测试可能占用的精力更多。所以可能在真正的软件工程实践中也是这样，我们要促进整个软件工程业的发展，关键问题一定不是编程语言，也没有一点就见效的silver bullet，还是要从最基本的人才培养、产业结构等问题考虑。
关于人工智能的随想
另外，对于人工智能，我想过很多，也想在这里说一下自己的想法。我觉得计算机是人造出来的，也是由人类确定的指令控制的，也许它在计算速度的方面比我们快一些，但是终究是靠人控制，它的智慧不会超过人类，也不大可能出现电影《I, Robot》中说的自己进化的情况，所以我一直觉得机器人占领地球只能出现在科幻电影中。
有人曾经这样说（非常抱歉，因为我经常在网络上看到各种文章、帖子，所以不记得出处了……），如果给一个机器人两个一模一样的樱桃要它选择的话，它不会有答案（编程初始化的问题暂且不谈），因为它没有选择的理由，但是人就不一样。计算机是逻辑的产物，它所做的所有事情本质上都是对0、1进行操作。它能做的事情很多但是它能做的事情也很少。
一个偶然的机会我听到了一个计算机专业教授的讲座，在讲座中他提到：“为什么计算机下世界象棋可以战胜世界冠军卡斯帕罗夫，识别能力却比不上三岁的孩子？”虽然人工智能、模式识别目前发展很快，但是目前再好的算法识别准确度也没有一个普通人高。那个老师说：“因为人不知道怎么识别，所以计算机也不会。”我觉得这句话道出了根本，人都不能理解的东西怎么能指挥计算机做呢？
目前人工智能的发展很快，专家们一直在尝试让计算机按照人的思维模式去计算，这些工作也取得了很多让人吃惊的成就。计算机能做的事情越来越多，但是到现在，也没有出现能通过“图灵测试”的机器。
扯了这么多，其实我是想说我们发展人工智能让计算机做更多的事情，但它终究只是工具，解决根本性问题还要靠我们自己。就像作者在《no silver bullet》中说的，编程工具和语言都只能解决非本质性问题，软件工程的管理、协调、人才培养等问题才是能提升软件产业的最根本措施。
关于Big Ball of Mud
在读这篇文章的时候，我不禁想起自己写的程序，真的是很惭愧，大部分都是ball of mud的状态。曾经有一次做大作业的时候，因为最初没有设计好，只是有了大概想法就动手做了，导致后面越写越纠结，甚至还想重头开始写的。虽然在各种编程书中看到很多让程序有条理，有效率的方法，但是真正在实践的时候还是会不自主的回到泥球的状态。我想这还是因为工程经验不够的原因吧。
目前我能想到的避免泥球的做法就是动手写代码之前先设计好整体的架构，不要写到一半发现有问题又纠结是重写还是凑合着……
关于瀑布型
我觉得瀑布型最大的特点是整个软件开发过程是按照流程一步步走下去的，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。并且文档在瀑布模型的开发过程中有重要的作用。这种开发模式最大的问题就是需求更改的成本太高。
邹老师在现代软件工程讲义中讲软件开发的各种方法，提到了瀑布模型（在这里），并用制造汽车做例子说明了瀑布模型的最大问题：
你(用户) 提出要发动机, 车身, 车窗, 方向盘, 加速踏板, 刹车, 手刹, 座位, 车灯…
生产商按照瀑布模型流程给你设计, 生产, 六个月后交付。
看到样车后…
你提出– 我当初忘了一件小事, 要有倒车灯
§ 当倒车的时候, 倒车灯会亮
生产商说:
§ 我要重新设计车尾部，加上倒车灯，把车底拆开，安装线路, 修改传动装置把倒车档和倒车灯联系起来。。。我得重新开始
你说: 这不是很小的一件事么?
我觉得在软件开发的过程中，可能瀑布模型并没有敏捷开发那么敏捷，但是它也有很多优点：
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
——百度百科
