弟兄们组织了一场读书会，讨论下阅读《大规模Web服务开发技术》前几章的感想，我作为一个才看了半章的家伙打了一下酱油，不过大家讨论的话题还是值得记录下来和挖一下的。
1.Hatena的发展经验-认同
Hatena是从人力的在线问答网站发展的，真是不可思议。我之前看过一家更传奇的网站的架构发展史，应该是FaceBook的，跟Hatena类似的经历，平均不到两年就对架构进行一次大规模的升级，以支持更高量级的压力。我想一个良好发展的网络企业，发展中的过程大致都是同样的情况，面对持续和爆发性增长，我们能做的只能是做合适的架构，和做即时的升级准备。
顺手记一下Hatena的改进过程：
a.改善组织体制，建立运维团队。b.迁移小型机房到数据中心，重新设计网络。c.优化系统负载，针对性做垂直扩展。d.LVS为主的负载相关体制的建立。e.推行虚拟操作系统。f.在d上改进，研发自己的监控管理工具。g.重新设计基础设施架构，重新设计程序逻辑和表结构，研发搜索引擎等子系统。
2.Hatena的组织结构-疑问
其实就是开发部和运维部，书上对于权责说的比较模糊，不过我总觉得貌似他们运维(基础设施部)做的事比我们公司的更多。因为注意到他们也会负责将系统扩展成虚拟化或云等比系统更先进的形态，处理负载等状况，而且是全责。再加上后面有提到开发的中间件等式完全统一规范的，所以我怀疑运维部有硬件方面的架构师，而不是开发部的架构师，而且很有可能搭建了内部的存储云计算云等服务给开发部使用。
3.Hatena的开发体制-认同
Hatena对于修改系统，采用的类似敏捷开发，但又好像不属于哪一种模式，果然是特有的。开发新产品的方法没有提，很遗憾。提到用了review和结对，态度是要用的适当，基本赞同。
4.敏捷开发的看法
敏捷开发我想是适合修改系统的，也适合开发需求或风险明确的项目。但是不得不说，敏捷是高效的，但也是高压高速容易疲累的。我有次用Scrum方法，4个人负责一个新项目的开发，有技术风险，经历了3个Sprint，我作为Master累的要死，其他开发的弟兄们也累得要死，燃尽图改过数次领导也很郁闷。所以敏捷开发不是银弹，不是没有代价的，反而更要在合适的时机下才能应用。
有兄弟表示结对编程的体验很棒的。我深深的认同，我想体验过结对的兄弟，也会对这神奇的经历念念不忘，两个人在这个过程产生的化学反应简直是超出想象，我至今怀念这样可以做到接近完美的自己。不过我也试验过，两个工作方法都不完善的菜鸟，或者一个主程带一个菜鸟，真的不适合结对，真的是活脱脱的浪费资源和折磨人。另外也不是所有的项目都适合两个主程去结对，我想最合适的，是设计大方向和目标明确，设计细节会有很多和高要求，比如一个公用的框架，结对编程是最合适也是能最棒产出的方式。我也不得不承认，我在不少时候也需要这样一个搭档来避免日后重新设计的代价。
5.Code-Review的看法
有兄弟很推荐Code-Review的做法。Hatena是在效率和质量中权衡后才选择，FaceBook是广泛使用的。
这事是很容易勾起我伤心事的。我从工作两年后就开始追求开发成本的降低(产品高效高质量知识低流失)，逐渐形成主要三个观点：Code-Review，系统平台化；先挖深和挖宽需求。几年来我起码向十家大小公司"鼓动"过Code-Review的做法，包括我的雇主、合作公司、客户公司，后来甚至面试也会有争论过这些，但是很意外，项目型公司坚决拒绝Code-Review，产品型公司难以采纳，唯一广泛采用这个做法并致力于同效果的改进的，居然是不以软件盈利的制造业企业。
我觉得我想说话的时候嘴是不笨的，我是明确说明了Code-Review的几大好处：
1.有效提高产品质量(利于开发规划化，Bug的排除)
2.有助于团队建设(团队成员能力提高、团队成员相互了解风格)
3.有助于部门建设（代理人/第二负责人体制有效的建立，开发人员流失带来的知识流失）
这样一个步骤，对于部门经理、开发经理、程序员都明显有利，这样对公司有莫大好处的做法，怎么你们就不采纳呢？！当后来我操心了很多开发之外的事情之后，我理解了。
1.先赚钱后省钱的生存法则。
这在中国做企业，尤其是软件企业，是必须遵从的。我承认Code-Review不能直接赚钱，是省钱的范畴。精力的重点，当然放在赚钱上面，Code-Review再多的好处，也需要人力和时间，即时能省下来后续的人力和时间，但是抢占市场的时机是更重要的。对于一个部门也是如此，不能保障对公司及时的产出，拿什么要资源提高质量呢。
2.质量没有严重影响到生存。
这个质量包括了产品质量和团队质量，这些都是可以通过Code-Review能提高的。赚钱和省钱也是相对有底线的，只不过优先考虑的是赚钱，当省钱的工作弱于底线的时候，才会得到足够的重视，公司投入精力，把它拉到底线上面来。就好像那家致力于开发质量的制造业公司，ITS部门不需要靠软件赚钱，但是由于软件质量问题，导致自己公司线上生产出现故障，一个数据出错意味着一个上万的笔记本报废，一批数据出错还要搭上高额的违约金，这种事故报上去直接就是该部门被训得天翻地覆影响仕途，完全没有其他的借口，所以只能致力于开发质量的提高。
说白了，各种不愿意推行Code-Review的理由，都是由于赚钱的追求无止境，质量的追究只在底线上。
完全可以理解。什么时候有精力弄质量了，有必须要弄质量了，Code-Review的好处大家其实都知道的，不需要推行也会被应用。
6.系统压力预估的看法
在公司一开始评审第一个项目的时候，就看到只评审功能需求，没地方填写性能要求。性能要求还是需要了解清楚，再做出设计的。
当然开发人员不可能准确预估出业务系统压力的，这确实是做产品的职责，没办法，开发人员只能按照要求做事，要求出错那不是我们可为的。
不过我还是喜欢挖深挖宽需求，尽量多了解不仅仅是需求本身，还有需求周边的信息。要知道产品人员不是神，最终用户也不是，我们做出的设计也会有Bug，他们提出的需求可能并不是实现他们目标的最好方式。另外需求了解的多，也更有利于设计准确的系统。
我是很赞成人人都是产品经理这个说法的。所以我想不论是做应用型的业务系统，还是研究型的基础系统，都要当成产品来做，包括售前售后而不仅仅是实现，可以得到更多的收获。
7.系统扩展的看法
我也一直觉得垂直扩展总是有上限的，水平扩展可以做到无限，这是水平扩展的明显优势之一。
水平扩展在硬件上确实比垂直扩展省钱，性价比高，水平扩展的明显优势之二。
在复杂度上来说，水平扩展会提高架构复杂度，但是垂直扩展也同样会导致程序的复杂度提高。
在人力成本上来说，需要架构师做水平扩展和维护人员管理服务器，但是垂直扩展同样需要高素质的开发人员：熟悉高性能算法优化程序、熟悉通过抓Dump改进系统各方面资源利用率、熟悉数据库各种优化设计等等，这样的开发人员也不好找。
8.分布式缓存的看法
我还真没特意琢磨过什么情况用memcache这种分布式缓存应用。我想了一下，发现我一直遵循这三个方面：
1.缓存数据需要其他进程共享
这种情况会考虑把缓存放到独立进程中。比如web系统做了负载，那么他们需要共享同一块缓存。
2.缓存数据会很庞大
能够预计到这个情况，那么就要考虑用高效的缓存中间件了，而且放到独立服务器上。
3.服务器职责需要分开
其实是按照业务拆分服务器资源的思路了。主打运算的服务器，主打存储的服务器等等，这样子拆分有时更容易充分利用资源，也更能节省服务器上重复部署组件的成本。