EcommerceAll

从Jquery Grid 谈前端框架设计

Speed — Tue, 19 Aug 2008 17:37:00 +0800

摘要: 框架毕竟是框架，没有最完美的，只有相对合适的，使用者需要分析知道自己的问题在那里，然后去设计开发、使用合适第三方的框架，或直接使用、或二次封装、开发、修改源代码，来解决自己的问题，总之，不要做一个问题的抱怨者，等着别人煮米下锅。

阅读全文

Speed 2008-08-19 17:37 发表评论

项目管理之能不能不要再说完成了90%？

Speed — Thu, 14 Aug 2008 00:32:00 +0800

摘要: 我以前做项目经理时，带了一个分销系统的项目，同时并行的还用另外的一个配合的项目，每周GM会review我们的工作，其实和过堂差不太多，气氛太紧张了，冷冰冰的，很不舒服，再加上两个PM一起被review，有点暗暗较劲的意味，我当时深深迷醉与项目管理的可视度的概念，就是增强透明度，我希望把我项目中的Issue尽早的暴露出来，评审的人可以看到，或可以帮助我一起解决，或了解项目的Risk和真实的Progress，真实的理解我的处境，给我必要的Resource支持。
阅读全文

Speed 2008-08-14 00:32 发表评论

纸糊的架构设计

Speed — Sun, 10 Aug 2008 10:55:00 +0800

摘要: 最近，负责客户的一个项目设计的审计工作，是一个短信平台的项目，上行和下行通信都有，之所以叫平台，是想将客户的很多的业务系统，涉及到短信的部分都统一挂接到者一个服务平台当中，只要一家服务提供商，量大从优，避免各自为战，浪费资源。业务系统多是遗留系统，当中对短信需求各不一样，客户从自己的vendor List中找了一个短信服务提供商（SP）。一般的要是能进入vendor list中，说明实力还是有的。阅读全文

Speed 2008-08-10 10:55 发表评论

为什么要使用JBoss Drools

Speed — Thu, 07 Aug 2008 14:22:00 +0800

摘要: 对于business rule, 一般的情况是，好的BA，可能更善于发现、抽取business rule ，并用结构化的方式描述、记录下来，普通的BA可能更是一种流水账式的、吃那拉那的描述方式。
不管怎样，BA在写文档，use case的时候，那些business rule被分布在文档中不同的部分，然后这些rule，在分工时，有被理所当然的分给不同的开发人员来开发。阅读全文

Speed 2008-08-07 14:22 发表评论

从用户的角度看待BA

Speed — Sat, 26 Jul 2008 11:43:00 +0800

摘要: 关于BA，很多人写书为了谋取利益，极力和UML、UseCase扯上关系，误导了很多努力向上的人，把工具当成了能力。很多公司在面试BA时，也非常看重你会不会UML，无疑是添乱。阅读全文

Speed 2008-07-26 11:43 发表评论

多背一公斤

Speed — Mon, 21 Jul 2008 18:10:00 +0800

摘要: 在旅行的途中，为山区的孩子们多背一公斤的捐赠物资，这样的idea，平凡又伟大。
旅游区的普通百姓其实很苦，外地人的蜂拥，抬高了物价、房价，而大部分本地的人收入确非常的低。
人们看到了四川、贵州、云南、海南旅游风景的美丽，却看不到山里的茅草屋里的贫穷。阅读全文

Speed 2008-07-21 18:10 发表评论

不要被牛粪糊住双眼

Speed — Sat, 19 Jul 2008 21:59:00 +0800

摘要: 很多人在走上管理职位时或者被赋予超越自己目前现状的角色时，精神状态陡然发生了变化，工作更积极了，主动性加班也多了，说话的声音也大了，语速也加快了，总带着居高临下的语气，不说教一下别人总是不爽。
阅读全文

Speed 2008-07-19 21:59 发表评论

struts 2依然坚挺 Seam前景不明

Speed — Wed, 16 Jul 2008 23:31:00 +0800

如今Java的Web MVC框架，夹在RIA和Ruby on rails、PHP之间，疲态尽显。
看图说话：
struts2还在攀升，spring MVC 缓慢增长，seam不温不火

最好的态度就是观望，不要在下面这些技术直接换来换去，而是以提高设计思想、加强积累、纵深发展为主。

Speed 2008-07-16 23:31 发表评论

Think in Jquery

Speed — Tue, 15 Jul 2008 19:06:00 +0800

摘要: 设计者高高在上，不食人间烟火，只是提供约束，不要这样，必须那样，而不是提供方法和可以复用的API。

开发者是处于解决问题的一线，饱尝重复造轮子的疾苦，他们最需要的是快速的解决问题，以更恰当的方式工作，寻找更容易构建系统的技术和方式。
Jquery给设计者上了很好的一课。
Jquery就像一个魔法师一样，$()就像魔法棒一样，随手一指，一个木偶变复活了，一瞬间具备了各种各样的复杂的能力。
阅读全文

Speed 2008-07-15 19:06 发表评论

成熟的架构+创新的扩展

Speed — Wed, 09 Jul 2008 19:47:00 +0800

