这是经过我的观察得出的海底捞的服务流程 从某种程度上说海底捞的服务模式是高效的。 固定服务（Fixed Service）：前端服务，用Listener来侦听事务的数据变化，请求并且在与后台通信后返回一个回馈。后台对于该事务的反馈通常都是这一个模块来处理的。另外这个模块还担负着执行事务的创建和销毁的流程。总之这个模块就是和事务直接进行接触的基础服务模块。 临时服务（Interim Service）：后台服务，该部门是处理系统底层数据的。当它收到前端服务的请求是会进行反馈供前端服务使用。 循环服务（Loop Service）：该部分通常是服务器脚本，它们有明确的智能，比如加水，加糖，换毛巾。它们循环侦听每一个事务的数据变化然后做出处理。 在整个流程中，还有一个部分是例外的请求。当固定服务忙，或者被死锁时，事务提交一个请求，这时候请求或许会被某些其他模块侦听到，应该放入一个缓冲区中最终交给固定服务去处理，以致不破坏流程
Posts tagged 模式
关于JS——架构的设计
随着web技术的发展，web2.0开始成为主流，JS在整个系统中的地位越来越重要，而对于JS的优化和架构的建立也越来越受到重视。 一、为自己的系统选择一个合适的框架 prototype和Jquery都是很好的框架。 prototype是一个完全存在于底层的代码，他优化了JS的面向对象的扩展，封装了DOM操作API，很好的处理了事件，AJAX等，体积也很小。要说他的缺点，恐怕就是它本身并没有实现太多的功能。 JQuery，本身实现了很多特效，能帮助工程师完成很多工作，即便是工程师对JS并不那么熟悉。它很重视代码的简介与高效。是一个很不错的库类，鼎鼎大名的YUI都复用了很多他的代码。 选好了一个框架，之后就应该要求工程师按照框架的要求去进行开发。否则，这个框架的选择还有什么意义呢。 二、不要把只有单独的子项目才会使用的JS放在全站都会引用的.js文件里 这个几乎是毋庸置疑的。但是有时候我们需要去减少一张页面的JS文件请求数，这时候我们通常会把子类的代码直接放在基类的文件中，然后随着项目的增多，继承该基类的子类也增多，我们在下载页面的时候需要去加载的无关代码量也开始增大。于是我们在控制JS文件请求数的同时也要考虑到，我们应该如何去规划JS的目录结构。 通常我们把js放在www的js目录下或者是将站点的所有静态文件都放于http://static.yourdomain.com，其中js文件的目录是http://static.yourdomain.com/js。 而我们通常把一些全站都会用到的函数，或者一些简单的极其常用的基类定义在一个类似于global.js的文件里，然后把其他的一些跨应用的基类放在以类名为文件里并放在class/目录下，如class/ajaxlist.js，这个文件是处理ajax下生成和操作数据列表的类的代码。而对不同应用则应该有一个文件是对这些基类的实例化和逻辑处理的相关代码便放在属于他们自己的文件里然后存放于app目录，比如app/album.js是关于相册的代码。 于是，我们的HTML里面应该是这样的。 <script src="http://static.yourdomain.com/js/prototype.js?124"></script> <script src="http://static.yourdomain.com/js/global.js?326"></script> <script src="http://static.yourdomain.com/js/class/ajaxlist.js?178"></script> <script src="http://static.yourdomain.com/js/app/album.js?768"></script> 而这样的代码是很符合优化策略的 三、在HTML里为你的JS加上版本号 这是很必要的。这将利用浏览器的缓存或SQUID等来减少浏览器像服务器进行请求的次数，也将节省用户的下载时间。只要版本号不变化，浏览器就不会重新下载。 四、在用户操作前为用户做好准备工作 有一些过度的结构化的代码反而会造成负担。特别是在IE的JS执行效率还不算很高的现在看来。有时候用服务器端去处理那些没必要交给JS的数据，将完整的初始状态留给用户对用户来说可能是更好的体验。
弱弱的说一下敏捷开发
关于敏捷开发，这已经不是一个新词了，我第一次听到敏捷开发这个名词的时候已经是好几年前。可是最近我才真正的开始关注和学习敏捷开发的思想。 首先，敏捷开发是一种针对人的以人为核心的开发模式，这是一种循序渐进的开发模式。他强调的是人与人之间的交互，而不是工具或者其他的流程。它有完整的开发团队，扁平式的，工程师与工程师之间，工程师与项目经理之间直接进行沟通。它把系统划分为若干个尽量小而简单的模块。它要求团队所有成员所做的事情都只是恰到好处。它甚至觉得我们应该拥有一个更好的沟通模式和流程控制，然后抛弃文档，因为文档会耗费大量的时间。 我们需要持续的向客户或者产品设计人员提交版本来让它了解进度并随时给出修改意见，这样做能避免更大程度的返工，也更能在不停的使用中进行测试，找出不尽人意的地方。 进度的控制很重要。进度是保持开发持续性的一个重要因素。而开发持续性是敏捷开发在代码质量控制的过程中的重中之重。 我们需要更好的架构和需求设计。更好的架构能保证模块与模块之间的解耦性，能减低模块之间的影响。而需求设计的完整能让工程师更清楚自己该做什么。 只做到恰到好处。完成所有客户提出的或者是产品设计人员提出的需求，然后仅此而已。保持开发速度，增强单位时间工作的实用性。 我们还需要，经常在一起开开小会，说说遇到的问题，然后改进。 总之我们的目标就是要刚刚好。 同时敏捷开发也存在他自身的不足： 1. 对于那些优先级不明确或者需求不明确的项目难以开展。 2. 团队的建设成本较高。这一点大部分来自于人的问题。人是有缺点的。比如人容易疏忽，犯错误，人宁愿自己写而不愿意改(我就是这样的人)，人有时候还难以保持一个优良的状态。于是我们要对团队进行不断的培训，培养，有时候还要设立很多规矩，比如不要随便打扰别人。 3. 当团队有新人进入或者有老人退出时，这一切都将变得很艰难。 其实敏捷开发，就像是一个美好的许愿，无论是公司老总，项目经理，还是工程师，对于敏捷开发都抱有不同程度的幻想，但是它真的那么容易实现吗？
Posts