11 2005 档案
摘要: 在项目中正式的执行xp中的过程，除了pp由于暂时没实施，其他的都在实施中，虽然这点会被很多xper说，^_^，其实我也知道pp非常好，毕竟以前经历过，但由于某些原因，在现在的team中我还不好去执行，以后找到机会，呵呵.....
自己接触xp说起来也有两年多了，而且在以前的团队中也是采用这样的过程，但现在自己带team真的执行的时候却发现碰到一些问题，一方面可能是因为自己太久没温习xp，^_^，有些过程都不是那么记得了，另一方面是在执行的时候有些步骤确实不好走，在这样的情况下，回顾了手头的几篇xp的文档，从xp中对于整个软件过程的推行来看自己实施过程中的问题。
摘要: 前天那篇blog更多的是讲了下数据驱动、模型驱动的大致概念，今天更多的是讲数据驱动以及模型驱动在进行系统实现时的方法、过程以及自己的一些思考。
摘要: 数据驱动、模型驱动作为如今软件设计中两种不同的模型驱动方法，应该说各有各的优缺点以及适用的场合，不能就一概的去认为哪种必然就是更好的。
摘要: 软件建设需要考虑的重要的两点我觉得是：
1、客户的功能需求以及非功能需求。
2、软件的维护性。
软件的技术架构就是为了满足以上重要的两点而诞生的，同时由于软件的技术架构决定了使用它的开发人员所需的水平以及开发的难易，此时又要尽量做到降低对使用者素质的要求以及开发的门槛，以保证开发的高效性，但这个相对上两点来说更没那么重要。
摘要: 写这篇和以前的意思不一样，这篇主要是对现在的动辄采用aop思想、采用插件架构、采用soa、大集成技术这些东西的一个个人的看法，象这种思想级别或者架构级别的东西来说，是很多人采用，但真的发挥了它的作用吗？不敢认同，呵呵，其实象一旦采用aop、插件体系架构这样的思想或架构级的东西，带来的是设计时，甚至是分析时的思想转变，^_^，否则采用了甚至比不采用还惨，不仅带不来效果反而会受很大的"伤害"，呵呵，所以在要采用思想级别和架构体系级别的技术转变的时候真的要慎重思考，需要的是对采用的思想以及架构体系的深入了解，毕竟做软件不是为了技术而技术的，当然，自己小玩玩当然是可以了。
摘要: equinox是eclipse的osgi ri的project，它的目标是建立成一个独立应用的plugin framework，因为现在eclipse的那个是不好做剥离的，翻译了一篇它的编码实践，希望能有些指导。
摘要: 插件架构体系是我一直就非常关注的内容，其实插件架构体系的发展已经有很久的背景了，插件架构体系的优点我们也是能看的非常明显，象硬件一样的即插即用、无论对于公司还是业界而言的良好的积累方式、为公司或业界提供统一而规范的开发方式以及稳定的内核架构等等，这些优点无论对于公司还是业界来说都是非常重要的。
插件架构体系基本的一个概念就是基于松散的模块积累方式，通过新增插件以及扩展原有插件的方法来完成系统的实现，凡事有利必有弊，在看到插件架构体系的这些优点的同时，在实现和使用插件架构体系的时候仍然会碰到不少的问题，在本文中大概的整理了一些也相应的提出了一些自己的看法。
摘要: 在和一个朋友交流权限系统方面的实现时，朋友提及到jaas，我自己对jaas不是那么了解，不好去评价，后来去网上查阅了不少jaas的文档，应该说现在大致的对jaas有些的理解了吧，个人觉得jaas只能算是实现权限系统的另一种方式，相当于提供了一个框架，至于这个框架基于什么模型我无从评价，对比下来我仍然认为基于rbac自行实现是更佳的方案，不过jaas中也有可取之处，那就是它的pam思想。
摘要: 本来作为客户而言，它需要关心的是自己想基于系统做什么，实现什么样的功能，而不会关心到技术层面，但如果碰到了关心技术的客户怎么办呢，客户关心到你用的是什么平台、什么框架、为什么要用以及它如果要基于平台做自主开发要怎么做，感觉在这种情况下挺棘手的，客户往往就变成了对于你实现需求的技术进行干预，而很多时候又没法向用户解释清楚，而且在这种情况下往往是客户根据你的介绍和讲解来做出基于这样的平台是否能实现他们需求的评估，这就挺难搞了，也许是自己的技术不过关，不过觉得最缺乏的是沟通的方法，大家觉得在这种情况下会有什么比较好的方法呢？求教.......
摘要: 几乎在所有的系统中对于权限控制都有直接的需求，而这类需求往往有其相似性，综合常见的对于权限系统的需求构成了本文档，文档主要从功能复用以及模型复用的角度来对权限系统进行总结，以便在各种系统中可对照此篇文档来进行权限系统的实现，考虑到文档的关注点在复用度，在文档中不会过多的去描述功能点到模型产生的过程，而是采用直接通过产生的模型来说明基于此模型如何实现功能点的需求。
摘要: 从公司级来讲，自己的资格是远远的不够，在这里主要也是根据自己的项目经验阐述下自己对中小型企业技术团队的一种观点，个人觉得对于中小型企业来讲三级团队的构成是比较理想的，就是支撑平台团队 应用系统开发团队 实施团队，从三级团队的构成来讲切忌企业的面铺的太广，那这三级团队就很难形成了，但在国内大部分中小型企业仍然处于盈利为上的策略，这也是没办法的，毕竟求生才是最重要的，在这种情况下，我觉得在这样的公司不如干脆由应用系统开发团队 实施团队来组成，而支撑平台则选用开源的或进行采购，当然，选用开源的概念是某个可直接用的或者不需要进行太多集成工作的，这样在公司发展到一定程度的情况下，在适当的时机下再进行升级到三级团队的建设。
摘要: 大家都知道eclipse是一个典型的插件系统，而从3.0起其插件体系架构就重构为基于osgi规范来实现的，从这也可以看出osgi必然与plugin architecture是有很多的关联性的，在这里就来说说自己对osgi r3与plugin architecture的关联。
摘要: 本文主要对于软件过程的整体规范进行较为完整的描述，来源于个人的项目经验、所在team使用的软件过程以及个人的一些想法总结而成。
文章按照对项目中采用的软件过程进行描述，之后对保证整个软件过程有效执行的工具、制度等进行描述。
本文意并不在标明这个软件过程是多么的优秀，关键是要找到适合自己团队的软件过程，没有最优秀的，只有最合适的。
摘要: 根据自己的经验整理一篇软件过程规范的文章，主要是根据自己的经历以及目前的情况来完整的描述一个软件项目过程中规范性的东西。
遵循的一个原则是："规范不是万能的，要不断调整，每个team有每个team适合的规范。"
这篇是序，明天整理一份完整的文档，对整个软件过程中涉及的规范的东西进行较为完整的描述。
"));