摘要: 技术是基础，积累才能提高，用户是目的。成熟的架构+创新的扩展，server端，团队应当继续构建、成熟以spring为基础的企业应用开发平台，深度挖掘、孵化、封装，同时将精力转向客户端。努力实现客户端与server端的粘合剂开发提高开发效率，建议的平台是spring + jquery 阅读全文

Speed 2008-07-09 19:47 发表评论

I don't want to say.

Speed — Fri, 16 May 2008 10:52:00 +0800

摘要: Look at our school building. nothing can describe the scene. 阅读全文

Speed 2008-05-16 10:52 发表评论

电子商务网站的可持续发展

Speed — Tue, 01 Jan 2008 15:29:00 +0800

摘要: 2007年终于过去了，从焦油坑里爬出来幸存的人们，互相握手庆幸，喜极而泣，纷纷在博客上写工作总结与来年展望，而我终于厌倦了期权的精神鸦片，难得的坐下来，远离自己负责的网站，想一想来年的布局。
阅读全文

Speed 2008-01-01 15:29 发表评论

好事要做到底，我们需要full stack的API设计

Speed — Tue, 01 Jan 2008 15:27:00 +0800

摘要: full-stack 的设计，意味着各层能够无缝的集成在一起，遵循的DRY原则（don't repeat yourself)，将各层共用的东西，抽取出来，并通过自顶向下的设计，无缝的集成在一起，粘合在一起，达到更高层次、更粗粒度的重用，同时为了保证灵活的可扩展性，在更高、更粗的粒度上遵守开放-封闭的原则，在各层的各个关键点，要提供诸多的钩子，回调的接口，供使用者扩展。full-stack的设计，在层与层之间，并不一味的追求松散的机制，而是相反，在层与层之间增强一定的内聚性，粘合力，以此来达到粗粒度的封装与重用。阅读全文

Speed 2008-01-01 15:27 发表评论

业务平台的真的存在吗

Speed — Tue, 01 Jan 2008 15:26:00 +0800

摘要: 在现实当中，真正影响我们，耗费我们大量时间的，对我们进度有很大影响的，就是在现实中复杂的需求，业务逻辑，这些复杂的需求，难以封装，造成复杂的设计、复杂的库表关系，这些复杂的设计，我们都知道越复杂的东西，越不稳定，更容易遭受到需求业务逻辑变化时的冲击。（希望那些做增删改查的人不要跳出来扯淡）

阅读全文

Speed 2008-01-01 15:26 发表评论

精心打造Team的组织架构

Speed — Sun, 03 Jun 2007 15:04:00 +0800

摘要: 长期以来，很多Team的组合都是随意的，从创建到稳定,　不经意之间，一个Team就出世了，在项目进行当中，弊端尽现的时候，也没有人注意到是团队的组织架构，人员搭配是否出现了问题，Team成长过程，就好像一个树籽落在地下，然后自生自灭，有的长成了歪脖子，有的则树倒猢狲散，有一部分，运气好，成为能经风雨的大树。　　阅读全文

Speed 2007-06-03 15:04 发表评论

应用层缓存　VS　ORM缓存

Speed — Sat, 02 Jun 2007 19:39:00 +0800

摘要: 最近做一个比较大的电子商务项目，预计每天订单量将在５万多单，客服人员需要频繁的下单、查询订单、操作订单，客人预订完订单后，会立即进入处理流程，为了提高服务质量，要求流水化作业，平均要在４０分钟－８０分钟内处理完订单。所以订单在创建后，会在短时间内，被频繁的修改和查看. 阅读全文

Speed 2007-06-02 19:39 发表评论

Ibatis VS Hibernate

Speed — Sat, 05 May 2007 18:14:00 +0800

近日，在JavaEye论坛中，看了Ibatis和Hibernate的帖子，看后，心里觉得的憋闷，不说不快, 这里，我想更细化一下：

1. 库表的复杂度，首先取决于需求，不取决于设计，设计能力强的人，也要遵守库表设计的规范，从巴克斯三个范式上，原则上也要遵守。不能说用了Hibernate,自己的库表设计能力就强了。不能为了用Hibernate，就去一味批判复杂的关系不对。复杂的关系设计对不对，首先取决于是否有复杂的需求，其次才取决于设计者的能力。

2. 只要你用的是关系数据库，就必须要明白，为什么叫关系数据库，而不叫面向对象数据库，把面向对象的那些观点，拿到库表设计上，后期维护和调优上，你要担起责任，不能让开发人员替早期决策人员擦屁股。我见过有的人，打着OO和扩展性的旗号，硬生生的把一个表，拆成了三个表，而这三个表，本来，只需要增加一个类型字段，再做一些冗余，就可以是一个表。现在查询时，还要把这三个表Union到一块来查。当需求变更时，增加一个字段，不仅要改变三个类，还要改变三个表，简直是乱伦。

3.One-One的库表设计，对于DBA来讲，并不是一个best practice的设计。不能为了Hibernate，刻意把大表拆成小表，再用几个小类，做成One-One的映射关系。整体性，是不能随便的分割，毕竟开发人在调试、测试和维护的时候，更喜欢看数据库里的数据，本来一个SQL，就查出来，现在要到多个表中去查。

