电子商务网站的可持续发展
2007年终于过去了，从焦油坑里爬出来幸存的人们，互相握手庆幸，喜极而泣，纷纷在博客上写工作总结与来年展望，而我终于厌倦了期权的精神鸦片，难得的坐下来，远离自己负责的网站，想一想来年的布局。
在国家大力宣扬环保，可持续发展的时候，从企业，从网站，就我个人，都要讲一个可持续发展，一夜暴富的思想只会浪费精力，没有方向，而只有平时注重积累，厚积薄发，终会有从量变到质变，扭转局面的时候。
我们发力在向前奔跑的时 ...
full-stack 的设计，意味着各层能够无缝的集成在一起，遵循的DRY原则（don't repeat yourself)，将各层共用的东西，抽取出来，并通过自顶向下的设计，无缝的集成在一起，粘合在一起，达到更高层次、更粗粒度的重用，同时为了保证灵活的可扩展性，在更高、更粗的粒度上遵守开放-封闭的原则，在各层的各个关键点，要提供诸多的钩子，回调的接口，供使用者扩展。full-stack的设计，在层与层之间，并不一味的追求松散的机制，而是相反，在层与层之间增强一定的内聚性，粘合力，以此来达到粗粒度的封装与重用。 可以说full-stack 的设计，其爆发出的威力是巨大的，相对普通的 ...
相信凡是开发者对用户纷繁复杂的需求，都趋之如虎，从制度上，我们建立了严格的需求变更的process, 从技术上，我们寻求一种所谓的业务平台，寻找一个冶百病的良药，在市场上，有商业软件来推销自己的平台，更在平台上加一个业务两字，真有这种平台吗。
关键是我们要对“业务平台”这个词语都没有一个定义，这是个伪明题。
像那些平台软件，反复所说的，UI组件之类，这些是业务吗，是与业务无关的东西剥离出来的一种框架解决方案而已，更不能说是平台中的特色吧。
就是工作流引擎，也是为了将流程定制、跳转与业务逻辑剥离出来的一种设计思想的实施。
表单定制更不是业务，也是与业务剥离的一种方式。
而在现实开发当中 ...
看了infoq中文站的那篇敏捷之文，又顺藤摸瓜，找到了太极掌门人的网站，作为一个旁观者，仿佛看到两个下盲棋的高人，飘在空中，一个说“炮五平六”，一个说“马8进7”，杀的好不激烈，另有一群评棋之人，或指点，或赞同，或反对，好不热闹。
回到JavaEye,却更觉得这是块净地，务实求进，Pragmatic, 是我看到的JavaEye的风格之一。更觉可贵，也更希望保持下去。看到很多追求卓越的人努力的改进自己所在项目的软件过程，虽处在强大的官僚机器之下，力量弱小，却又像一群拓疆之士，在大雪迷漫当中，互相扶拥，奋力前进，自己身处于其中，似乎更加亲切。
软件开发本来就是一种抽象的过程，将现实世界的连续的 ...
长期以来，由于IBM等大的厂商，声嘶力竭、不遗余力的宣传，SOA开始在江湖盛传，但掌握着是否实施SOA的权力，掌握在高层的领导手中，而IBM的Sales，则将天花乱坠的Solution，很容易的输入到领导的大脑当中，SOA成为无所不能的利器，而领导对于实施SOA，来改变当前混乱的局面，寄于很高的期望。
而无论是在IBM、BEA、Oracle等大牌厂商，还是Mule等开源方案，都没有真正的案例，来提供很好的异构系统通信的解决方案，而这正是很多大公司长期以来，所希望解决问题。
最近在做一个公司的一个信息集成的工作，由于客户在长期信息化的过程当中，积累了多个IT遗留系统，在工作开始，客户 ...
精心打造Team的组织架构
长期以来，很多Team的组合都是随意的，从创建到稳定, 不经意之间，一个Team就出世了，在项目进行当中，弊端尽现的时候，也没有人注意到是团队的组织架构，人员搭配是否出现了问题，Team成长过程，就好像一个树籽落在地下，然后自生自灭，有的长成了歪脖子，有的则树倒猢狲散，有一部分，运气好，成为能经风雨的大树。
几年来，虽然敏捷管理与开发，深入一些经验丰富的PM和开发人员之心，但是在推广时，却南桔北枳，没有了味道，
一些优秀的开发与设计思想或技术，如TDD、MDD，大部分只流转于个别经验丰富的开发人员之间，在团队项目开发中，不见了踪影。
...
最近做一个比较大的电子商务项目，预计每天订单量将在５万多单，客服人员需要频繁的下单、查询订单、操作订单，客人预订完订单后，会立即进入处理流程，为了提高服务质量，要求流水化作业，平均要在４０分钟－８０分钟内处理完订单，对于疑难订单要到第二天，才能处理完。所以订单在创建后，会在短时间内，被频繁的修改和查看。
由于在项目中ORM层主要是基于Hibernate框架，所以在调优时，很自然的就想到打开Hibernate的二级缓存，以次来减小由于Load 订单大对象时N+1次查询给数据造成的压力，自己做的测试效果也非常好，也顺利通过压力测试。
但在上线时，性能却并不佳，经过分析业 ...
近日，上论坛中，看了Ibatis和Hibernate的帖子，看后，心里觉得的憋闷，不说不快, 其实Robbin之前有一个帖子，都说过了，但在这里，我想更细化一下：
1. 库表关系的复杂度，首先取决于需求，不取决于设计，设计能力强的人，也要遵守库表设计的规范，从巴克斯三个范式上，原则上也要遵守。不能说用了Hibernate,自己的库表设计能力就强了。不能为了用Hibernate，就去一味批判复杂的关系不对。复杂的关系设计对不对，首先取决于是否有复杂的需求，其次才取决于设计者的能力。
& ...
计算机专业毕业的学生在学校当中，都读过软件工程这本书，而软件工程的书，都无一例外的，强行规定了一个编码阶段，并且十分严肃的告诉学生，代码在整个软件过程的生命周期阶段当中，只占了1/5左右。需求分析和设计、项目管理，更强于代码。我想对这于刚毕业的学生，是一种思想上的毒害，很多人刚毕业一两年，都耐不住性子，哭着喊着，要做architect，要做PM。
我认为回避代码是可耻的，只要编码显的有意义，我们在任何阶段，都应当投入到编码当中。
最近一个项目，我下面有两个设计人员（GM派过来的），协助我做设计 ...
近来为客户新做一个电子商务网站，部门经理天天给我说要把群集做进方案里，听的都吐了，在没有对于用户服务需求真正在进行好认真的分析的前提下，就将群集做进方案里，真的觉得很厌烦。
我觉得即使对于中型的电子商务网站，也不一定需要群集，群集只会增加复杂度，甚至有可能延长用户请求的响应时间。同时限制Web应用的开发方案，如对于重型的基于SessionWeb-Flow方案，你就要考虑不能使用了。但对于电子商务网站，web-flow的应用很多，想像一个网站下单的过程，-查询－预订－登陆－填写需求-填写配送单－信用卡担保（或网上支付)-生成订单。使用wegbflow框架很方便，但在群集环境下， ...
OneEyeWolf
- 浏览: 81410 次
- 性别:
- 来自: 深圳
- 详细资料
搜索本博客
我的相册
共 3 张
最近加入圈子
最新评论
-
电子商务网站的可持续发展
好经常的评论，虽然我不是做电子商务的，但在公司也是做开发，职位也不高，提过很多相 ...
-- by xiaofengtoo -
电子商务网站的可持续发展
随着业务的发展，有很多的合作型的项目，子系统越来越多，同时要外接的系统越来越多， ...
-- by linyajun -
电子商务网站的可持续发展
和我的处境差不多，最主要的原因是我们都是建议者而不是决策者，或者是某些范围内的决 ...
-- by gurudk -
电子商务网站的可持续发展
刚刚看你的这篇文章，写的非常好，对项目管理中的一些细节问题描述的非常好，提出的意 ...
-- by wangshare -
电子商务网站的可持续发展
引用只是在自己承担一个任务时，才会去看那些相关的代码，这样就会时间太紧了，手忙脚 ...
-- by 咖啡舞者
评论排行榜