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