4. 增删改存的实体维护
Ibatis比不上Hibernate，说实在话，现在让我写SQL来维护一个多对多关系的实体维护，我都要考虑上半天，别说写代码了。

5. 你需要写原生SQL吗
首先你要确认，你项目的要求不需要写原生SQL，再来讲Ibatis和Hibernate的好坏，在写原生SQL上，特别是动态生成的SQL，ibatis比Hiberante有得一拼，ibatis就像一个模板一样，将SQL写在配置文件当中，集中配置，特别方便技术领导者监控项目成员写的SQL好坏，而且没有什么学习曲线，就写SQL就完事了。

有人会说，Hibernate也支持写SQL，但是写代码当中，就失去了原来基于Hibernate的DAO的简洁性。那个DAO一点也不简洁，如果你将动态拼SQL的代码也放在DAO当中，那个DAO就会充斥大量的If 。。Else。。之类的语句，一坨一坨的，非常的壮观。

还有人会说，Hibernate也支持命名查询，将SQL写在映射文件当中，但是命名查询，只支持占位符固定的情况，也就是说，where a = ? and b = ? and c=?，是三个问号，就是三个问号，传参时，少一个都不行。但是很多项目的查询，都是动态的，也就是说用户选了这个查询条件，才会生成这个占位符的。

Hibernate办不到。

还有人会说，我自己用Hibernate写一个框架，也可以做到，那你写的可能比Ibatis好，也可能差，你要造轮子，谁来拦不着。

5. 调优
早期调优，有些Bad SQL，其实在code review阶段，只要看看Ibatis的SQL配置文件，就可以扼杀掉的，如果使用HSQL，可能不会被发现，因为它不仅隐藏在代码当中，有的时候，还需要程序跑起来，通过日志打印出SQL或者通过其它工具如P6Spy来看的出来。

后期调优，既然是调优，我想就一定是遇到了瓶颈，可能要在库表上做冗余，可能要检查那些Bad SQL，可能要修改代码，可能要动用DBA层次上的一些调优手段，那么调优越深入，Ibatis的优势就越能体现出来，比如说增加临时表，中间表，增加冗余字段等。

    6. 开发速度

       如果项目当中，没有一个Hibernate高手，你的项目又相对的复杂，不仅有复杂的库表关系，还有大量的报表查询，那么使用Hibernate，速度上逊于Ibatis.

问题在于，怎么样算是一个Hibernate高手，别看论坛上，那么多人，群情激奋的在说Hibernate的好，有谁真的是高手？

我认识一个人，连Hibernate的命名查询、悲观锁、乐观锁之类的，都不清楚，还在那说：“说Hibernate不好的人，只是他不会用Hibernate，高手使用EJB也一样用的很顺溜“，我这辈子，最最讨厌的就的这样的人，人家明明用Spring很简单，很快乐，为什么要用EJB，充高手。换过来，项目使用Ibatis来做动态查询，很快的就解决问题了，为什么要去学Hibernate里面高深的东东，是不是这样就是高手了？

7. 平台移植性
如果你的项目要做产品，而且打算基于多个数据库平台的发布，使用Hiberante是没有说了。

8. 维护性
如果不考虑移植性，Ibatis的可维护不差于Hibernate，库表变动引起实体类变动时，HSQL也会有改动，有人说不用改，说这话的那个人可能整天只会有select * ，如果ibatis也是这样写，也不用动了。

HSQL好阅读吗，From order，确实很简单，但实际当中，这跟拿HelloWord做例子，有什么区别？

    9. 我在实际项目当中的运用
    项目背景：
       我自己从Hibernate2开始使用，我现在也不认为我是Hibernate高手，我也没有时间去钻研Hibernate，更深的东西，我也不喜欢坐在开发人员旁边老半天，去帮他们解决Hibernate遇到的问题，因为我自己还有很多事要做。

我的项目当中，在Hibernate方面，还有一个比我更强的人，他也很烦去看Hibernate打印出来的sql，看上老半天，再调上老半天，项目进度，嗖嗖的过去了。

水平越高的人，任务越重，很少有时间和耐心去解决一般性的问题。

最终的运用：

       在基于Spring的容器事务管理之下，
       增、删、改、存及在事务中的查询，使用Hibernate。
       非事务性的查询及报表，都用Ibatis，维护非常的直观方便，开发速度上也快很多。

我觉得现在技术换代很快，使用一项技术，首先是要快速的解决问题，然后要学习他的思想，那些整天死抱着Hibernate，自认为学习到ORM的设计技巧的人，就去继续的学吧。

我已经会用Hibernate的一些方面，我觉得够用就行了，犯不上，天天钻研HSQL，如果有时间，我觉得躺在草坪上看看Unix的编程艺术，看看代码大全，看看Oracle的编程艺术，比看Hibernate的SB书要惬意多了。

简单能够带来快乐，用过EJB，再用Spring的人，都有体会，那简直是一种思想上的重生。

Ibatis的设计者认为，在新的项目当中，可以使用Hibernate，在旧的遗留项目当中，可以使用Ibatis，不明白，他为什么说这样的话，这与新旧项目有什么区别？新的项目就真的可以使用Hibernate吗。

