关于公司系统支撑工作的建议

关于公司系统支撑工作的建议

成晓旭

刚来部门不久，对部门的整体工作情况了解不多，对公司的信息系统建设情况更是不敢枉自品评。

对于像我们这样规模的公司，自己建设、实施和维护满足公司自身管理要求的管理信息系统，是目前部门公司对于企业 ERP 系统的建设方式。比如： XXXX 、 XXXX 、 XXXX 、 XXXX 等等知名企业。其实：这种 ERP 系统建设方式，我本人并不看好和推荐。如果公司也采用这种方式建设我们自己的综合信息管理系统，本着把事情做好，尽量让部门能更省心、更有效的为公司综合信息管理系统提供支撑，从我个人的视角出发、提出几点浅见：

1、   加强相似业务流程、管理模式的抽象与提炼，通过系统分析与设计、并编码实现成我们自己的基础架构源码库。 下面是用简单的源码统计工具，针对新、旧两个版本的 XX 系统，进行的最简单的代码行数统计分析情况：

	总代码量	业务代码量	架构代码量	2/8 原则 (80%BUG 分布于 20% 代码中 )	2/8 原则 (20%BUG 分布于 80% 代码中 )
旧 XX	135704	135704	未统计	27140	108564
新 XX	36891	31025	5866	7378	29513

         仅通过最简单的减少系统代码量，相信就能较大的降低系统后期的测试、调试、维护、升级的复杂度和工作量。

2、   注重新建子系统、功能模块、业务构件、甚至是最简单的一个新单元、新类的重新分析、设计和实现。 针对目前整个系统的在新运行情况和日常的维护工作量，我们不大可能有充足的人力和时间，来整体重新构建各个在线的子系统。但新业务需求的实现时有发生。既然是新增功能、新写代码，我们更有理由摒弃原来不太好的开发方式和思路，采用一些更专业、更成熟软件开发模式与架构，至少让新增的功能块一开始，就有较好的稳定性、较高的可复用度、较强的可扩展性。坚持这样，才能逐渐、逐渐地提升整个软件系统的内部质量特性、才能逐渐、逐渐地减少系统的维护工作量；否则，随着软件代码量的日益增加、系统功能的日益复杂、业务需求的频繁变化，已建系统对新需求变动的满足难度势必越来越大：“雪球效应”很可能发生在系统支撑小组，导致系统支撑小组最终很难再继续有效地支撑下去。

3、   为支撑小组的软件开发、维护工作选择适合的软件开发方法论，并结合具体工作实践进行裁剪或增补。 切合团队实际工作情况的软件开发方法，将极大改善开发团队的工作效率、提升交互软件产品的内外品质：已是不容质疑的事实。传统的软件开发方法、信息化软件开发方法、统一软件开发方法，都不太适合我们公司系统这种“应用需求变动频繁、支撑资源配置紧张”的现状。建议采用敏捷软件开发方法的原则与模式：准确把握客户的当前需求、适度设计并保持设计的灵活性、简单开发以满足当前需求、频繁重构与迭代保持系统当初的设计原则、测试驱动开发和加强单元测试从最底层开始确保系统的健壮性。

4、   在公司系统的开发、维护、支撑过程中，建议一定要坚持系统建设初期的分析、设计、编码原则，至少最起码的基线原则必须坚持。 进公司几个月来，听到、看到太多的、很好的原则在现实面前妥协的情况。表面上看，我们的妥协当时是缩短了开发时间、提高了客户需求的响应时间；其实，事后我们往往为违背这些原则付出了更大的代价。众所周知，任何项目系统的建设，在人力、时间、质量等方面都是受限制并且相互制约的。软件系统的经典的设计模式与原则也是人所共知的，最终软件产品的质量在很大程度上，就取决于开发团队在软件构建过程中，对原则的坚持力度与执行力度上。

5、   个人对公司系统构建过程的建议：准确把握客户的当前需求但不求全责备；采用经典、成熟的设计原则与模式但不过渡设计；尽量用简单的编码来实现当前功能；通过频繁的重构来坚持期初的设计和实现原则；在维护和新增功能前尽可能先重构再重用、杜绝通过“代码复制”实现相似的系统功能；加强单元测试来保证系统构件的可靠性与健壮性、将软件 BUG 的大部分解决在单元开发期间。我个人经验是：“用精巧、优雅的设计来应对需求的瞬息万变；用重构与迭代来维持良好的系统体系架构；注重单元测试保障系统内部、外部品质”。

6、   再次建议加强系统测试、尤其是开发初期的单元测试。 在我的维护工作中，很多次发现这样的现象：运行很久的程序功能突然发生一个异常，通过跟踪代码，错误居然被定位很基本的指针保护或逻辑错误上，而这些错误极易在单元测试中被覆盖、发现和解决，相反，在系统后期的组件测试、集成测试、回归测试、系统测试阶段较难再现。这类问题还反应了我们原来的测试用例的代码覆盖率不高。

7、   其实，还有很多，觉得太过于注重细节，就不写在这里了，在日常的工作中，慢慢的改进吧。