易栈网-膘叔

说起来，上次参加聚会到现在已经过去两个月时间了，ThinkInLamp聚会是每个月的第一周的周末举办，这是我第二次参加，在安居客公司的会议室里。
与会者嘛，还是安居客的开发占了大部分，毕竟天时地利人和啊。确实，如果有这样的聚会放在公司里，一来可以让单位的开发人员进行学习二来也可以了解认识一下其他开发人员，对于公司来说几乎没有任何投入成本，但所获颇多（毕竟真要请人来培训花的钱更多。。）
这次聚会其实就三个内容，一团队，二求职，三敏捷开发
从上个月的聚会开发stingchen就开始有他的分享了，可惜7月份无缘参加，（那次还有逍遥冰心讲的领域驱动方面的内容，也没有听到。惋惜，所以这次我怎么样也得来了。）sting介绍了团队建设方面的一些要点，以及注意事情，引起了很多人的共鸣，看来很多人在工作中遇到过类似问题啊（看来领导们很多）
板子介绍的是不要让工作外的事情来影响工作。总结起来就是有一颗平常心，不以物喜不以已悲，了解自己的真实想法做下去，不要频繁跳槽。
最后的敏捷开发就是讲的如何让工作变得更有效率。在讲之前做了一个游戏，每组8个人，每组中又有不同的分工，一个客户，一个客户老板，三个经理，每个经理下面有一个工人。然后分组开始数硬币（当然是有一定的规则）。客户将硬币交给工人时，客户与客户老板同时开始计时，当第一个工人开始翻硬币时，对应的经理开始计时。当第一个工作完成任务后，把硬币交给第二个工人时，第二个工人对应的经理开始计时。当第一个工人全部把硬币给了第二个工人时，第一个工人对应的经理停止计时。客户在收到第三个工人第一枚硬币时结束计时。当最后一枚硬币到达客户手里时，客户经理停止计时。然后做了五次不同方式的游戏，比如从左手到右手再到两只手一起，等等。DannelTeng的意思就是想让我们把工作能够细分，而且并不是在细分全部结束后再下达任务，这样的工作效率会有提高。
突然想起几件事，一小时学的语文课文里有个统筹方法，好象与此类似。还有就是在夜大学习的工商管理中的管理学，都有涉及类似方面。工厂运作本来就与程序开发有类似之处，毕竟理论是一样的，只是在实现的方法中有不同的方式而已，就如那句：戏法人人会变，手法各有不同。当然，如果没有经过培训过的人，可能在工作过程中也会摸索出类似的方式，但如果经过事先培训，岂不是会更加增加工作效率 ？

最后再做一个广告，锅巴哥哥准备在10月份左右举办一次数据库的专题会，他说到时候会请一些数据库方面的专家来与大家分享和讨论数据库设计方面的事情。也坦言在PHP开发中，其实DBA处于一个很尴尬的地位，即DBA在开发中几乎是没有介入开发中的机会，往往数据库的设计都是由开发人员自行设计，这导致在遇到问题时无法进行调优。而这次分享会上，就是请不同行业的专家们来分享如何更好的设计数据库，以及一些调优方法 。
顺便，锅巴哥哥说的原来从最初设计MYSQL时就是为了电信级的应用。我承认我真不了解这个背景，我想，恐怕80%的PHP开发者不了解MYSQL设计的背景吧。了解的最多的恐怕就是开源、免费。想着MYSQL被我们用成这样，不知道那些数据库设计人员是否会很郁闷。
估计，下一周就会有今天分享的PPT和视频出现在thinkinlamp官方网站了。你也可以到官网查看往期的分享（官网：www.thinkinlamp.com）。

