程序员职业生涯得到的经验教训

【程序员职业生涯得到的经验教训】 每天都各种教训,蠢得我自己都想抽死自己,多动脑子啊!

以下列表将长期更新:
核心:积极主动的去动脑子!!读上下文!比如在公司的一个页面点保存的时候最上方跳出了非常令人费解的报错信息,但其实在“保存”那个按钮附近解释了遇到类似的情况怎么处理。别一次一次的去打扰数据库,尽量一次性拿到所有数据!今天的血泪教训是一个要花两个多小时的脚本通过一次性把所有数据放到缓存速度从一个小时优化到了一分钟。出现问题先去找日志!一个脚本文件,从几个数据库拿数据最后整合成一个输出文件,为什么在同样的环境下直接运行可以用工具调用脚本就不行?找到日志在哪,去看看是不是这个脚本是不是卡在哪了?在终端输出一下这个进程当前的状态看是不是还在运行Debug一个运行时间很长的脚本。多print,每次for循环都print一次,这样至少你可以分辨是卡死了还是只是要循环的东西很多。然后profile,很多profile工具,不要自己瞎猜。不要盲目自信!今天在处理一个file save问题的时候我用了:with open(\u0026#39;XXX\u0026#39;, \u0026#39;w+\u0026#39;) as f: \u0026lt;do_something\u0026gt;我特么居然愚蠢的认为要写入到一个尚不存在在磁盘上的文件的时候一定要那个“+”! 更蠢的令人发指的是我的导师指出我这个错误的时候我还死不承认,说我记得是这样的啊。老师很nice的回答:恩,那可能不同平台不一样(先给我个台阶下),然后直接调出python文档指着描述打脸。。所以千万不要盲目自信啊!一定要自己先查一下。
搞清楚优先级!如果手头的两个任务都看上去很重要,优先完成有明确deadline的那个!再不确定就去问!不要犯傻!要积极主动的去跟进!不要一个脚本要跑几个小时就放在那不管了,别人不看你的代码就被动的等。如果情况比较急,积极的去跟进进度!跑了几个小时还没跑完你不得看看到底要多久吗?要一天咋办?也等?结果出来有bug呢?改完再来一次?别人忙没时间看你的代码不能去找另一个人吗?是不是蠢?一个东西在编译的时候想想还有什么其他可以做的事情好吗?不要就刷手机好吗?如果很慢的话想想怎么优化好吗?在不确定的时候,问!不知道应不应该把一个标记为不可用的机器重新启动?问!不确定任务的优先级?问!优先级在敏捷开发的环境里面是会变化的,可能你昨天还觉得这个任务不是很重要,今天就被一帮人追在屁股后面在每次根据对方的需求修改过代码以后重新读一遍代码!不要犯低级错误!如果你的导师或者老板问起你一件工作的进展,不要在继续按照自己想当然的进度工作了!肯定是他们觉得这件事情该出进展了才问你,赶紧停下手上的事情优先扑灭被问到的事。对于流程较长的公司,一定要尽量保证PR提上去就很完美,测试完整。否则别人让你改一点点就会导致很多back and forth和时间耗费。不要相信别人说的话,要自己亲自去验证。人的记忆是不可靠的。不要以为找到一个原因就解决一个问题了。有的问题是由多个原因造成的,比如有五个文件都出现了一个问题,如果找到原因解决了,要彻查是否这五个都得到了解决。因为有可能其中还有一些文件是由多个问题造成的。
自己看自己的代码看什么:
有没有无关的文件混进来?(有些ide会产生一些无关文件,设置好gitignore)变量名够不够具体?比如一个变量名是config_path,是什么东西的path?最好把业务逻辑也添加到变量名里面。同样的results就不如ServiceInstances具体什么时候该用全局变量?如果一个变量在同一个文件的两个以上的地方使用,按照情况可以考虑设置为全局变量。比如前面提到的config_path添加docstring,方便单元和整合测试
■网友
不要成为大公司流水线上的螺丝钉,要成为具备建立流水线能力的人


推荐阅读