Published on 2009年05月27日
今天上午，我的twhirl告诉我有如此一推，“digitalboy：Twitter的用户数已经从一年前的160万增加到了3,210万人左右，但这家旧金山公司的员工数仅从1月份时的21人增加到了45人。”（从twitter的网站看来应该是54个）
于是我开始想到价值与规模的问题。我看到的很多公司，迅速的膨胀，人数越来越多，效率却越来越低。难道价值和规模不应该是正比的吗？也许有几件事情是我们应该搞清楚的。
一、我们要做多大的事？
我们要做很大的事么，其实不然，创造价值不代表你要做出惊天动地的大事，我们要弄清楚的事情是我们到底要做什么，我们更要弄清楚不是非要几千万美金来能真正作出事情来。创造价值最根本是知道价值在哪里，而且做排场。
二、我们到底需要多少人？
一个精良的技术团队，通常只需要那么一两个产品，一两个前端工程师，两三个后端工程师，一个架构师同时还可以作为团队的管理人员。有时候我们就是应该这样苛刻，因为我们可能并不需要更多的人，精简的团队能带给我们更高的沟通效率和更高的执行力。当我们发现这样的团队人数不够用时，我们就要思考是不是我们的schedule或者任务不合理，或者是我们的流程有问题，要不然就是我们的人员工作效率太过低下。当我想到要去招新人的时候应该先尝试提高整个团队的素质，改良我们的工作模式。
三、我们真的要扩张吗？
我们希望有一家大公司，几千号人，一个庞大的官僚机构，我们可以高高在上，掌管了员工的命运。但从此，公司就会走上一条不归路，庞大的组织将拖垮这台机器，一些人多而引发的问题就开始出现了。我并不是说我们不能把一个公司做大，做大当然是好的，但是在做大之前，我们要想想是否有必要这样做，也许光是现在这些业务我还需要裁员呢，公司里面可能有30%的人是不做事情的。
那么新业务呢，我们需要不断的开展新的业务么？我这里说的是一个公司，并不是一个集团，你有足够的钱，你再开一家公司去做另一件事情这个当然是好的。但是对于一个公司而言，我们应该拥有一个核心业务，比如twitter的碎碎念，google的搜索，microsoft的个人软件，Oracle的数据库，SOHO的房子，Nokia的手机……而且任何的业务扩展，应该是围绕这个核心业务来做。不做不相关的事情，少做只有一点相关的事情。要记得，用户大多是冲着你的核心业务而来的，你要做的事情应该是服务的核心业务，让你的核心业务增值，这样才能给用户创造更多的价值，从而给自己带来更多的价值。尊重用户，尊重股东就是我们要选择新业务选择扩张的前提。
四、我们还有需要注意的么？
作为一个管理着来说，工作模式的改良，团队自身的提高，才是我们工作的重中之重。我一直在说我们需要有克制的扩张，我们需要在大多数时间学会控制自己的团队规模。可是这样显然是不够的。我们需要进步，公司需要进步，我需要做更多更困难的事情，这个时候，我们就需要一个更好的团队了。所以我们平时一直要做的便是总结、学习、进步。
Published on 2009年03月13日
这是经过我的观察得出的海底捞的服务流程
从某种程度上说海底捞的服务模式是高效的。
固定服务（Fixed Service）：前端服务，用Listener来侦听事务的数据变化，请求并且在与后台通信后返回一个回馈。后台对于该事务的反馈通常都是这一个模块来处理的。另外这个模块还担负着执行事务的创建和销毁的流程。总之这个模块就是和事务直接进行接触的基础服务模块。
临时服务（Interim Service）：后台服务，该部门是处理系统底层数据的。当它收到前端服务的请求是会进行反馈供前端服务使用。
循环服务（Loop Service）：该部分通常是服务器脚本，它们有明确的智能，比如加水，加糖，换毛巾。它们循环侦听每一个事务的数据变化然后做出处理。
在整个流程中，还有一个部分是例外的请求。当固定服务忙，或者被死锁时，事务提交一个请求，这时候请求或许会被某些其他模块侦听到，应该放入一个缓冲区中最终交给固定服务去处理，以致不破坏流程
Published on 2009年03月9日
随着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的数据，将完整的初始状态留给用户对用户来说可能是更好的体验。
Posts