做技术的难免都会遇到技术分享这个词，其实，它并不难懂也不难理会，只是以前很多人更多喜欢自己独自享受，以防影响到自己的职业。但到了近几年，技术分享这个词越来越被大多人所提及，毕竟你一个人了解的技术也是有限的，在圈内推广或者分享的时候，你虽然把你的经验与他人分享了，别人可能学会了你的东西、技术，但是你也相对的了解了其他的技术细节，这是你一个人的时代无法得到的。
单兵作战的时代早就过去了。现在讲究的是团队作战，当然个人技术很可能会占有主导地位，但你总不是万能的。
就象这次lamp聚会，我更想听的是逍遥冰心：《领域驱动设计简述》和蒙显仁：《LAMP在51座席项目中的应用》，遗憾的是这两位都没有来，相反，我却在我认为意义不大的演讲中获取了很多有用的东西，比如滕振宇：《Check in Dance》，真正让我了解到原来check in，并非那么简单，其实在我们的项目中，使用版本控制的时候，一般情况下，都会差不多半天check一次吧。但滕振宇讲的技续集成、atdd等让我受益匪浅，虽然他用的是c#而并非PHP，但是他的一些工具和他的作法很值得推广，比如红绿灯机制、rabbit之类的（参考一些大公司）。如果是重要项目，甚至有小熊机制（得到小熊的人才能checkin代码）这对于小型公司的人来说确实比较难以遇到。事实上我也一直在小型公司打拼。虽然我一直认为我不是做技术的料。滕振宇让我意识到合理的利用工具，绝对是可以增加工作效率的。但我却还是用不到这些，在小公司，并非以产品为主导的公司，如电子商务，一切都是以开发效率至上的，东西错了可以改（只要不涉及到钱）。所以什么单元测试啥的很多时候是用不到的。虽然小公司也有UserStroy，但效率、效用并不如大公司来的那么彻底。

再谈一下方言的《优秀产品欣赏》，方言给了我们很好的产品介绍，以及对于一个产品的分析，品析了玉溪香烟，对于用户忠诚度、品牌认知度、推广度等进行了简要的介绍（其实上就是在分析一款产品对于用户来说有哪些是可以控制并拿来利用的。）还介绍了MacBook，并坦言在自己公司也推广了4台。事实上我对于MB也是有点想法的，只是闲钱不多，没办法了，忍忍吧。最后他介绍了自己的一个做了两年的产品，看他演示的时候感觉好象不错，但是在线版的说实话，不敢用。真的，在国内，凡是涉及到用户信息的，我还真是不太敢使用，我越来越胆小了。但那款软件，感觉上真不错。最起码他在演示的时候显现出来的功能让我感觉很爽。是类似网页设计的。

其实祁宏：《正则表达式入门》和Ben：《基于 Zend Framework 的 Web 开发实践》都不错，只是这两个东西对我来说已经了解过很多次，所以相对就没有特别的关注。祁宏（并非足球运动员哦）的正则表达式并非他所言讲的只是初级的，到后面的内容已经是一般项目中用不到的内容了。有点深后，反而影响了大家的兴趣，因为他也不可能每一句都讲解的非常详细，反而就觉得不太实用了。举两个实际例子的话，或许会好上很多（比如采集网页啥的。如何写上一些关键代码，可能会更吸引人。）,regexbuddy这个工具实在太出名了。验证正则表达式，几乎都会用到吧？Ben的ZF框架介绍的不错，只是时间有点拉长了（注重了细节而没有把如何应用架构列的详细）如果真要介绍ZF的流程性操作，bootstrap可是有的讲了。板爷也说了，真要讲ZF，三天三夜也讲不完啊。说实话，做WEB项目，我还真是很少有看到拿ZF来做的，虽然我也比较推荐（因为有完整的团队在支持而不是那一些个人框架，说不定哪天就不支持了，那才郁闷比如我们现在用的thinksns，那真叫一个郁闷啊。）ZF可拿来说的事还真不少，MVC这块除了V之外，M和C都是让人很头疼的。M吧，一直没有一个完整的model类，全部是通过zend_db_table,zend_db_table_gateway,..table_row等进行CRUD，当然要说select的话，他还提供了一个zend_db_select（这是支持连贯操作的类），对于表关联操作，我记得zend官方也说过，好象没有一个特别完美的方法，连他们自己对于zend_db_table_gateway都不满意，更不用说用户了。。。。C嘛。因为涉及到front_controller，就又显得复杂了一点。真想程序逻辑与business logic完全分开，那真的就要等逍遥冰心：《领域驱动设计简述》了。V。。要么不扩展，如果真扩展了。那些View_Helper类，几乎完全作废。