Speed 2007-05-05 18:14 发表评论

如何用代码推动设计

Speed — Sat, 05 May 2007 16:29:00 +0800

计算机专业毕业的学生在学校当中，都读过软件工程这本书，而软件工程的书，都无一例外的，强行规定了一个编码阶段，并且十分严肃的告诉学生，代码在整个软件过程的生命周期阶段当中，只占了1/5左右。需求分析和设计、项目管理，更强于代码。我想对这于刚毕业的学生，是一种思想上的毒害，很多人刚毕业一两年，都耐不住性子，哭着喊着，要做architect，要做PM。

我认为回避代码是可耻的，只要编码有意义，我们在任何阶段，都应当投入到编码当中。

最近一个项目，我下面有两个设计人员（GM派过来的），协助我做设计，我做了一个设计的骨架，然后交给他们去迭代细化。下班前，我去看看他们的工作只有一些空洞的UML图和一个还没有写内容的概要设计模板，我对他们说，不要求你们去写文档，我也没有时间去看，我不知道你们以前，是怎么做这设计的，但在我这个组，这样做，不行。做为设计者，首先是自己要理解要做的东西，并且真正知道怎么去设计它才能满足涉众需求，第二步，才是让别人能够理解你的设计。怎么样让别人理解你的设计，文档并不是唯一的途径，对于普通程度员来讲，白板上的讲解和直白的代码注释甚至比UML图更容易理解和平易近人，我们很多的设计者，总是喜欢用大量的4＋1 UML图和文档中生硬、冰冷的词汇来吓唬程序员，恰恰反映出了设计者内心的空虚与胆怯。

以往自身的设计经历，谈一下：
我第一次给另一个组做一个子模块的设计时，心里很紧张，因为我不在他们那个组中，也不参与他们的开发，这个设计对于他们的项目进度来说，又是一个关键路径，我生怕我自己设计的不好，考虑问题考虑的不周到，在项目后期，如果出现问题，自己责任重大。

我对他们说，这个设计需要两个星期，其实我只化了三天，就把接口文档写好了，我对着接口考虑来考虑去，还是觉得没有底，我忍不住想写代码，来验证这样做对不对，又怕别人说我的设计能力不强。我就偷偷摸摸的写代码，又和他们的组的主要使用者反复沟通了几次，根据需求，设计了几种不同的案例，来验证我的设计是否有漏洞。

最后，又对接口修复了几次，觉得接口相对稳定和健壮了，就让他们过来看看，提出问题，结果也没有提出什么问题。于是我就交工了。

实事上，这个接口，在开发后期，还是有一点修改，但并没有给他们的项目造成很大的影响，他们自己也认为能考虑的这么全面，已经不易。
做开发这么多年，越来越觉得设计是一个很复杂的东东，他不像建筑工程中的设计一样，可以用工程化的方法去中规中矩的验证，并交给工人进行构造。但如果没有好的验证方法，一个设计就交工了，大家都没底。就好像选择是狮子还是公主，只有把门打开才能知道。

这几年，我经历的每个项目，几乎都有评审，需求评审，设计评审等等，但我现在回想过来，我想不出对我的项目有太多的意义，很多人痴迷于通过文档和评审来试图证明设计是正确的，而通过评审，对于PM和Architect，似乎也被当做是一个项目当中非常重大的milestone，直到现在，我的上级和我的同事，似乎从未改变。而我的自己观点的表白在OP会上，迎来的是批判。

我认为文档必须要有，总体的架构设计和模块的详细设计，都是需要的，但是设计者，往往忘记了，文档只是设计者自己对已经构思好的设计的一种反映，这种反映只是让别人去分析、理解、修正、接受并按照它来进行开发的一个工具，它绝对不是一个证明自己完成一个良好设计的方法。

编码、测试、调试、交付用户UAT，都应当视为是设计的过程，也应当是验证设计是否正确的最好的办法。

尽早的进入代码开发，是敏捷开发中一个很重要的标志，所谓的标志，我认为如果在项目前期的前一两个月，你仍然徘徊在需求分析、文档编写的工作当中，而没有代码产生，你绝对不是敏捷。这个观点是我自己加的，我很难容忍，我的设计、分析人员天天在写文档，开发人员在心猿意马的看长遍大论的需求和设计文档。
一句话，越早进入开发，我就越主动。

   我验证设计的一些方法：
   1.根据以往的设计经验，做一些check list.
   2.写代码，做demo。做Demo是我非常喜欢的一个方法，一个可以运行的Demo，远胜过文档了。开发人员一看，直接copy、paste就完了。做汽车、计算机等新产品，都会有样机，对样机做大量的试验后，才能上线，大批量的生产，在软件当中，怎么一做完设计，就大规模的进行开发了呢。
   3.做测试案例，TDD是一种方法，有长期开发经验的人很容易吸收的思想，并且愿意在重要的地方使用，来理顺和验证自己思路。
   4.对于设计的涉众人员，能够尽早的看到，并充分的沟通，不要把文档写完了，才交给他们，那是一种思想上的强暴。很多时候，在领导的安排下，设计人员与开发人员，在能力上，并差不了多少。所以设计人员要虚心，并且要有责任心。

   好的设计应当交付什么：
   1. 有简洁注释的代码
   2. TestCase
   3. Demo
   4. 模型
   5. 文档

