标签：io ar os 使用 sp strong 文件 数据 div
在欧洲中世纪的传说中，有一种叫“人狼”的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子作成的特殊子弹才能把它杀死。Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ，说明在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。他当时大胆声称并预言方法学家们10年之内绝找不到什么极好的的神奇银弹。
现代软件四个无法回避的本质问题：复杂性，一致性，可变性和不可见性。复杂性指的是软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的；不可见性指的是尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难；统一性指的是在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难；易变性指的是软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。
在过去，软件工程领域的几大突破：高级语言、分时系统和统一编程环境。
这些突破部分解决了一些问题，但是大型软件开发的困难度依旧很大。作者列举了一些可能成为“银弹”的技术，比如模块化编程、面向对象编程、人工智能、专家系统、自动编程、可视化设计、程序验证、环境和工具、工作站。
上学期我们学习了面向对象课程，初步接触了软件开发，了解现实抽象到代码中的过程。编程时，要注意抽象各个实体间的联系，减少代码量。而且大型软件工程要多人进行，各个类之间的交互要设计好，成员之间的代码要能结合起来。对于可视化编程，像VS和Eclipse都支持灵活的编程方式，可以拖动组件，也可以自己在代码中设定组件。
但是，这些都不能从根本上简化程序设计的复杂性，目前本质性的问题仍然无法解决。这学期体会了团队编程，感觉对于工程进度很难把握，各个成员技术实力和分配到的任务难度较难协调，导致部分成员的工作时间不同。
本篇作者对于软件开持乐观态度，认为软体危机是必然会面临的的困境，但并非是无法克服的。
当全球经济进入资讯时代，市场对资讯殷切需求而产生的经济诱因，将促成人们社会中的文化改变。加上目前遭遇的软体困境：成本过高、品质不良、以及人们无力去改善它们。使得人们对软体的看法和思维产生巨大的变迁，人们开始看重面向对象编程。在新环境中，软体的价值体系、权力结构、以及软体师与消费者关系重新定位；彻底从过去重视程式的撰写过程转而重视组件价值、拥有、及买卖系统等基本文化要素、而导致软体产业的革命。把组件的复杂封装起来，对使用者而言，调组件再也不复杂了。使用者无需了解内部构造，只需要使用相应组件即可。人们不再受困于组件内程式撰写的复杂，而专注在组件本身的使用、价值和买卖上。同时作者作了更远的展望：非文字的编程，可以使每个计算机的使用者都成为编程者。
大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑。引用吴际老师的话就是一个“面条程序”。产生大泥球的原因可能是程序员在编写代码时，而是为了代码完成的效率，编写一次性程序， 没有考虑整体的模块化。或者在编写过程中不断更新新的功能，导致煤球越滚越大。在学习面向对象编程以前，我就是在编写泥球。整个代码只有一个主程序。对于简单功能的程序来说，没什么。但是对于一些功能比较复杂的软件工程程序，如果没有对代码进行很好的整体设计，会造成功能混乱，调试效率低，测试效率低等缺点。泥球使得系统内的信息难以得到更好的控制和共享，使得信息失去了应有的价值。大泥球般的系统的整体结构没有得到很好的界定，也就使得大泥球越发的复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。
对于这次的软件工程团队作业，我深有体会。学长的代码基本上符合面向对象的要求，但是个别类如DownloadFile类，这个类的run方法实现了网站访问，本地文件下载以及数据库更新这三个核心功能，导致代码过长，而且难以维护。我们在修改时会尽量修改代码结构，减小煤球。
本书讨论两种不同的自由软件开发模式︰
大教堂模式︰原始码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。
市集模式︰原始码在本模式也是公开的，不过却是放在因特网上供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
这篇文章的要义是让够多人看到原始码，错误将无所遁形。
虽然书上这么说，但是我们这次软件工程开发是按照大教堂模式的，因为每个团队都有自己的项目，很少有人会关注其他团队，而且我们组实现的是网络爬虫，核心功能比较单一，而且实现方式也较单一，没必要放在网上供其他人员开发。而且对于一个小的应用软件，一个小的团队更便于交流。
本文批判了滥用集市模式的人们，代码不加修改的重用，编写代码时不去探究代码精髓，直接简单引用，造成了代码质量越来越差
我在本次软件工程负责处理爬取内容的柱状图动态显示。一开始我只是简单引用了网上的现有代码，发现效果不是很好。柱状图的显示范围不符合实际。部分冗余数据应该去除，而且柱状图的显示窗口不能调节大小和
显示位置。于是我仔细学习力JFreeChart的相关函数，对原有代码进行了修改，使得代码符合我们团队的要求。
作者提出了普遍认为是“好”的设计原则：
他又提到了“更坏是更好”的设计原则：
Unix和C在设计上，充分考虑了实际环境，而放弃了一些一致性和完整性，保证了简单性。这点让C和Unix在历史的选择中胜出。C++也是如此。作者以此为例证认为实现简单的优先级更高。
但是在第二篇文章中作者对之前的观点进行了反思，实现简单也可能造成结构的混乱。
这篇文章主要是介绍了“瀑布模型”。作者总结了自己在软件开发中的经验，提出了一个软件项目的开发架构，开发过程是通过设计一系列阶段顺序展开的。
瀑布模型主要分为下面三个阶段：
1.定义期：“分析重于设计，设计重于编码”，因为差错产生的越早，后面纠正差错所花的成本越高。
2. 开发期：该阶段实现系统的详细设计和具体应用程序的开发。需要系统设计人员和软件开发人员的大量工作，同时，用户必须有效地参与设计过程。
3.维护期：维护是系统生命周期的最后一个阶段，也是持续时间最长、付出代价最大的阶段。前面各阶段的细致工作，其中一个目的就是为了提高系统的可维护性，降低维护的代价。
我们的团队项目主要是在学长代码的基础上进行的，所以我们可以省去定义期。但是由于学长已经基本实现了爬虫的基本功能，所以我们在设计期就花了好长时间思考该增加什么样的功能。我们的开发是边开发，边维护，所以我们将开发期和维护期合并在一起了。
当前，传统的软件工程方法越来越难以适应迅速变化的需求。近年来出现了一类新的轻量级的软件开发方法，它们被统称为敏捷型软件开发方法。在所有敏捷开发方法中，XP 是最引人注目的。
早期的时候，多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改”。软件行业中最初的一场运动是要改变这种情况，而引入了“正规方法” （methodology〕的概念。这些（正规）方法对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践 － 因此我把它们称为工程方法（engineering methodologies）。工程方法已存在了很长时间了，但是没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。而敏捷型方法（agile methodologies）的发展是对这些工程方法的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。
我们团队在开发中保持两天一次scrum meeting的习惯，这样有助于团队成员及时完成任务，便于PM管理项目。而且我们的开发人员的寝室都很近，我们可以及时交流，主要是面对面交流，这样有助于我们及时改正程序出现的问题，也便于协调成员间的任务进度。
本文主要讨论了工程方法论和敏捷方法的选择上。我比较赞同作者的观点，对于不同的软件要根据实际情况指定编程方法。盲目套用是不会成功的。
标签：io ar os 使用 sp strong 文件 数据 div
原文地址：http://www.cnblogs.com/wangao1236/p/4093982.html
