年终总结里的建议

建议：

1.       构建我们自己的基于.net开发环境的企业应用架构，一个好的应用架构关注架构中的商业应用组合以显示直接的商业价值

2.       创建和维护基于企业应用架构上的组件库，组件提供了高复用性的保证，可以从整体上缩短我们的开发周期

3.       招聘和培养我们公司的技术专家和业务顾问专家

缘于看到的一些问题：

1.       技术方面：.net的项目日益增多，大部分项目开发都是从头做起，很多公用的功能都在反复开发，如：用户、部门、权限、日志等功能和一些经常使用的web界面

2.       公用功能的设计参差不齐，没有架构师制定标准的调用接口，复用性和灵活性较低，需求变化时要花费较多时间维护

3.       多个系统整合时遇到的各种问题：单点登陆，多个用户、权限等公用应用管理很难统一、业务跨系统流转实现复杂等，这些都会花费大量的时间

4.       很多项目里的功能都可以扩展成一些可复用的组件，这些很好的技术积累都流失了，我觉得组件是研发部门的无形资产，一套完备的组件能很大程度缩短开发时间，并且提供灵活性可维护性的保证。   复用是减少开发成本最直接的方式。

5.       需求方面：开发人员设计的需求书和用户想要的有差距，导致一些没必要的开发工作；很少人做这些相关行业的需求调研、市场分析和一些新需求的前景预测，没有业务顾问专家揣摩我们的用户在想什么，使用我们系统时最关心什么功能，怎样通过我们的软件解决用户的问题，尽可能提高他们的工作效率，例如，我们做的东西用了很好的技术，如果做出来的是用户不想要或者用着不喜欢的，那还是失败的

（本人水平有限，说出这些只想起一个抛砖引玉的作用，希望部门里的设计人员考虑一下）

想法：

企业应用架构可以为我们的多个业务需求系统提供一个公用平台，在这个微容器里，基于基本组件（用户管理、权限管理等功能，在j2EE的不少企业架构里都有这些功能）支持的多种业务模块被有机的管理和关联，信息以轻松的、安全的、综合的并多方位的访问和共享（每个用户都沉浸在自己关心的信息网格中，加上赏心悦目的界面，也许会有种享受的感觉- -），组件之间的耦合和业务功能之间调用也可以被设计人员很好的解决。不过企业应用架构以及组件库都需要好的设计思想，而且花费的时间比较长，希望部门可以慎重考虑，即使不作企业应用架构，也可以先建立组件库：每个人都可以向部门的设计人员提交创建组件的申请（不一定是提出的人来做，每做完一个项目可能我们都会想，这个功能要是能做成组件多好，或者我们要做一个功能时我们会想，这个要是有现成的组件多好），部门经理和设计人员经过讨论和实际调查后确定可行性，会安排人员来设计开发，经过严格测试后将组件和和配置文档、二次开发手册以及优缺点和性能报告放入组件库中，供所有项目的开发人员参阅选择使用，并根据使用反馈可能再对组件更改或升级。我觉得组件库是部门整体开发团队的强大后盾，也可以评价一个部门技术积累的程度和技术水平，以上只是种设想。另外别人开发的好东西也可以拿来后封装供自己使用，也是快速积累的好办法


faint，摘要居然还有字数限制，在这里再发一下：（
把博客作为自己的工作日记，希望可以把自己某个时刻的想法或者学的东西记下来，就像积累实验代码一样，不断反省提高，让自己能够很认真很踏实很现实的工作。事出有因，昨天看严宏先生讲质和道，忽然觉得“质”就是事务深层的永恒内在，这些内在的特质不随人类的观察角度和认知水平发生变化，也就是说，当观察者把事务放入自己观察的环境下，受种种条件所限，他所看到的质可能已经发生扭曲，变成他从中悟的“道”，至于领悟的道是不是真正的质，也只能在这个时代的认知水平下评论，所以俺不怕在博客里保留自己真实幼稚的想法，毕竟我的博客还没有发布过，可以暂时把博客当作自己的邮箱，更何况我们现在研究的东西，说不定都是错的呢，这只是人类在一个很短阶段的探索（这个想法让俺对阿Q精神又有了更深的领悟哈）
（经历了长时间的梦游，终于学会面对现实了，不想再等待那些没有结果的结果，不管结局是不是匆匆收场，总算可以给自己一个全新的后半段人生开始了。呵呵这就是生活吧，它从来不告诉你做的事情是对的还是错的，但它总会等待一个机会用另一种方式告诉你，也许是更直接更冷漠的方式。清醒一点后，俺开始认真写年终总结，尤其是郑重的填上自己打算在新的一年中的个人期望，没想到刚发的年终总结部门就有了回应，，现在部门安排我们几个人负责组件库的构建，以后还会涉及到一些设计思想的实现，我很清楚自己接触.net的时间很少，掌握的面向对象知识太少，不过还是想把握这个机会，为自己打下气吧