稍微提几个可改进之处

2010-11-17 16:57:45 +08:00
 keakon
粗读了下Babel的源码,发现了一些问题。不过我说话比较直,意见可能会很难听。

首先是TopicHitHandler和PageHitHandler这2个用于计数的handler没有做事务处理。
如果一个主题同时被多个人浏览的话,会很容易冲突。而如果此时这个主题进行了其他修改,这些修改也很可能丢失。
至于其他修改的地方,我就没去找了,至少last_reply_by、last_modified这些字段就是为修改存在的。

其次是很多地方的性能可以做优化。
最明显的是很多模型的num字段实际上可以用key id来代替,get_by_id比query将近快1个数量级。
此外还有很多索引是可以去掉的,例如Member.password我就想不出要index的理由。
另外,GqlQuery的解析速度是很慢的(比Query慢20倍,还得小心被GQL注入),通常都会使用bind来重用的。

最后是代码风格。
我觉得model和它的操作应该写在一起,作为方法或类方法。但是Babel却将其分散在各处,有的是方法,有的是v2ex.babel.da里的函数,有的是直接写在controller中。
这种写法当然也是OK的,不过不知道Livid是否觉得维护起来很麻烦。如果新增或修改的功能涉及到model的变化,不得不到处搜索这些model、model name的usage,甚至memcache key。

而且由于代码的分散,可重用性也因而降低,因此Handler显得过于冗长,很难一眼看出做了哪些操作。
例如HomeHandler.get,恐怕没人能在30秒内看懂它做了哪些事————然而读完却发现所做之事实际上是很简单的。
至少在区分是否手机时,取数和渲染逻辑是大致一样的,很显然只要把memcache key和template file(或者直接用browser['ios'])作为参数就能提取出一个函数了。


意见就说这么多,总体来说Project Babel给我的感觉更像是一个从PHP以最快方式(或者说最小努力)移植到GAE/Python的项目,而不是针对GAE去设计的项目。
我觉得Livid应该在适当的时机尽早重构代码,不然随着功能的增多,维护势必会越来越难。
5528 次点击
所在节点    Project Babel
23 条回复
keakon
2010-11-17 20:20:47 +08:00
1. 使用task queue。一个实体保存成功后创建另一个task来更新下一个实体。文档里好像有个例子。

2. 实体一旦保存到数据库,它的实体组关系就不能变更了。因此你只能下载所有实体,删除所有实体,然后在上传时通过设置key的parent来构造实体组。
c
2010-11-17 20:27:57 +08:00
darasion
2010-11-17 21:07:01 +08:00
谢 @keakon @c 二位。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/4640

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX