框架设计
提供framework design guideline.
摘要: 框架毕竟是框架，没有最完美的，只有相对合适的，使用者需要分析知道自己的问题在那里，然后去设计开发、使用合适第三方的框架，或直接使用、或二次封装、开发、修改源代码，来解决自己的问题，总之，不要做一个问题的抱怨者，等着别人煮米下锅。
阅读全文
摘要: 最近，负责客户的一个项目设计的审计工作，是一个短信平台的项目，上行和下行通信都有，之所以叫平台，是想将客户的很多的业务系统，涉及到短信的部分都统一挂接到者一个服务平台当中，只要一家服务提供商，量大从优，避免各自为战，浪费资源。业务系统多是遗留系统，当中对短信需求各不一样，客户从自己的vendor List中找了一个短信服务提供商（SP）。一般的要是能进入vendor list中，说明实力还是有的。
阅读全文
摘要: 对于business rule, 一般的情况是， 好的BA，可能更善于发现、抽取business rule ，并用结构化的方式描述、记录下来， 普通的BA可能更是一种流水账式的、吃那拉那的描述方式。
不管怎样，BA在写文档，use case的时候，那些business rule被分布在文档中不同的部分，然后这些rule，在分工时，有被理所当然的分给不同的开发人员来开发。
阅读全文
摘要: 设计者高高在上，不食人间烟火，只是提供约束，不要这样，必须那样，而不是提供方法和可以复用的API。
开发者是处于解决问题的一线，饱尝重复造轮子的疾苦，他们最需要的是快速的解决问题，以更恰当的方式工作，寻找更容易构建系统的技术和方式。
Jquery给设计者上了很好的一课。
Jquery就像一个魔法师一样，$()就像魔法棒一样，随手一指，一个木偶变复活了，一瞬间具备了各种各样的复杂的能力。
阅读全文
摘要: 技术是基础，积累才能提高，用户是目的。成熟的架构+创新的扩展，server端，团队应当继续构建、成熟以spring为基础的企业应用开发平台，深度挖掘、孵化、封装，同时将精力转向客户端。努力实现客户端与server端的粘合剂开发提高开发效率，建议的平台是spring + jquery
阅读全文
摘要: full-stack 的设计，意味着各层能够无缝的集成在一起，遵循的DRY原则（don't repeat yourself)，将各层共用的东西，抽取出来，并通过自顶向下的设计，无缝的集成在一起，粘合在一起，达到更高层次、更粗粒度的重用，同时为了保证灵活的可扩展性，在更高、更粗的粒度上遵守开放-封闭的原则，在各层的各个关键点，要提供诸多的钩子，回调的接口，供使用者扩展。full-stack的设计，在层与层之间，并不一味的追求松散的机制，而是相反，在层与层之间增强一定的内聚性，粘合力，以此来达到粗粒度的封装与重用。
阅读全文
摘要: 最近做一个比较大的电子商务项目，预计每天订单量将在５万多单，客服人员需要频繁的下单、查询订单、操作订单，客人预订完订单后，会立即进入处理流程，为了提高服务质量，要求流水化作业，平均要在４０分钟－８０分钟内处理完订单。所以订单在创建后，会在短时间内，被频繁的修改和查看.
阅读全文
摘要: 我觉得现在技术换代很快，使用一项技术，首先是要快速的解决问题，然后要学习他的思想，那些整天死抱着Hibernate，自认为学习到ORM的设计技巧的人，就去继续的学吧。
我已经会用Hibernate的一些方面，我觉得够用就行了，犯不上，天天钻研HSQL，如果有时间，我觉得躺在草坪上看看Unix的编程艺术，看看代码大全，看看Oracle的编程艺术，比看Hibernate的SB书要惬意多了。
阅读全文
摘要: 我认为避谈代码是可耻的，只要编码有意义，我们在任何阶段，都应当投入到编码当中。
阅读全文
摘要: 所以对于框架来说，职责的分担，是很重要的，完成你该完成的，该扩展的地方，即要提供默认实现，也要提供接口，供调用者二次开发。这才是框架的可扩展性、灵活性所在。
很多人在开发框架时，总期望做很多东东，自己给自己加套，反而丧失的灵活性，同时提供了很多不能扩展的实现，等于强加意志给使用者，爱用不用。
阅读全文