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