Speed 2007-05-05 16:29 发表评论

什么算是大型项目经验（一)

Speed — Sat, 21 Apr 2007 14:57:00 +0800

     说老实话，我都不知道什么算是大型项目经验，我也不知道，那些所谓要求有大型项目经验的公司，在做多大的项目，有多NB，但我并不以做过大项目为荣，我这几年的项目经验告诉我，团队不在于大，在于精，我经历过20人的团队，也有60人的团队，我觉得这样的项目要做好以下的几点：
     1.项目团队构建前，组织架构要精细考量
       各个关键角色的能力有与角色职责相适应，越向上，能力要足够的全面，要足够的强势，这样才能层层推动。
       上至CTO，GM，下至PM，DBA，TM，要能够撑得住，靠一个NB的PM，是绝对撑不住的，俺经历过一个60人的项目，4个PM，一个GM，一个GM assistant，结果是GM，天天躲在自己的办公室里，发email, 以为自己是船长，吹个口哨，大家都齐心协力的向前划了，结果是今天向东，明天向西，每次开会，乱成一团，一帮SB PM，满口单元测试，闭口敏捷，开口迭代，谁也不服气谁。
     2. 避免跟着感觉走，
        其实国内很多软件公司都一样，越向上的领导，技术层面越来越薄弱，即使一些曾经是大N的技术人员走上了CTO的岗位，但也会逐渐丧失掉技术的敏感度，很多PM都很少写程序，何况CTO、GM？估计每天的时间都浪费在回复邮件，开会，评审，会客之类的所谓的很虚的管理之上。
       这样造成的结果，就是掌控力度，其实是越来越弱，在用人，更是做不到知人善任，对于不懂技术的上领导来说，一头猪和一个高手，是没有什么区别的，只能跟着感觉走，对下边的一些人会特别的依赖，当下面的PM发生争论时，也搞球不清楚，那个SB说的对，那个SB越的有道理。
       但做人要对得起良心，作为一线的PM，要相对虚心，自己没有经验的，从书上学来的，不要轻易乱用，不要拿别人当实验品，更不能现学现卖，欺骗不懂技术的上领导，有的时候，也是没有办法，会叫的孩子有奶吃，也要讲究策略。

     3. 沟通与协作
        作为PM向上的领导，有的时候，你感觉自己好像都在天天开会，但有的会，就开的很好，起到了事半功倍的效果，有的会，就开的很糟糕，不仅得罪人，还吃力不讨好，在沟通与协作能力方面，作为稍大的项目以上，PM是必须要把握尺寸的，我见很多嚣张的PM，说话节奏快，语气比较强势，经常批评其它的PM,结果在OP会上，很容易遭到攻击，大家的级别和能力都差不多，谁也不会卖你的账，更不会给你帮助和施以援手了。有的PM就比较圆滑，在会上很少发言，听的比较多，经常说的话就是：是的，对，OK，没问题，尽量吧，等等话语，这样的PM就很少被攻击，也更容易得到帮助。

其实，大家经常解释时说的一句话："我也是就事论事"，但在OP这样比较高层面的会上，还是尽量不要这样搞，就事论事，可以在下面一对一的搞，不要动不动都拿到OP会上搞，得不到别人的协作，要尽量的沟通，不能动不动，就上报给CTO之类的领导，这样会更糟糕。因为CTO可能会不能罩你一辈子。也并不是每个CTO都是清明的领导。

email有email的用处，但它不是command, 也不是communication, 从你的坐位上站起来，在公司内走一走，要比一个email强万倍。

     4.架构师

        架构设计是个很复杂的东东，但如何选择合适的架构师，如何进行最终的决策，很多公司做的并不好，很多领导在架构师的任命上，很容易草率，说你行，你就行，说你不行，你就不行。于是一些不负责的、半桶水的人，就在领导的指示下，走上前台，将项目推向死亡之谷。

架构的设计依赖你全生命周期项目经验的积累，格局要大，依赖于你对技术的敏感度，技术上比较全面，就像参谋长一样，从军校毕业的，就容易纸上谈兵，比较激进，从士兵，一路杀过来的，就比较慎重，但如果不爱学习上进，则又属于野路子，做又不究其理，不善于抽象，不讲究方法论。

总之，在这点上，能找一个NB的，又有理性的，不太容易。

     5. 文档

         项目组与项目组之间，项目组与客户，项目组与测试部门，项目组与评审组之间的交互，有很重要的部分就是文档。

文档这个东东，说实在话，就是一个鸡肋，但不要又不行，客户要签字，领导要评审，测试组要拿它写测试用例，但对于项目组来说，天天在那咬文嚼字的，实在是没有意义的，俺在原型分析与用例驱动上探索了很长时间，虽然用例直接了当，且很容易转化成功能书、测试用例，但工作量，比之传统的需求文档说明书，有过之而无不及，在时间紧的时候，也很难保持实时一致。