完事，对于此次分享会我是受益颇多，毕竟有些想法是我以前没有想到的。如果以后还有这种机会我还是想去，当然尽量不要太远的。HOHO。对于滕振宇所提的软件协会的一些探讨会，感觉不错，只是不知道有没有时间去听了。

听说一些老外的分享会也不错，但我这个人有点闷骚，不太喜欢讲。如果用电脑交流或许会更好一点。所以，我更多的只能适合作为一个旁听者而不是演讲者了。再加上，我也应该是属于野路子编程，其间之事，实不足为外人道也。Over

结束前突然想起一位朋友说的我聚会后的博客更新很快。其实，这只是对于听大家分享内容的一点笔记而己。由于我没有带任何笔、纸等 相关用来记忆的东西，在听完分享后，为了防止自己遗忘，总要想个办法记录下来，既是一种记录也是加深自己的印象，对于分享中了解的东西做一点归纳，哪些是自己能够吸收的，哪些是可以听过就忘的，哪些是未来想要了解的。这些，还是很重要的。

本次活动由ThinkInLamp牵头举办，发起人为三马，活动网址：http://blog.thinkinlamp.com/?p=174,本篇我听完分享后的个人感想而已

在文章内容里加入了新的尝试，可以把页面分享至google reader;生成pdf;发送至wordpress,发送至live space。

看到很多网站有这个分享功能，我觉得我也是可以尝试一下。不知道是否有什么大用处，但或许能够有不一样的体验？
用官方的话来说，那就是：一个点击， 快速完成分享。 常在开心网或人人网看到朋友转贴的精采文章及图片吗? 【分享】就是背后的大功臣，一个强大的网页分享插件，让您将喜欢的博文、新闻等内容快速分享到社群网络上。

但其实，我还是认为这样会反而使得自己的用户在流失，不过，我这也算是一个尝试，而且bshare.cn上面有统计。所以我想试上三个月，看看有没有什么特别的用处。

分享按钮在哪里呢？是在文章的底部啦



上面的四个按钮的顺序也是我精心挑选的。点击更多则可以分享到其他网站。其中google reader用了你自己的google帐号，如果处于登录状态，可以直接使用。生成pdf则不需要任何帐号【比较适合收藏文章】其他两个也是需要在本站输入帐号，但其实是在bshare.cn的JS代码中输入，所以我不能保证是否会有什么密码XXX的问题。官方和弹出窗的提示窗上也都说了不会收集密码等信息。。。

原文作者：yizhu2000

链接：http://www.phpv.net/html/1663.html

本人作为一位web工程师，着眼最多之处莫过于性能与架构，本次幸得参与sd2.0大会，得以与同行广泛交流,于此二方面，有些架构设计的心得，不敢独享，与众友分享，本文是这次参会与众同撩交流的心得.

架构设计的几个心得：

一，不要过设计：never over design

这是一个常常被提及的话题，但是只要想想你的架构里有多少功能是根本没有用到，或者最后废弃的，就能明白其重要性了，初涉架构设计，往往倾向于设计大而化 一的架构，希望设计出具有无比扩展性，能适应一切需求的增加架构，web开发领域是个非常动态的过程，我们很难预测下个星期的变化，而又需要对变化做出最 快最有效的响应。。

ebay的工程师说过，他们的架构设计从来都不能满足系统的增长，所以他们的系统永远都在推翻重做。请注意，不是ebay架构师的能力有问题，他们 设计的架构总是建立旧版本的瓶颈上，希望通过新的架构带来突破，然而新架构带来的突破总是在很短的时间内就被新增需求淹没，于是他们不得不又使用新的架构
web开发，是个非常敏捷的过程，变化随时都在产生，用户需求千变万化，许多方面偶然性非常高，较之软件开发，希望用一个架构规划以后的所有设计，是不现实的

二，web架构生命周期：web architecture‘s life cycle

既然要杜绝过设计，又要保证一定的前瞻性，那么怎么才能找到其中的平衡呢？希望下面的web架构生命周期能够帮到你

所设计的架构需要在1－10倍的增长下，通过简单的增加硬件容量就能够胜任，而在5－10倍的增长期间，请着手下一个版本的架构设计，使之能承受下一个10倍间的增长

