漫谈互联网产品开发

每个公司都有自己的产品开发规范,我自己也大概想了下,比较适合小团队。

借鉴Unix的设计哲学:一个工具只做好一件事,并提供接口。放到产品开发就是:产品可以被划分成多个模块,每个模块都有相应的API。这样就能做到分工明确和解耦。

三层架构

表现层

web / mobile / app …

API层

user / article / comment / …

基础服务层

db / queue / memcache / …

如果使用GAE的话,就不用花心思去构建基础服务层了。这样就只剩下表现层和API层。

分工

每个人都要负责产品的一部分,有两种构建方式:水平构建和垂直构建

垂直构建

假如我负责用户系统,则所有与用户相关的事情都由我来完成,从前端到后端,包括API,页面展示,互动等等。这样做的话,对开发人员的要求比较高,需要同时对前后台都比较熟悉。但能减少沟通成本,提高开发效率。假如用户系统出现了一个bug,我就能很快地修复,因为我最熟悉,且所有与用户相关的都由我负责。

水平构建

这也是大部分公司采用的方法,把开发人员分为前端/后端等等。前端的任务就是负责页面的展示和交互,后端开发人员负责API的构建,可能还会有专门的DBA。这样做的好处是可以发挥每个人的特长。但也有不少问题,比如用户系统出现了一个bug,前端相信自己的程序没有问题,就会把问题推给后端,后端查看了一遍也觉得没问题,可能又会把问题推回去。这样一来二去,不仅浪费时间,影响效率,还会破坏团队的氛围。

假如又有了一项新任务,是开发一个评论系统,前端可能1天就把页面做完了,然后就干别的事去了,结果后端花了4天才把API搞定。然后前端又要从别的地方把心收回来,阅读API文档,再整合,又耽搁了不少时间。这就有点不够敏捷了。

项目管理

我推荐使用Basecamp+Campfire+github。Basecamp用来管理项目;Campfire是团队讨论的地方(已与Basecamp集成),可以开设多个版块;github用来管理源码。

一个高效的开发者最不能接受的就是被打断,我好不容易进入了状态,结果被迫去跟你讨论一个不太重要的问题,这简直是谋杀,所以开发项目时最好把IM关掉,或者设置成离开状态。

dropbox可以作为辅助工具,用来在团队内部共享资料。

github的开发流程,可以参考此文

Tips

  • frontController要尽可能的薄,通常只需负责渲染页面
  • 使用hmvc将各个页面模块组合成一个页面
  • 可以使用内部REST的方式来合并多个REST请求
  • API层可以模拟http的403状态码来减少数据传输

暂时就想到这些了,实际情况肯定要复杂地多。有哪些地方可以改进,或者根本就不现实,欢迎指出 :)


--EOF--

若无特别说明,本站文章均为原创,转载请保留链接,谢谢