以下文章来源于Java知其以是然 ，作者帅飞
韶光过的挺快，不知不觉我已经演习了大半年了（从大三放学期到大四上）。在演习的过程中，我明白了很多道理，也有些许感悟。接下来就分享职场上一些好习气，以及编码好习气。
职场好习气养成写单测的习气（学习一下 TDD 开拓），可以减少很多在 qa、预发环境上测试的韶光。在本地创造问题，而不是等到在 qa、预发环境上创造问题。写了东西一定要用单测测一下。测试之前要想好测试用例，只管即便不要漏测了某个分支流。要细心和严谨。为方便排查问题，打印日志要记录当时程序实行的高下文信息。凡是运营、产品让我们手工操作的，我们一定要在文档上做好记录，记录好关键信息，特殊是详细的操作韶光，操作了哪些表，哪些字段等等，越详细越好。我们从日常的事情中就严格哀求自己，才能形成专业的专业素养，带有“肌肉影象”的专业素养。从小的问题引起把稳，从而避免更大隐患的发生。技能方案可以多花韶光去思考，可以偏理论一些。真正开拓的过程中，要以先完成项目目标为紧张任务，如果还有韶光可以对写的代码进行一些重构和优化。在需求开拓中，不要你以为的你以为，要反复 check，找人详细确认。而且要把确认后的结果同步到群里。开拓中要牢记信息透明化。对付开拓中的事要反复 check。碰着以为困难的事不要慌，理清思路，做下去。碰着办理不掉的问题，可以多去请教同事。在刚入职场时，多问同事是你主动性的表现，如果你每天什么都不问，你会让你的 TL 发慌。以是有问题就即时问，反馈出来，没有什么大不了的。反而是如果你把问题憋着不问，你的 TL 才以为你有问题。做一个方案时，要有一个懂全局的人指挥，如果是每个人都做一块，末了合起来时就会存在各种问题（可能是代码导致的、也可能是沟通不到位，信息闭环导致的）。12.测试接口调用时，要把返回值打印出来，看是否和预期值一样。
千万不要在 merge 分支上写代码，要在自己的 feature、fixhot 分支上改代码。Push 代码前先 pull 一下该分支上最新的代码，这样可以减少不必要的 merge。在项目的 api 包里修正了代码后，须要重新打一个 api 包的版本，要不然会导致 dubbo 调用失落败。在公司中结果驱动，要把稳结果产出，业务方向上要有全局不雅观。你的领导并不会关注你的过程多么俊秀，他只会关注你在规定的截止日期前，有没有让他看到实际的产出。信息同步，碰着问题要去推动，想办法去办理。沟通要到位，有什么问题就要去主动沟通，折衷，避免自以为的自以为，要反复 check。当你主导一个会议时，提前把一些内容准备好，往节约大家韶光方面的细节去想。写 PPT 时技能和生活结合，不要照着读，要有自己的理解和想法。主动沟通，理解上级没有说出的含义。要区分对待开放性的需求，多去想，主动性多一些。要关注报警的信息，可以忽略的告警，也须要在群里同步下。修正老接口时，要评估对其他系统影响。在办理线上问题或客诉后，要及时把处理结果以及引起问题的缘故原由同步给 TL。要正派、与人为善，多帮助别人。不要太暴躁追求面前利益，要懂得长期沉淀自己的一些个人技能。总结
在事情的过程中，我体验最深的便是规范了。不管是发布规范、开拓规范还是技能方案的规范等，我们都要去敬畏这些规范，规范都是一些精华的总结，遵守规范可能会让我们少踩一些坑。我以为上面这些内容就可以作为职场规范来约束我们，让我们形成一种职场的肌肉影象，在潜意识中驱动我们走的更远。
推举阅读
共勉：作为一名程序员你该当怎么提一个高质量的问题？