我目前的做法是原型必须与客户的需求保持一致，基于静态页面的原型，修改起来，速度很快，且更容易被客户、程度员、设计者所接收，长篇大论，动不动上百页的需求文档，你喊破喉咙，也没有人看。

文档，有专人写，专人维护，但会比较滞后，只要能够保证在提交测试部门时，有一份完整的文档，这样测试部门，也更方便测试。培训的时间也少。

在评审时，可以评审，但具体文档要拖一拖了。

客户签字，就以原型为主了。文档，它也不看。如果动真格，要看，那就抽时间赶出来。

当然对于接口等技术文档，还是必须要的。

         (未完待续)

Speed 2007-04-21 14:57 发表评论

由ibatis引起的框架设计思考

Speed — Fri, 13 Apr 2007 19:09:00 +0800

以前，不熟悉Ibatis的时候，自己写了一个类似Ibatis的查询分页框架，SQL配置在XML文件当中，提供脚本语法的功能。

    后来，觉得Ibatis完全能替代自己的框架，还有Cache、Transaction等强功能。

   但是跟踪到源码才发现Ibatis完成是基于内存分页的，而且方法已经Depreciated. 内存分页对我的应用来说，是一点不实用的，其实就是一个废物。

   但是Ibatis又不提供任何的回调接口，可以让调用者扩展。

   于是我不得不重新修改了Ibatis的源码，向外部透出了一个回调接口，供分页SQL使用，并重新打包成jar文件让开发人员使用。

    这真是不爽之极，为什么Ibatis不能提供，这么强大的框架都做出来了，但这个小小的分页，却做不了，如果你做不了，其码也要透一个接口给我呀。

    所以对于框架来说，职责的分担，是很重要的，完成你该完成的，该扩展的地方，即要提供默认实现，也要提供接口，供调用者二次开发。这才是框架的可扩展性、灵活性所在。
    很多人在开发框架时，总期望做很多东东，自己给自己加套，反而丧失的灵活性，同时提供了很多不能扩展的实现，等于强加意志给使用者，爱用不用。

    相信很多人在用Ibatis的时候，也有同感，对于数据库分页查询，应当是非常重用，非常普遍的一个功能，Ibatis竟然做的是如此的差，一些人在使用Ibatis的时候，不得不写了两套SQL，一个查询总行数的，一个是查询某一页的SQL。实际上，ibatis完全可以根据一个SQL来生成这两个SQL，并自动分页。

Speed 2007-04-13 19:09 发表评论

谁来买单

Speed — Sun, 20 Aug 2006 19:52:00 +0800

摘要: 公司的发展出现了问题，不应当让技术人员来买单，而是我们的管理团队，是公司的上层建筑出现了问题，当领导的应当自己积极的反省，即使可以凭借权力让下面无辜的人来买单，那又怎么样，当公司over的时候，大家不都是一样over，总有一天，报应会来的，终有一天，领导要为自己的决策失误来买单。阅读全文

Speed 2006-08-20 19:52 发表评论

又一次被干

Speed — Tue, 08 Aug 2006 01:12:00 +0800

　星期四是约定去面试的日子，二面了，觉得还是有希望的，对方是台湾的一家公司，从网页上看，还算是跨国公司，规模也算比较大，做呼叫中心的。
　　下了公交车，到写字楼虽然有二百多米，却是寸步难行，风刮的伞都打不开，雨水顺着裤腿全都灌到皮鞋里，整个裤子下半部分全都湿了。
　　总算没有迟到，本人的时间观念很重，到了对方的公司里，一个负责技术的接待了我，因为一面已经谈过了，彼此寒暄了几下，他拿出两页纸给我让我做，我一看，是一个业务单据的审批处理，流程还是相对复杂的，有跳转、退回、收回、分流、同步等操作。让我做DB模型和应用模块设计。
　　我心里想我是来应聘PM的，让我做程序甚至，与PM一点关系也没有，至少要有几道项目管理的问答题作一个陪衬吧，虽然很疑惑，但也没有问，他说不限定时间，计算机上装的是eclipse，写好了叫他，就走了。
　　我对工作流，以前做过几个项目，还算熟悉，我就努力的让自己的大脑兴奋起来，花了将近两个半小时，把工作流引擎的全套接口，包括供业务层扩展回调接口，如触发器、验证器、脚本扩展接口等，全部写出来，同时写了一个XML配置文件来配置考题上的各种流程流转，并用Webwork写了一个Action和单据实体作为Demo来演示整套接口的调用。
　　由于快下班了，那个破计算机鼠标一点也不灵敏，也没有装五笔，我就没有太多的注释，太累了，就直接叫考官进来了。

