个人阅读作业2
作业要求：阅读关于软件开发本质和开发方法的博客/文章，结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得。
No Silver Bullet - Essence and Accidents of Software Engineering这篇文章主要将软件工程存在很多问题与困难，并且解决的希望十分地渺茫。欧洲中世纪传说，有一种叫“人狼”的妖怪，它们专在月圆之夜袭击人类，传说中对“人狼”，普通子弹都伤不到也打不死它，只有一种用银制的特殊子弹才能把它杀死。引用此典故，用狼人来比喻在软件开发过程中所遇到的难题；用能够奇迹似地将狼人一枪毙命的银弹来比喻解决软件开发过程中难题的方法。软件工程发展到现在遇到了很多问题，其中软件工程开发所面临的本质问题是复杂性、整合性、易变性和不可视性。为了解决这些问题，人们探索了很多方法，比如高级语言、分时系统和统一编程环境等，但是这些都没软件工程的解决本质问题，只是从一些程度上减少了错误的发生率。最后作者写了一些可能的解决方案，如模块化编程、面向对象编程等，但是又认为解决本质问题的可能性似乎都很小。
There Is a Silver Bullet – Brad J Cox这篇文章与第一篇文章都在讨论软件工程中的silver bullet，本篇作者比第一篇作者要乐观的多，他认为面向对象、软件封装，使其对于使用者简单易用就是所要的silver bullet，同时作者更远的展望了非文字的编程，认为它可以使每个计算机的使用者都成为编程者。
big ball of mud一文介绍了大泥球的产生及解决方法。大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑。产生大泥球的原因可能是程序员在编写代码时，而是为了代码完成的效率，编写一次性程序，没有考虑整体的模块化或者在编写过程中不断更新新的功能等。定期检查以及重构是作者提出的解决方案。
CatB – Cathedral and the Bazaar讲述了cathedral和bazaar两种软件开发模式，cathedral即大教堂模式指源代码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。bazzaar即集市模式指源代码在本模式也是公开的，不过却是放在互联网上供人检视及开发。
Lost in CatB一文主要批判了现今软件呈现一种"脓包"似的状况，无休止的复制,粘贴，质量越来越差，批判了集市模式的软件开发。文章还提到了彼得定律，就是在一个根据人的业绩、成就和价值来提拔人的组织中，最终会把一些人提拔到他们并不胜任的位置上。
Worse is Better – Richard Gabriel由两篇文章阐述，作者认为简单一点更有利于移植等操作，为了追求简单，其他方面可以在一定程度上做出让步，并提出了简单性、正确性、一致性、完整性等worse is better的设计原则，而在第二篇文章中作者对之前的观点进行了反思，表明实现简单也可能造成结构的混乱。
Managing the development of large software systems: concepts and techniques阐述了瀑布模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型有阶段间的顺序性和依赖性、推迟实现、质量保证等特点。
Agile Method – by Martin Fowler主要讲了敏捷开发方法，它以代码为主，强调代码是文档的主要部分，提出适应性比预见性更重要、以人为本而不是以项目为本的观点。极限编程、SCRUM方法论、水晶方法、上下文驱动测试、精益开发、统一过程等是一些比较流行的敏捷开发方法。
软件工程的方法论到底有多少用处的两篇文章中Why Software Development Methodologies Suck讲了一些软件工程方法几乎无效的原因，提出划分小开发周期和提升反馈效率的解决方法；The New Methodology讲的也是敏捷开发，讲了敏捷开发的由来，其面向人、以人为中心的特点，以及一些具体敏捷型开发的方法。
感想：
所给的几篇文章大多是英文，阅读起来比较不顺，对于我的英文阅读小小的锻炼了一下。
我自认为写代码的能力本就比较弱，读了这几篇文章后，觉得自己确实有很多的不足，需要更多的学习和练习。我以往写的都是一些小的程序，了解一下题目要求，就开始动手敲代码了，从没有考虑过代码的重用、更新、移植等问题，也很少有注释、文档等，可以说就是代码的堆砌和拼凑，就是一团泥球。对于我们以前的小程序作业，或许泥球的代码的问题不是特别明显，但是如果要真正做一个软件项目，并且可以真正投入市场，写一个泥球代码可能会给团队的其他成员的工作带来困扰，也会对之后软件的更新维护等带来很大困难。所以，应当十分的注意这个问题，即使是写个小的程序，也要结构清晰，不能再写泥球代码了。
关于团队项目，我们团队做的是北航MOOC的安卓客户端，我们有两轮的迭代，根据目标和需求给每个人分配任务，定期交流反馈，并发表daily scrum博客，运用了敏捷开发法方中的SCRUM方法论，我认为这个方法还是挺有效果的，能够明确任务并监督和督促完成。关于大教堂模式和集市模式，我们团队属于大教堂模式，瀑布模型也值得我们团队学习和实践。根据worse is better观点，我觉得我们的团队项目可以聚焦一些重点，尽力做精做好，而对于不是十分重要的地方，可以放低一些要求，希望最终我们团队能把软件做好。
关于Lost in CatB，开源本意是好的，想共享资源，减少某些软件的工作量，但是现在的软件过分依赖公开代码，总是复制和粘贴，大大降低了软件的质量，确实是一个问题，开源代码用与不用，还需要根据具体情况认真分析判断。对于silver bullet，我觉得第一篇文章的作者观点消极了些，情况是否如第二篇文章所言比较乐观，是否有解决软件工程本质问题的银色子弹，我对于软件工程的理解还很浅，体会也不深，就不妄加论断了。
