点击上方蓝色字体，选择“置顶公众号”
一起自学，一起进步
时间过的挺快，不知不觉我已经实习了大半年了（从大三下学期到大四上）。在实习的过程中，我明白了很多道理，也有些许感悟。接下来就分享职场上一些好习惯，以及编码好习惯。
职场好习惯
养成写单测的习惯（学习一下 TDD 开发），可以减少很多在 qa、预发环境上测试的时间。在本地发现问题，而不是等到在 qa、预发环境上发现问题。
写了东西一定要用单测测一下。测试之前要想好测试用例，尽量不要漏测了某个分支流。要细心和严谨。
为方便排查问题，打印日志要记录当时程序执行的上下文信息。
凡是运营、产品让我们手工操作的，我们一定要在文档上做好记录，记录好关键信息，特别是具体的操作时间，操作了哪些表，哪些字段等等，越详细越好。
我们从日常的工作中就严格要求自己，才能形成专业的专业素养，带有“肌肉记忆”的专业素养。
从小的问题引起注意，从而避免更大隐患的发生。
技术方案可以多花时间去思考，可以偏理论一些。真正开发的过程中，要以先完成项目目标为首要任务，如果还有时间可以对写的代码进行一些重构和优化。
在需求开发中，不要你以为的你以为，要反复 check，找人具体确认。而且要把确认后的结果同步到群里。开发中要切记信息透明化。
对于开发中的事要反复 check。
遇到觉得困难的事不要慌，理清思路，做下去。遇到解决不掉的问题，可以多去请教同事。在刚入职场时，多问同事是你主动性的表现，如果你每天什么都不问，你会让你的 TL 发慌。所以有问题就即时问，反馈出来，没有什么大不了的。反而是如果你把问题憋着不问，你的 TL 才觉得你有问题。
做一个方案时，要有一个懂全局的人指挥，如果是每个人都做一块，最后合起来时就会存在各种问题（可能是代码导致的、也可能是沟通不到位，信息闭环导致的）。
12.测试接口调用时，要把返回值打印出来，看是否和预期值一样。
千万不要在 merge 分支上写代码，要在自己的 feature、fixhot 分支上改代码。
Push 代码前先 pull 一下该分支上最新的代码，这样可以减少不必要的 merge。
在项目的 api 包里修改了代码后，需要重新打一个 api 包的版本，要不然会导致 dubbo 调用失败。
在公司中结果驱动，要注意结果产出，业务方向上要有全局观。你的领导并不会关注你的过程多么漂亮，他只会关注你在规定的截止日期前，有没有让他看到实际的产出。
信息同步，遇到问题要去推动，想办法去解决。
沟通要到位，有什么问题就要去主动沟通，协调，避免自以为的自以为，要反复 check。
当你主导一个会议时，提前把一些内容准备好，往节约大家时间方面的细节去想。
写 PPT 时技术和生活结合，不要照着读，要有自己的理解和想法。
主动沟通，理解上级没有说出的含义。要区分对待开放性的需求，多去想，主动性多一些。
要关注报警的信息，可以忽略的告警，也需要在群里同步下。
修改老接口时，要评估对其他系统影响。
在解决线上问题或客诉后，要及时把处理结果以及引起问题的原因同步给 TL。
要正直、与人为善，多帮助别人。
不要太浮躁追求眼前利益，要懂得长期沉淀自己的一些个人技能。
总结
在工作的过程中，我体验最深的就是规范了。不管是发布规范、开发规范还是技术方案的规范等，我们都要去敬畏这些规范，规范都是一些精华的总结，遵守规范可能会让我们少踩一些坑。我觉得上面这些内容就可以作为职场规范来约束我们，让我们形成一种职场的肌肉记忆，在潜意识中驱动我们走的更远。
▼
往期精彩回顾
▼
END
如果读完觉得有收获的话，欢迎点【好看】，关注【Java知其所以然】，查阅更多精彩历史！！！
让我“好看” 
490
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