　　面试考官来了以后，故做认真的看了看，并让我讲了讲整个思路，讲完后，突然问我，你能不能不用工作流的思路，来写这个案例，我说那很简单，如果不用工作流，流程数据就要保存在业务层中或与业务层紧密的耦合在一起，流程的跳转就要写死，但这样做很难去适应业务流程的变化与功能扩展需求。如果不想写死，就得走可配置的道路，同样也必然回归到工作流思想上。
　　他反问我，但那样做，是不是更快一点，性能上要好点呢，我说，工作流引擎的开发上可能会花点时间，但如果一旦开发完成或者采用第三方包的话，那么业务层的开发将会非常的快，通过简单的配置和表单定义及描述层的开发，就会很快的完成工作。
　　他却说你这套代码写的很好，但如果技术水平不高的程序员，他们没有工作流思想, 看到我写的这些代码，会看不懂。而如果使用常规的做法，不使用工作流，那些人就能很快的接受并能很快实现这个需求。
　　我当时很恼火，但仍然耐着性子说，如果从单纯从实现速度上，确实要很快，但后面维护的代价是很沉重的，而我基于工作流的设计，根本不需要他们看懂，工作流引擎对于他们就是一个黑匣子，完全通过灵活的配置和接口调用来完成工作，为什么一定要看内部的代码实现呢，再说即使没有工作流思想，通过简单的培训，相信也可以使用的。我心里想，为什么要招这么蠢的程序员呢？
　　但他仍然很固执的说服我，我也不想再纠缠下去，就同意了他的看法，心里已打定注意了。谁知那个SB竟然对我说，你回去后，按我刚才的说法再完整的写一份的设计发给我，我听了这句话，心里真有点怀疑，他是不是在诈骗，让我免费替他写程序。
　　我口头答应下来，然后头也不回的走了，由于走的快，鞋子里的水与脚摩擦，发出噗嗤噗嗤的声音，很是狼狈，前台小姐捂着嘴偷笑。
　　闷了４个小时，出了写字楼，有点头晕目眩的感觉，心情很不好，为什么那些SB，啥球都不懂，还能拿着９k，１０k的工资，能够耀武扬威的、随意践踏你的尊严。自己却是这么的累，每天不断的学习，不断的鼓励自己要踏实上进，回报却是这么的不公平。

　　我这一生经历过的比较厌恶的面试经历：
　　1、给一张破纸，让写一个算法，草纸都没有（就像让人蹲在光滑干洁的地板上拉屎一样，巨痛苦）
    2、让写足足有四张的个人信息登记表，里面还要写家庭关系。就像唐僧问山妖，你妈贵姓？
　　3、排队面试，在会议室里，等了有４０多分钟
    4、做SUN公司Java程序员认证的考题，里面还有SWING，AWT，Applet之类的题目
　　5、与一个考官讨论接口与抽象类的差别，争论了一个下午，巨傻
        6、每次都被问为什么离职
        7、进度控制和需求分析，都是很有挑战性的，但问的多了，也就想吐了。
       8、做名词解释题，SCM，TDD，XP，这些都见过，还好说，竟然有SWAT，有点过份，也算说的过去，还有一些至今都GOOGLE不到的缩写，因为不会，现在都忘记了。不明白人为什么要耍酷，装什么装，谁不知道谁呀。
　　9、经过三面、四面后，音讯全无
　　

　　这几天太累了，不想再出去找工作了，努力让自己的心态平稳下来，时间是最宝贵的，不能再东奔西跑的了，以后再有面试的邀请，不再刻意的去准备了，爱咋咋地，同时一定要讲明：
　　不再盲目的屁颠屁颠的去面试了，要求对方先有同技术负责人的一个电话面试，在电话中讲明自己的缺点或者弱点及长处，如对方说要熟悉JMS，而自己就没有做JMS的项目，但对于底层的TCPIP协议通信，还是很了解的，SOCKET通信更是不在话下，相信对于JMS，应当很容易掌握。
　　

Speed 2006-08-08 01:12 发表评论

List集合随机排序算法分析

Speed — Mon, 31 Jul 2006 18:25:00 +0800

List集合随机排序算法分析

先说一下JDK 对List的随机排序的实现：

public static void shuffle(List list, Random rnd) {　　　　
　　final int SHUFFLE_THRESHOLD = 5;　　//这应当是一个经验值吧

        int size = list.size();
　　/** 为什么要判断，后面有论述 */
        if (size < SHUFFLE_THRESHOLD || list instanceof RandomAccess) {
            for (int i=size; i>1; i--)
                swap(list, i-1, rnd.nextInt(i));  //这一种方法是直接调用List.set方法，属于RandomAccess中的方法
        } else {
            Object arr[] = list.toArray();

            // Shuffle array
            for (int i=size; i>1; i--)
                swap(arr, i-1, rnd.nextInt(i));

            // Dump array back into list
            ListIterator it = list.listIterator();      //如果不是Random Access实现，就使用迭代器遍历
            for (int i=0; i<arr.length; i++) {
                it.next();
                it.set(arr[i]);
            }
        }
    }

再说一下我自己的笨拙实现：
　　public static List randomSortList(List ls, Random random) {
                List randomList = new ArrayList();
                int size = list.size();
               while (size > 0) {
                  int randomNum = random.nextInt(size);
                  randomList.add(ls.get(randomNum));
                  ls.remove(randomNum); //这一步，对于RandomAccess的集合来说，是O(1)操作
              }
               return randomList;
     }