google之所以能够称霸，不完全是因为搜索技术和排序技术有多先进，其实包括baidu和yahoo，所使用的技术现在也已经大同小异，然而，google能在一个月内通过增加上万台服务器来达到足够系统容量的能力确是很难被复制的

三，缓存：Cache

空间换取时间，缓存永远计算机设计的重中之重，从cpu到io，到处都可以看到缓存的身影，web架构设计重，缓存设计必不可少，关于怎样设计合理的缓 存，jbosscache的创始人，淘宝的创始人是这样说的：其实设计web缓存和企业级缓存是非常不同的，企业级缓存偏重于逻辑，而web缓存，简单快 速为好。。

缓存带来的问题是什么？是程序的复杂度上升，因为数据散布在多个进程，所以同步就是一个麻烦的问题，加上集群，复杂度会进一步提高，在实际运用中，采用怎样的同步策略常常需要和业务绑定

老钱为搜狐设计的帖子设计了链表缓存，这样既可以满足灵活插入的需要，又能够快速阅读，而其他一些大型社区也经常采用类此的结构来优化帖子列表，memcache也是一个常常用到的工具

链接:钱宏武谈架构设计视频 http://211.100.26.82/CSDN_Live/140/qhw.flv

Cache的常用的策略是：让数据在内存中，而不是在比较耗时的磁盘上。从这个角度讲，mysql提供的heap引擎（存储方式）也是一个值得思考的方法,这种存储方法可以把数据存储在内存中,并且保留sql强大的查询能力,是不是一举两得呢?

我们这里只说到了读缓存，其实还有一种写缓存，在以内容为主的社区里比较少用到，因为这样的社区最主要需要解决的问题是读问题，但是在处理能力低于 请求能力时，或者单个希望请求先被缓存形成块，然后批量处理时，写缓存就出现了，在交互性很强的社区设计里我们很容易找到这样的缓存

四，核心模块一定要自己开发：DIY your core module

这点我们是深有体会，钱宏武和云风也都有谈到，我们经常倾向于使用一些开源模块，如果不涉及核心模块，确实是可以的，如果涉及，那么就要小心了，因为当访 问量达到一定的程度，这些模块往往都有这样那样的问题，当然我们可以把问题归结为对开源的模块不熟悉，但是不管怎样，核心出现问题的时候，不能完全掌握其 代码是非常可怕的

五，合理选择数据存储方式：reasonable data storage

我们一定要使用数据库吗，不一定，雷鸣告诉我们搜索不一定需要数据库，云风告诉我们，游戏不一定需要数据库，那么什么时候我们才需要数据库呢，为什么不干脆用文件来代替他呢？
首先我们需要先承认，数据库也是对文件进行操作。我们需要数据库，主要是使用下面这几个功能，一个是数据存储，一个是数据检索，在关系数据库中，我们其实非常在乎数据库的复杂搜索的能力，看看一个统计用的tsql就知道了(不用仔细读,扫一眼就可以了)

