标签：思维 时间 服务 process 专业 命名 一个 业务部 最好
防御式编程，不要相信任何人和服务。你要做好对自身的保护，号称4个9的AWS不也宕机了吗！
你所担心的事一定会发生，而且可能马上会发生。最近上了一些功能，你说好像这个地方可能会有问题，你最好赶紧看，也许马上就会有问题。
线上出现问题要放大处理，尤其是和数据、钱相关的，肯定有不合理的地方，特别准。
命名要专业一些，多用一些业务用语，少起一些 map process run等方法，要具体一些，见词知意。
接口定义要明确，做到只要看一下定义就知道写得是什么，不需要看实现基本就可预知你写得的是什么。如果还要看实现才能确定做了什么，那么你写的这个接口就有些失败。
重构很重要，但也要小步前进，如果抽出大段时间重构，十有八九会失败，还要受到业务部门的挑战。
重构还有一点作用，让你更加了解系统的来龙去脉。我在想对于新入职的员工，是否可以给他一个小模块，让他搞一点重构，通过这样的方式让他来了解系统。这有一个前提，leader要对新员工的代码review、负责。
我们工作环境是一个团队，这就要求我们要适当的帮助他人。但也注意，不要让别人背上的猴子跳到你背上，把别人的活都揽在自己身上，自己累的够怆，别人也没有成长。
测试人员信息获取更多应该来自产品，而不应该是开发人员，那样的话掺杂开发人员的代码思维，很有可能是错误的理解。这个吃过亏，测试人员让开发人员给讲逻辑，结果上线后发现与产品的初衷是想背离的。
最近订阅了很多技术公众号，大家写得都不错，也有很多干货。但有一个问题，就是知识不够系统不连贯，如果想深入的了解一个东西最好还是从纸质书籍下手。另外北京地铁是可以看书的，至少我上班的时间点还是能拿出书来看的，相对来说比刷朋友圈实惠一些。
标签：思维 时间 服务 process 专业 命名 一个 业务部 最好
原文地址：http://www.cnblogs.com/liweiby/p/thinking.html
