【经验分享】一名慕星人多年的工作感想

第一篇就写一下随笔，写一写工作感想吧，希望大家帮我提出宝贵意见。

在企业工作了多年，感觉自己的技术水平没有多大进步，只是觉得更加迷茫了，感觉在目前电子商务盛行的年代，自己如果去开发商业类的软件公司的话，感觉什么都做不了，什么都不会。

首先，简单写一下在企业里做应用系统，或者做项目的流程。当然这里主要说的是新项目，续建或者运维项目，我再总结总结吧。新项目的一般做法是拿到一个任务单，需要与业务部门的主要负责人（可能多个）进行沟通，最好形成沟通会议纪要，当然在沟通过程中，会根据我们自身做项目的经验，进行有针对性的互动沟通，比如这些数据需不需要结构化，需不需要进行数据统计，系统需不需要异地部署，数据是否需要同步汇总等。其次会进行架构、编程语言环境的选型，这个其实就是根据项目负责人熟悉的语言环境、架构环境，比如选择用.Net还是Java。第三进行数据库结构设计，包括选择的数据库产品，大部分采用MS SQLServer，小部分用Oracle，当然有时候这部分和第二部分交换或者同步进行，在这部分做的过程中，会大致确定系统的几大模块，每个模块涉及到哪些业务，有时候会根据用户的业务情况进行模块分类，这种模块分类方法在我们企业的软件设计过程中会经常出现。第四进行开发，分模块进行任务的分配和测试，公共模块和数据结构的调整，整体界面的设计都是在开发之前由项目负责人带头完成的，和大家讨论共同形成的，第四进行测试，功能测试一般都是在开发阶段就完成了，这里主要进行环境测试，比如不同浏览器下的运行情况，各个模块整合后的集成测试，比如公共模块是否重复引用，公共模块是否一致，是否有同名的类等等。第五进行总结和验收，主要对这一期建设情况的总结，和其他系统建设成员交流有没有可以共用的东西，有没有困难需求兄弟项目协助，同时提出下一期建设工作的设想。

一、应用系统设计与开发方面

1.在企业工作的前几年，主要做过了很多行政管理类的系统，比如OA系统，科技项目管理方面的系统，360度考核系统等等，感觉这一类系统最大的特点是要求的专业不高，流程比较多，流程总是变化，用户界面比较落后，比较古板，用到的技术比较老，比较陈旧，比如左侧一般用一颗树，上面有一些导航链接，右侧是正文，主要用到table，但好像目前比较新的技术趋势是多用div，少用table，同时会有一些图文混排技术，因为企业中很多资料都是图文并排的。
2.在企业里后来的几年，主要做专业应用类系统，比如生产数据的管理、地质资料的管理，专业矢量图形的生成。这一类系统最大的特点是要求专业性比较强，流程很少或者没有，报表很多，图件比较多，多张图综合显示的要求比较多，用户希望资料之间的关联度比较高。在做数据结构，数据接口分析，报表生成方面时，需要了解各专业的特点，各个单位之间的换算，比如方与桶、桶与吨、比采油、气油比、饱和度和成功率等等。做这类系统过程中，自己感觉软件开发水平很难有提高，顶多在图形图像显示、数据传输、数据汇总等方面有一些提升，特别是海量数据方面。用到的一些软件技术如下，比如为了帮助用户快速上传下载资料，特别是大文件、多文件或多文件夹方面，我们采用Activex控件的方式，基于ftp协议进行传输、缓存与保存，为了解决异地数据汇总迁移的难题，开始采用数据库提供的publisher和subscriber，但是随着后来系统的专业强，数据库表和字段的急速增加，这种方式总是存在问题，而且没办法解决海量附件的同步传输迁移，后来我们自行设计了一套数据传输和汇总工具，主要用C#开发，传输方面主要基于Wcf技术，可以用Tcp协议，也可以采用http协议，支持断点续传和文件的打包传输等。其他的管理界面用到的技术，其实第一部分行政类管理系统中用到的组件就已经足够了，这里有一些体会就是在右侧正文的table显示方面，我们当时用到ExtJS提供的UI控件（如GridPanel），但是随着数据量的增大（比如常规100万条记录，30个字段），系统的性能就会特别慢，后来我们采用最原始的div加table的方式，反倒快了不少，当然可能与我们的分页技术、数据表设计也有关系。

