刚刚读完《软件工程概论》，感觉很多东西都曾经接触过，但在实际工作中有些理论要完全遵循可能还有些障碍，软件工程只是提供了理论上的一些结论，但对项目的具体可操作性的规范的制定方面却做的很少，所以现在很多同行都说：“我们都学过《软件工程》，但却不可能完全遵守它去做项目”，因为一个项目是否应该遵循《软件工程》还要根据项目的大小、规模、进度的要求有一定的关系。如果对于一个时间很紧的小项目，如果完全按照传统的瀑布模型一步一步的写各种文档，可能是很不现时的，很可能造成了那种“用1周写文档，用1个小时写代码，但期限是1天”的情况，当然这只是一个极端的例子，但《软件工程》发展了几十年，光是开发模型就达到了10多种，对不同的项目采用合适的开发模式，有些项目在不同的开发阶段可能还要转换开发模式，这对于我们这些做项目的公司来说，是个不低的门槛。
现在国内外都重视《软件工程》是因为，人们都认识到了如果能够适当合理的利用软件工程的理论可以减小开发成本和风险，风险降低了，成本就减少了，利润就提高了，所以有一种说法就是“软件工程就是提高软件项目利润的理论”。但人们也都意识到《软件工程》的确更接近于理论，它所提供的可操作性太差，于是就有了现在流行的RUP和XP开发理论，这两种理论就是根据《软件工程》的理论经过大量的试验总结出的比较成功的开发模式，
现在人们对RUP的诟病也开始心声怀疑，认为这种开发模式也是理论多于实践，管理过程比较繁琐，对于大项目还适合，对于小项目则不利于降低开发成本，所以现在国外提倡“敏捷开发”，而最受吹捧的就是“极限编程”（XP）。现在国内也有很多公司开始使用这种方法，
这种方法与其他开发方法最大的不同是将测试提到了一个几乎是最重要的位置，先写测试用历，然后编码，而且在测试过程中提倡使用一些自动化的测试工具，如对Java测试的Junit和对Delphi测试的Dunit。
我个人认为软件工程很重要，但更重要的是要能够根据不同的项目在不同阶段选择合适的开发模式，规避风险，适应客户灵活多变的需求变更。所以对需求调研和需求分析提出了更高的要求。我看过了一些讨论软件工程的文章，几乎一致认为“客户直接参与的项目成功的可能性非常高”，传统的软件工程中提出的不论是“瀑布”还是“螺旋”模型都是进行阶段性的客户确认再开发，等开发完或者客户的需求变了，或者需求分析有错误，完全符合客户要求的几乎没有。所以我们是否考虑一下能否在条件允许的情况下，在以后的项目的开发中多征求客户意见，而不是在一阶段完成后再请客户看，这有利于我们降低开发大规模修改的风险。这也是“极限开发”模式中很重要的一点。当然这也不是绝对的，但这是经过证实的成功率比较高的一种方式。
在前期需求调研和需求分析都做好了之后，我们就可以做概要设计和详细设计了，我认为这部分很关键的一点是确定界面风格和关于代码复用的考虑。一个符合客户习惯的界面是最保险的方案，这里面包括客户的操作习惯和审美习惯。但对开发人员更需要注意的是代码复用，一个好的代码应该是注释详细、代码可读性强、代码复用率高的集合。而要做到代码的高复用率需要高度的抽象能力和对类的粒度的划分，对于粒度的划分应该遵循很多教材上多次提到的“高内聚，低耦合”，也就是说一个函数或方法的功能越单一越容易被组合起来复用，和其他的方法或函数或其他类的关联越少越好，这样在与之关联的对象或方法改变后不需要改动或很少改动就可以被复用。
另外“设计模式”也越来越被开发人员所重视，“设计模式”为开发人员提供了一系列其他人经过多次试验证实成功的可以放心使用的解决套路，能够按照“设计模式”的思路开发系统可以获得很好的扩展性和强壮性，这也是经过无数案例证明过的。举个简单的例子，如果将获得数据的部分和显示数据的代码混在一起，如果将来在改动显示部分或改动获得数据部分则要到混在一起的代码中去挑自己要改动的部分，这可能造成不该动的代码被改动了，或者因为一部分改动了，另一部分必须被改动，这样也带入了被迫改动代码的正确性的问题。对于这样的改动需要在测试时增大测试力度，才能保证代码是正确的，当然这是以增大测试成本为代价的。用另一种方式，使用设计模式，遵循MVC模式，将获得数据部分作为C（控制部分）封装在一个函数里，将显示部分作为V（视图）封装在另一个部分，他们之间的数据传递用函数的参数或其他数据结构（如记录、集合等），这样就可以保证改动一部分不会影响另一部分的正确性，测试时只要针对改动的部分测试就可以了，不会因为不知道是那部分出现的错误而做更多的测试用例来确定错误来源。在谈到“设计模式”时人们举的例子几乎都是Java的例子，经典的《设计模式》举的例子则是用C＋＋来写的，而设计模式是一种经别人验证成功率很高的代码编写解决方案，可以用在各种面向对象的编程上，这个问题我在总装的项目以后才意识到，并做了一些尝试，感觉是比用以前的思路所写的代码维护性好一些。
如今的软件工程已经改变了很多，提倡能够快速适应客户需求变化并能够根据变化快速转变开发方向的开发方法，这一两年国内外充斥着大量的讨论能够提高开发速度、减少需求变更的开发模式的书籍，如一些认证，如ISO9000，CMM，CMMI等，还有开发模式，如敏捷开发，RUP，XP，PSP，TSPi等。在目前来看，XP是很出众的，XP对国情是否适合可能尚难以下结论，但XP对于测试的重视和对使用自动化测试工具的推崇则是我们可以借鉴的。
软件维护也是个重要的阶段，软件在运行一阶段后，可能会发现一些测试时没测出的错误，也可能客户觉得有些地方改变一下会为他们的工作提供更多的方便，这是就需要软件维护。这时需要的开发人员不会很多，但这时维护人员可能不是原来的开发人员，这是就设计到了代码的可读性和可维护性。良好的代码应该有详尽的注释，当然最好还要有简单明了的文档。维护后应该有维护记录，要说明维护原因，变更部分的说明。如果在维护阶段不知道原来的代码的意义，则维护工作根本无处着手。我在维护南昌市民卡项目过程中遇到这样一件事，因为南昌方面急着要操作员卡，而这边制卡程序需要改动，但这边什么文档都没有，程序没有业务方面的注释，根本看不出什么意思，只好重做。如果当时有一份良好的注释，可能重新开工的可能就机会没有了。
另外功能齐全的公用单元有利于减少开发重新编写的代码量，可以节省开发时间，增强代码的复用性。这在多个项目中可以看到好处，最近在新闻出版总署的几个项目中非常迅速的就搭建起了系统框架，对于一些功能需要的技术实现已经在公用单元提供了，所以可以拿过来直接使用。
这本书包含的内容很多，对我有很大启发，由于篇幅关系，暂时写到这里，请指正！
