下面是有一些截图，是做代码静态扫描，很多毛病只有真的跑起来才知道，但是软件写到后面分支那么多没有办法在测试的时候把所有分支再跑一次，需要扫描所有原代码元件，包括这里面显示，有一个自己扩展能力，写了一些豆瓣自己扫描代码的小工具放进去，扫描话段引用，发现三个元件可能有问题，这行代码要用某一个函数处理一下，这个可以提醒开发者有一些隐患，这个里面已经包含一些问题，写的时候不用说自己要去跑来跑去的，把所有东西都折腾一次。错误日志是 web公司强项，所有错误都在自己的服务器上，但是有产生另外一个问题，同样分布在很多机器上，可能尤其是有运维人员维护并不是每台服务器都能上去，我们开发了这样一个工具，目的把所有出现错误日志抓下来，会把每一个当时出错现场涉及每行代码留下来，把每个当时涉及变量值保留下来，包括用户当时访问这个的时候带着各式各样变量之类的，让我们的程序员可以专注于说在一个地方发现所有问题，比如说我上线了，代码上线出没出错，首先要高优先级错误，我刷半个小时发现没有错误，可能出新一两个其他的东西，看一看，是我还是其他人，出去是其他人可以通知他一下，让程序员调试里面解脱了，包括出错怎么回事，点开可以看到当时出错用户请求传过来的东西，大多数时候可以改程序不用做本地环境复建等等。
另外我们也需要一些提高网站效率的工具，豆瓣资源少不光指人，包括我们服务器也很少，所以服务器上面程序执行效率对我们来说意义很重大，可以帮我们省很多钱，我们很早的时候做了一个工具，可以在线跑，刷一个页面，底层有哪些语句，运行情况怎么样，哪些是热点，执行特别多，花费时间特别长等等之类的，这个是对我们非常有效率的工具，用了这个工具以后平均访问时间保持在一个比较小的范围之内。这些工具还是需要人去执行。我们希望这个工具让计算机自动做，我们可以做更多事了，最简单web测试，我们把它框架建设起来，也建立起来自动化的方式，之前程序员一个一个测试，跟我们报表结合起来，只有在程序员做完以后提交，提交以后程序自动考，没有消息就是好消息，没有收到邮件说明你的代码很好已经通过了，如果收到邮件就要赶紧修，所有后面人也会收到同样报告，这里面只有功能失效才会发警告信。
说了这么多东西，但是我觉得最核心一个，也是对豆瓣来说保持开发团队创造力的一个很重要方面，就是我们给大家提供很灵活选择空间，回想一下现象独立开发，创业团队高效率原因，一心铺到上面去，他做的是一个全新前人没有做过的事情，因为没有前人经验，所以从用户角度对这个东西做设想，分析所有里面利益，他会选择一个最好的方案去做，这个过程中如果没有这些东西只给他限定一条路线，你只能用python就不好玩了，我们希望程序员有一个更灵活选择空间，希望团队能够不断接触新的机制，技术，把这些技术应用到豆瓣开发里面来。
我们有一些基础的设施，就是通过这种方式逐渐实现起来的，比如说我们有一个分布式数据库方案，我们内部也做了一些其他东西，这个东西接口非常简单，只有放进去，取出来，删除就这么几个操作，有了这样基础设施开发者有省事了，这个时提高效率非常重要的方面。包括前面说的我们可以自由选择设计方案，这个自由也是有限度我们公司也有架构师，我们会一起讨论这个新项目打算怎么做，选择这个东西跟现有有什么好处，所有东西都是在大家广泛沟通之下达成共识，比如说豆瓣有一些项目是用django做的，还有一些其他的，类似的也有，我们开发方式，豆瓣是一个非典型，用了一个python，但是python也不是必选项，有用C的，有一个算法R，这些东西也都有，通过给大家更好的选择空间我们希望避免我们内部架构，技术僵化，希望提供一个更像创业团队自由用最好的方式把这个事做起来。
评论