二、数据库设计方面

1.进入公司首先接触到的数据库就是sybase数据库，这个数据库产品，感觉目前流行的电子商务公司几乎没人提了，但是sybase数据库的学习对之后的ms sqlserver帮助很大，很多基础的sql语言、存储过程和触发器都是相通的。后来接触到另一个生产项目中用到Oracle数据库，Oracle的学习要深刻理解其实例、schema、控制文件，数据文件和日志文件等，使用Oracle的过程中，感觉最方便的地方是，他有一个Ora-xxxxx的帮助说明，而且错误非常明确清晰，有错误就能直接找到。再后来就是Ms sqlserver数据库，目前到了Ms SqlServer2012了，微软的产品最大的特点就是工具做的非常好，不需要我们再去其他地方下载第三方工具了，他本身的执行计划分析，性能检测分析等都已经很完善了。
2.数据库设计方面的经验总结，感觉任何一个软件系统，不管是专业类的系统，还是管理类的系统，都会将表分为以下几大类：配置表(Config)或系统表（Sys）、注册表（Reg）、代码表（Code）、邮件表（Email）、人员权限授权表（Auth）、具体业务类表（如地质类：Geo，考核类：Evt）、工作流类表（Workflow）、各类报表（Report），不过不是每个系统都有这么多类，但根据这样的分类去做，应该都差不太多，而且以这些英文名为数据表的前缀，打开数据库管理工具会一目了然的找到要查看的表。当然有时候会按照各个库的设计早晚进行分库设计，并将功能的信息合并到一个库中进行管理。比如各个专业都会存在各类文档资料，那就会单独设计一个文档库（如document），表的前缀有可能就是Doc。
3.数据结构设计模板方面的经验总结，不管我们在做什么类型的系统，只要用到数据库，就需要进行数据结构设计，而且数据结构设计有早有晚，有时候会变化，比如长度的调整，类型的变换等，同时有时候会换人，有时候开发人员之间打开系统后台进行了修改，各类因素导致系统最早设计的数据结构设计文件无法跟随系统开发同步进行。为了解决这个问题，我们想了以下这个办法，将系统最终定型的数据结构都用一个系统的功能管理界面进行管理，相当于元数据的管理，当然这是各个系统独立的在管理，没有做出一个大的平台，管理所有系统的元数据。同时要求这个管理界面提供输出下面Excel格式的模板文件，这样就可以自动生成最新的Excel格式的数据结构设计文档，并生成最新创建表的SQL脚本，同时包含表、字段说明和注释，这样就非常方便项目和系统的持续建设和运维。

4.对象数据库方面，这部分是从最近一年的系统建设过程中体会到的，同时查看了很多目前开源的产品，比如MongoDB，感觉我们之前用关系型数据库完成的资料的存储，我们自己需要对其进行管理，进行同步汇总迁移，其实很多的开源产品都已经提供了相应的机制帮我们做了这部分工作，而我们很多系统都需要有这一部分资料的管理，计划将文件资料的管理都放到这里面来做，这样就实现了关系型数据库和对象数据结合，一起来完成企业中的应用。不知道附件资料达到几十TB到几百TB的情况下，会不会降低系统的访问性能？

三、今后的技术方向

接下来的技术方向主要是以下几个方面，欢迎大家吐槽

1. 数据接口方面：其实不管是最早的Dos，还是后来的Linux、Windows、到现在的iOS，对数据的访问，对文件的访问，都要转换为对设备的访问。那么我们在做企业软件系统时，我们在存储和访问数据时，目前还是要区分哪些来自于url、哪些来自于文件，哪些来自于数据库表，而且返回的格式各不相同，错综复杂，或许他们之间的握手协议也不同，试想能否通过几种规范或接口进行统一，而不需要让每个系统进行单独设计，单独开发和单独部署，甚至做到一套程序，多家调用呢。
2. 前端技术方面，之前掌握的html+javascript（jquery）+css已经落后了，希望跟进潮流，加入一些最新的前端技术，比如AngularJs等
3. 后台技术方面：深入探讨MongoDB，Restful格式定义的规范等，以及与现有关系型数据库的结合方面结合项目进行研究
4. 矢量图形展示方面：目前比较熟悉的就是SVG，不知是否有其他的图形显示技术能够适合企业级的复杂综合图形的展现技术。