质量信息管理系统开发中的问题
质量信息管理系统是一套以Swinglet为基础框架，使用JAVA语言开发的B/S应用软件。在这一年多的系统开发过程中，质量系统的基础框架和代码编写方式已经越来越显得不太适应现在的开发，在开发过程中，面临着很多实际的问题。此文档只就目前开发过程中出现的问题进行一个总结。
一．无人升级维护
Swinglet框架的出现时间非常早，和很多JAVA社区的框架一样，是一个开源项目，公开源代码，使用者可以随意使用，然后也是在很早之前Swinglet框架已经渐渐淡出了历史舞台，框架处在一个无人升级、无人维护的这么一个尴尬境地。作为一个公司，对于开发项目而言，既不应该盲目追逐新技术，也不应该太过保守，而应该选择当时非常成熟的技术，同时逐步加入新的东西，循序渐进。就这个框架而言，目前无人维护，它所必须使用的servlet.jar的版本非常低，而现在servlet.jar版本已经更新到3.0以上，版本的向下兼容性如何，是否会存在问题，这都是未知知数，而与servlet.jar密切相关的还有TOMCAT服务器；另外持续使用老版本的servlet.jar无法使用新版本中的新功能。如果继续在项目中大量使用Swinglet框架，那么公司必须自己对框架进行升级和维护 ，就目前情况而言，得不偿失。
二．项目不成熟
Swinglet其实就是是对Servlet进行了再封装，但Swinglet的封装，是对展现层面的Servlet的封装，就本质而言就没有脱离老的Servlet程序的开发思想，只是封装之后的Swinglet让我们在写程序的时候不需要再象当初开发Servlet程序的时候那么烦琐，更不需要再在程序里面将HTML语言打印到页面，因为这一切Swinglet已经为我们封装好了，但实际上，Swinglet做了原本该由页面所做的事情，增加了服务器端程序开发的复杂度。另一方面Swinglet框架也提出了一个影响到后来技术发展的思想——“服务器端控件”，不过这项技术在Swinglet中实现的并不好，目前有很多框架吸收了它的这个思想，在具体实现上也做的更好，特别是MS的.NET，它的面向程序员级的可视事件驱动开发和服务器端控件结合的非常好，可以说，真正达到了当初Swinglet所想做，而没有做到的东西。
三．资料匮乏
基于前两个原因，自然而然的出现了资料匮乏的情况。一年之前，刚刚加入质量项目组的时候，可以说完全不懂Swinglet，在网络上几乎完全搜索不到任何一点点关于Swinglet的中文或者资料，当时的入门可以说的痛苦万分。资料的匮乏加大的学习和深入的难度，不过，从另一方面讲，一个处于无人升级维护，已经淡出历史舞台的框架，无论作为个人还是公司，是否还有必要进行深入的研究，我觉得，这个问题值得商酌。
四．可扩展性差
一个优秀的框架，应该具有良好的可扩展性，随时接纳新的东西，只有这样的框架才具有旺盛的生命力，才能不断发展、成熟和完善。然而遗憾的是，Swinglet框架并不具备这样的能力。质量系统开发过程中，特别是9所质量系统的开发过程中，也曾经想过，逐渐将一些比较成熟的好的东西加入进来，只是，确实找不到切入点。
五．系统性能及安全性
这是一个系统级的问题。
1．Swinglet对于用户的管理方式是，每来一个用户，就分配一个Threadlocal，用户及用户所拥有的大量信息都被放在其中。Threadlocal已经被证明非常耗费性能，已经不推荐使用，而Swinglet的核心部分，正是以这种方式来运作，后果是系统性能低下，极易引起众多并发症。另一方面，Swinglet框架的想法是将几乎所有的东西都交给服务器运行，这样的方式和jsp+javabean的方式一样，走得过于极端，不便于开发的同时也会影响到系统性能。
2．安全性包括很多方面，这里只就并发控制及其相关问题进行阐述。对于并发操作Swinglet似乎完全没有考虑，而这种系统级的问题，作为应用软件开发公司的我们，没有必要放太多的经历在上面，因为有很多现成的东西，已经为我们打好了基础，我们所要做的只是拿来主义，直接拿来用，提到并发机制就不得不说说数据的同步更新和数据缓存机制，在这两点上，Swinglet同样做得不好，如果要让应用软件开发人员在原框架的基础上来完善，又违背了当初选用框架的初衷，工作量巨大。
六．灵活度差
Swinglet框架对页面的编写是强侵入性的，必须完全按照框架的要求的规则书写页面。整个页面，几乎都被基于Swinglet规则的编写方式所占满，通用性太差，而要在页面上加入一些别的东西，也特别的困难，比如，要想加入一个javascript，所要做的工作实在纷繁复杂。
七．偶合度大
在质量信息管理系统中：
首先、数据层、逻辑层和表现层之间的偶合度非常大，开发人员几乎每天都在表现层、逻辑层和数据层的迷宫中缠绕，编译完后台的CLASS之后，才能看到表现层的页面展示情况，而这也是Swinglet的先天性所决定的；
再者、类于类之间联系也是纷繁复杂，偶合度非常之大，经常是碰了一个地方，引起一连串的连锁反应。
我想，高偶合是任何软件开发中都所不想见到的情况，而现在的实际情况却就是这样。
八．开发效率低
最后，我想谈谈开发效率的问题，之所以把这种跟程序员和公司都密切相关的问题放到最后来谈，是因为，影响开发效率的因素是多方面的，所以，我想在把其他因素都谈得差不多的时候再来谈开发效率的问题。
1．项目采用的框架无人升级和维护，开发中，只有原封不动的始终使用老的开发方式，这必然会影响到开发的效率。
2．项目采用的框架不成熟，在使用过程中，应用软件开发人员自觉或不自觉的要不断的去维护框架，而这种维护又是不自觉的，无条理的，这样的结果是框架越来越不稳定，同时开发效率也会越来越低。
3．技术资料匮乏，我想这对开发效率的影响不用多说。
4．可扩展性差，很多非常好的东西无法引入，举个例子，也许引入另一成熟技术后，某些功能，只需要几句代码就能完成，但无法引入的后果是，需要自己写上百，甚至上千行的代码，我们这样写出的代码，无论是效率还是重用性上都不及别人成熟的技术，同时，也降低了开发的效率。
5．系统性能和系统安全，本来应该是我们要考虑，但不需要我们实现的内容，因为，作为应用软件开发商，只需要对应用软件的性能和安全性做一个全面的评估和分析，然后决定采用何种框架或者技术，问题就能迎刃而解，但遗憾的是，目前质量采用的Swinglet框架在性能上并没有优势，在安全性上几乎完全没有考虑，这使得应用软件开发人员不得不停下脚步，去做系统级的事情，影响软件开发效率。
6．在开发过程当中，Swinglet框架对页面编写的强侵入性造成的灵活度差所带来的结果是，开发人员为了去实现一个小小的功能，而疲于琐碎而又复杂的规则，这对开发效率的影响也是显而易见的。
7．软件各模块各个类之间偶合度大，造成开发和修改代码时候特别容易引起连锁反应，调试起来特别费时费力，严重影响开发效率。
8．由于当初资料的匮乏和工期的紧迫，开发人员对Swinglet框架的控制力不够，封装出来的类天生就具有很多的不足，现在我们在开发的过程中，继续维护当初编写这些类时所定下的规则，在这些类的基础上再写出更多的类，而在这些规则，或者说是开发模式，已经有很多严重影响到了开发的效率。当程序的功能不断完善的时候，代码量也随之迅速增长，代码复杂度以几何倍数增长，这样一个无论代码量和代码复杂度都巨大
的软件，维护难度将难以估计。
这些是我就目前质量系统里面所使用的开发框架、编程模式和开发现状的一点体会。
本文地址：http://com.8s8s.com/it/it12989.htm