架构师接龙：百姓网潘晓良VS. 盛大许式伟
主持人：冯大辉，现任丁香园 （http://www.dxy.cn）网站CTO。曾历任支付宝架构师、数据库团队负责人等职。
潘晓良：你们是否面临着南北问题？你们是如何解决南北问题的呢？
许式伟：南北问题，是所有网络服务共同面临的难题。
我们解决南北问题的思路是“动静分离”。具体来说，就是把网站中不易变的部分和易变的部分明确区分。
不易变的部分，举个特例就是静态资源文件如JS、CSS、image之类，可以使用CDN技术作为解决方案。易变的部分，又区分为状态保持型和计算型（也就是状态都是内部的状态，整个服务对外是个无状态的服务），如果是计算型的，那么如果该服务压力比较大的话，也是可以通过在南北各部署若干套服务，然后通过DNS解析来分流；对于状态保持型，这个是最麻烦的，因为多份部署对它来说并不适用（多份部署存在数据一致性问题），只能采用集中式部署。我有两个建议：第一，应该尽可能通过调整架构来减少这种服务的压力需求；第二，如果实在没办法的话，花钱解决，将这部分的服务部署在优质的机房。
潘晓良：你们是否尝试过敏捷的一些方法？有什么敏捷心得吗？
许式伟：我们尝试过敏捷方法，例如10分钟站立会、Pair Programming等，并且还在继续坚持。
对于敏捷，我的看法是，觉得合适、有效果就行，没效果就换着试试别的办法。方法学都是与团队文化息息相关的，并不是一种放之四海而皆准的标准。
潘晓良：你们是如何监控代码的执行效率？又是如何来找到瓶颈的？
许式伟：我们并不“监控”代码的执行效率。只有在业务上说某个特性性能没有达到需求，比如测试发现执行效率没有达到业务预期的目标，或者依据网站访问的日志发现某个功能的执行效率会严重影响用户体验，我们才去分析瓶颈在哪儿。
我们使用的找瓶颈的方式很传统，就是 Profile。对于这种分析方式，多数语言的编译器都是支持的。
潘晓良：你们是如何衡量代码质量的？是行数、执行效率、Bug数量还是其他的？
许式伟：这是一个很有意思的话题。
代码行数是衡量代码质量一个非常粗糙的指标，代码量大，意味着潜在的问题概率也大，但显然只能是一个预警指标，而不是精确的。另一个预警指标是测试案例的覆盖率。测试案例覆盖率越低，代表着代码潜在的问题也越大。个人认为它比代码行数更有参考价值。
我认为衡量代码质量的尺度，是保证测试案例覆盖率情况下Bug的变化曲线。如果Bug曲线下降迅速，那么意味着代码质量很棒；如果Bug迅速下降到一个基点，并且稳定在这个基点长期无法下去，这意味着代码质量不错，但是存在设计缺陷，在某些特性上无法满足；如果Bug长期居高不下，不断衍生出新Bug，或者Bug被反复Reopen，那么代码质量就低。
潘晓良：互联网产品的更新周期很快，我们是一天发布一次，但是这时候测试就变得很重要，既不能大规模地测试，因为有改动的时候更新比较多，光维护测试用例都来不及；又不能减少测试，因为如果Bug太多，光修复的开销就很大。你们有什么经验或者建议吗？
许式伟 ：互联网确实带来了巨大的革新，对软件开发方式的影响也是如此。如同解决南北问题一样，我们主要是从架构上做保障，同样的方法 ： “动静分离” 。
具体来说，就是把业务区分出易变的部分和不易变的部分。尽可能把更多的服务做成基础性的、不易变的、与用户交互无关的。对于这种服务，维护周期可以较长 ；而业务相关的，变动就要多一些，这里可以做的事情是，尽可能解耦功能之间的关联性，让一个功能的调整不要影响到另一个功能。如此这样的话，一方面可以保证待测试的代码量尽量少（代码行少，至少出问题的机会也就少），另一方面出问题影响的范围也小。
潘晓良： 你们是否尝试过Pair Programming？我们试下来确实很好，但问题是推广比较难做，你们是否有一些这方面行之有效的经验？
许式伟 ：我们鼓励Pair Programming，但是没有强推。如前所述，没有强推是因为觉得它并不一定适用所有人，所以喜欢就用。而且我们也不是所有任务都来个Pair Programming，只有在觉得某个任务适合的情况下才做。
潘晓良：互联网产品的网络访问日志是非常宝贵的资源，但是却因为存储容量的限制等问题，没有好好地用起来，你们对网络访问日志会分析什么？怎样分析呢？
许式伟：我很认可这一点 ：互联网产品的网络访问日志，是网站运营积累下来的宝贵财富。
我个人倾向于尽可能地保留更多的原始日志信息，当然很多公司出于成本的考虑会抛弃一部分历史数据而仅仅留下分析结果。保存原始日志信息的意义是显然的，因为我们期望统计的用户行为其实是不断调整的。今天你关心独立IP数，明天可能就变另一个参数，而一旦你丢弃原始日志，也就无法再对这段历史进行新参数的统计。分析日志我们会倾向于用第三方如Google Analytics与自有的数据分析的系统结合。自有的数据分析，我觉得Hadoop是一个不错的成熟方案，可以直接使用。