select   c.Class_name,d.Class_name_2,a.Creativity_Title,b.User_name,(select   count(Id)   from   review   where   Reviewid=a.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id 

select   a.Id,max(c.Class_name),(max(d.Class_name_2),max(a.Creativity_Title),max(b.User_name),count(e.Id)   as   countNum   from   Creativity   as   a,User_info   as   b,class   as   c,class2   as   d,review   as   e   where   a.user_id=b.id   and   a.Creativity_Class=c.Id   and   a.Creativity_Class_2=d.Id   and   a.Id=e.Reviewid   group   by   a.Id ..............................................

我们可以看出需要数据库关联，排序的能力，这个能力在某些情况下非常重要，但是如果你的网站的常规操作，全是这样复杂的逻辑，那效率一定是非常低 的，所以我们常常在数据库里加入许多冗余字段，来减小简单查询时关联等操作带来的压力，我们看看下面这张图，可以看到数据库的设计重心，和网站(指内容型 社区)需要面对的问题实际是有一些偏差的

同样其他一些软件产品也遇到同样的问题所以具我了解，有许多特殊的运用都有自己设计的特殊数据存储结构与方法，比如有的大型服务程序采取树形数据存储结构，lucene使用文件来存储索引和文件

从另外一个角度上看，使用数据库，意味着数据和表现是完全分离的（这当然是经典的设计思路），也就是说当需要展示数据时，不得不需要一个转换的过 程，也可以说是绑定的过程，当网站具备一定规模的时候，数据库往往成为效率的瓶颈，所以许多网站也采用直接书写静态文件的方法来避免读取操作时的绑定

这并不是说我们从今天起就可以把我们亲爱的数据库打入冷宫，而是我们在设计数据的持久化时，需要根据实际情况来选择存储方式，而数据库不过是其中一个选项

六，搞清楚谁是最重要的人：who's the most important guy

在用例需求分析的时候常常讲到涉众，就是和你的设计息息相关的人，在web中我们一定以为最重要的涉众莫过于用户了。，在一个传统的互动社 区开发中，最重要的东西是内容，用户产生内容，所以用户就是上帝，至于内容挑选工具，不就是给坐我后面三排的妹妹们用的吗？凑或行了，实在有问题我就在数 据里手动帮你加得了。。这大概是眼下许多小型甚至中型网站技术人员的普遍想法。钱宏武在他的讲座里谈到了这个问题：实际上网站每天产生的内容非常的多，普 通人是不可能看完的，而编辑负责把精华的内容推荐到首页上，所以很多用户读到的内容其实都依赖于编辑的推荐，所以设计让编辑工作方便的工具也是非常重要， 有时甚至是最重要的。

七，不要执着于文档：don't be crazy about document

web开发的文档重要吗？什么文档最重要？我的看法是web开发中交流>文档，

现在大的软件公司比较流行的做法是：
注重产品设计文档，在这种方法里，产品文档非常详尽，并且没有歧义，开发人员基于设计文档开发，测试人员基于设计文档制定测试方案，任何新人都可以通过阅读产品设计文档来了解项目的概况

而web项目从概念到实现的时间是非常短的，而且越短越好，并且由于变化迅速，要想写出完整的产品和需求文档是几乎不可能的，大多数情况是等你写出 完备的文档，项目早就是另外一个样子，但是没有文档的问题是，如果团队发生变化，添加新成员怎样才能了解软件的结构和概念呢，一种是每个人都了解软件的整 个结构，除非你的团队整体消失，否则任何一个人都能够担当培养新人的责任，这种face2face交流比文档有效率很多。

于是就有了前office开发者，现任yahoo中国某产品开发负责人的刘振飞所感觉到的落差，他说，我们的项目是吵出来的，我听完会心一笑

八，团队：team

不要专家团队，而要外科手术式的团队,你的团队里一定要有清道夫，需要有弓箭手，让他们和项目一起成长，才是项目负责人的最大成就

总结：

架构是一种权衡

web开发的特点是是：没有太复杂的技术难点，一切在于迅速的把握需求，其实这正式敏捷开发的要旨所在，一切都可以非常快速的建立，非常快速的重构，我们的开发工具，底层库和框架，包括搜索引擎和web文档提供的帮助，都提我们供给了敏捷的能力。

此外，相应的，最有效率的交流方式必须留给web开发，那就是face2face（面对面），不要太担心你的设计不能被完备的文档所保留下来，他们会以交流，代码和小卡片的方式保存下来

人的因素会更加重要，无论是对用户的需求，还是开发人员的素质。

今日在QQ群中闲逛，听得群友胡侃天地，偶得一笑谈，与诸君共享。

上周六，云高气爽。吾心愉，遂往颐和园。由东门入，行至十七孔桥。后舟至石舫，穿竹林，越沟桥，至四方院落，购肉肠若干，面一桶，吾至饿，故速食之。出院落，行百余步，忽现一庙堂，奇之，遂入！堂内仙女般MM若干，左右依壁各一龙座，一MM见吾左顾右盼，忽披一龙袍于吾身，摁于龙座之上，"皇上勿动!" "喀嚓！" 吾顿觉双眼恍惚，忽觉手中有温软之物，定神视之，见MM玉手攥与吾手之中，吾汗！须臾之间 "喀嚓"，吾双目恍惚again,未及清醒，忽闻一MM呼："喂，你自己照的10块，和哀家合照40，一共50，掏钱！" 

一笑了之