你这里的 value 相当于全局变量

我情况和你差不多。MSSZ 离家近。

@RorschachZZZ 讨论的。但都是基于表面或者 bug 本身的讨论，深层次原因应该大家都知道但是不会拿出来说罢了。

@peterswan 我亲身经历过没有代码审核，快糙猛急着上线，等代码库到一定体量一个没更新一个版本都是提心吊胆，开发人员身心俱疲，最后项目烂了，公司黄了。
话说回来，我现在所待的地方，是有代码审核的，同样老板喜欢催上线，大佬们都相互给个 LGTM 都不仔细看。现在代码体量已经很大了，基本两天一个中性 bug 爆炸，一周一个大 bug 核爆。
流程是用来约束自觉性的，但是完全没有自觉性，有再多流程也没用。

从中长远来没有 code review 看就是自杀行为。
了解同事的技术水平，了解同事在做什么，肉眼抓 bug，等等等。 因为要急着上线不审代码的先不说技术水平如何， 工程水平肯定有提高空间。

长远来看不做 code review 就是自杀行为。
code review

可以参考 google 的 python coding style: https://github.com/google/styleguide/blob/gh-pages/pyguide.md#383-functions-and-methods
以前的公司也用过这个
“”“ Summary.

Details.

:arg1, int: i do this
:arg2, str: i do that
:return, list: i do both
"""
仅供参考

支持下苏州的互联网企业！

追求美

有需求的话就自己做“建房子的材料”和没需求的时候“为什么有这块墙在这里好碍眼“的区别。
有些时候用小型 RESTFUL 服务肯定是不会选 django 的。flask 相对灵活。当然也有灵活的代价。

@anonymoustian hbase batch get 目测满足你的需求。

直接读 hfile ？
问题描述的不是很清楚，再具体点：准备导出多大数据，数据的 rowkey 的分布大概是什么样的，导出时间要求多长。如果是一次性导出那就随便写个都行啊。

完全取决于心态。挪个地方从短期来看会感受到变化，长期的话会脱敏，最后该干嘛还是干嘛，你还是你。

if 是不能完全避免的，好的数据结构或算法可以让 if 的出现频率减少。
if 如果是在函数头部简短的做 condition check，个人觉得可以不写 else。但是如果不简短，尽量加 else。
如果有 elseif，那尽量加 else，即使 else block 里面什么都不做。

主要是运维。运维做的不好，集群少则两三天，多则一个月就要出大岔子。
回头想想，把一拖开源工具往锅里一扔做了大杂烩，也正常。
理想情况下，最好公司里就有某个工具的 contributor，这样有了问题直接找他 /她。

sapporo 黑啤

25

PEP8.
个人并不是很推荐 google 的 python 规范.

没有 最后代码库简直臭气熏天