评述：
　　如果List的实现是ArrayList，在时间效率上要多循环一次，但在空间上，我的方法非常差，多生成一个List集合，如果List很大，就更差了。同时我的算法如果用于Sequence List上，效率是相当的差，只能适合ArrayList,有很大的局限性。
　　这是因为：如果集合类是RandomAccess的实现，则尽量用for(int i = 0; i < size; i++) 来遍历而不要用Iterator迭代器来遍历，在效率上要差一些。反过来，如果List是Sequence List，则最好用迭代器来进行迭代。
　　JDK中说的很清楚，在对List特别是Huge size的List的遍历算法中，要尽量来判断是属于RandomAccess(如ArrayList)还是Sequence List (如LinkedList），因为适合RandomAccess List的遍历算法，用在Sequence List上就差别很大，常用的作法就是：
    要作一个判断：
    if (list instance of RandomAccess) {
        for(int m = 0; m < list.size(); m++){}
    }else{
        Iterator iter = list.iterator();
        while(iter.hasNext()){}
    }
   我的项目中List都是基于ArrayList的，所以基本上很少用迭代器来遍历，而是用for循环来遍历，对于迭代器的作用我当然很清楚，但是我觉得有点庸人自扰了。
   除非你经常用Collection作为你的接口方法中的输入或输出的集合参数类型时，你也就只能用Iterator。
   但我一般在接口方法中，一般用List，所以我就不用迭代器，除非我的List是Linked List实例。
   好的作法是：在供外部调用的接口方法中，使用Collection作为集合参数类型，在内部实现当中，使用List，而不是一味的使用Collections及Iterator，这样做无异于作茧自缚。
   顺便说一下JDK中推荐的是对List集合尽量要实现RandomAccess接口。

Speed 2006-07-31 18:25 发表评论

CA与电子支付

Speed — Sat, 03 Jun 2006 23:33:00 +0800

摘要: 在电子支付的安全环节中，CA认证是必须要了解的技术阅读全文

Speed 2006-06-03 23:33 发表评论

金融系统的前置平台

Speed — Sat, 03 Jun 2006 23:26:00 +0800

摘要: 随着企业竞争日渐激烈，各商业银行业在扩展金融服务产品、服务渠道方面更是争先恐后，但目前银行系统存在的主要问题在于外围前置机较多，部分业务流程复杂，系统交叉联系，业务扩展时需改动的外围系统较多，导致业务扩展较为困难。为了减少主机进行路由服务，减轻主机的压力，使核心业务系统成为简单而稳定的核心。同时为了满足金融行业快速的电子化建设需要一个高度集成、高可配置的开发和运行框架，既是一个高效、方便的开发环境，也是一个稳定、可靠的运行环境。通过配置化的管理，实现渠道接入整合，业务流程的优化，数据分布的合理布局阅读全文

Speed 2006-06-03 23:26 发表评论

SET协议与SSL协议的比较

Speed — Sat, 03 Jun 2006 23:23:00 +0800

摘要: 电子商务发展的核心问题是交易的安全性问题，这也是企业应用电子商务最担心的问题，因此如何在开放的公用网上构筑安全的交易模式，一直是人们研究的热点和大家关注的话题，要构筑一个安全的电子交易模式，应满足以下五个方面，这也是OSI规定的五种标准的安全服务阅读全文

Speed 2006-06-03 23:23 发表评论

风雨飘摇

Speed — Sat, 03 Jun 2006 23:04:00 +0800

公司正在同VC谈判，即将获得资金投入的时候，由于突发事件，原来光明的前景突然暗淡下来，，只有高层和我知道事件的缘由，一般的管理人员和技术人员都一无所知，仍然正常的上下班，正常的做事，不知道现在公司的命运正处于风雨飘摇之中，前途极为凶险。
　　这几天，老板处于极度的烦躁之中，平常极为强势的他，现在频频招开会议，希望能够从我们这些无能的下属中找到一些帮助和建议，我只能用加班来表示我仍然是坚定的与公司同在的，但是自己也是一片慌乱。想到为之奋斗几年而打造的产品，由于核心资源掌握在别人的手里，而即将被别人掐断源头的时候，自己也是即愤怒而无奈。
　　晚上我还是努力的强压住心头的慌乱，做好了主分站的部署，认真的做好测试，搞技术的我，只能做好自己的本职工作了，别的想的多也没有用处，随命吧。

Speed 2006-06-03 23:04 发表评论

EcommerceAll

从Jquery Grid 谈前端框架设计

项目管理之能不能不要再说完成了90%？

纸糊的架构设计

为什么要使用JBoss Drools

从用户的角度看待BA

多背一公斤

不要被牛粪糊住双眼

struts 2依然坚挺 Seam前景不明

Think in Jquery

成熟的架构+创新的扩展

I don't want to say.

电子商务网站的可持续发展

好事要做到底，我们需要full stack的API设计

业务平台的真的存在吗

精心打造Team的组织架构

应用层缓存 VS ORM缓存

Ibatis VS Hibernate

如何用代码推动设计

什么算是大型项目经验（一)

由ibatis引起的框架设计思考

谁来买单

又一次被干

List集合随机排序算法分析

CA与电子支付

金融系统的前置平台

SET协议与SSL协议的比较

风雨飘摇

应用层缓存　VS　ORM缓存