程序员8个优秀习惯成为大佬
1、引入新的技术栈的时候，要以官方文档为主
在项目里，无论使用新的 jar 包，还是用新的中间件，一定要去看官方文档。
比如，如果你想要对 SpringBoot2 写的代码进行单元测试，JUnit 版本你可能已经是 5 7。但你搜到的网上文章很可能会告诉你测试用例需要注解但是官方文档说了，其实如果你用 JUnit5，就不用加这个注解了，加了反而可能引起不必要的冲突。所以，官方文档对新技术的引入是唯一的参考金标准
2、一定要悄悄地把代码测的没问题了再交付
在职场上，什么样的人才能快速成长、快速得到重用?答案是可靠的人。那就程序员来说，什么样的人才算是可靠的人?答案是交付可靠的技术产品。
那可靠的产品第一评估标准就是 bug 少。这个 bug少是别人评估的，而不是自己评估的。无论咱们自己代码实现成什么样子，哪怕是代码写的还不完美，但是，只要咱们通过自测，在提交之前尽可能把问题解决掉，让别人少发现你的错误，尤其是低级bug，那么你才是一位可靠的程序员。所以，交付任务前，一定要自己把代码全方位地测试一遍，保证自己有着优秀的口碑才好。
3、打日志的时候尽可能把输入、输出以及耗时都打印出来
我们打日志的目的是什么?是为了定位问题的。问题有哪些?其实大体就两种，逻辑问题和性能问题。逻辑问题，我们如果打印了输入和输出，那么根据业务规则，这么一对照就能很容易定位到问题。性能问题，我们无论是通过像 grep、sort 等 shell 命令去直接对日志做个过滤加排序，还是通过日志搜集加日志搜索等工具，都能很容易的发现到问题。甚至还可以和监控系统联合起来，直接做预警。所以，打日志的时候，我们要记得把输入和输出以及时间都打印出来
4、学好 Git
Git 这东西太重要了。现在的团队开发，用 Git 管理各种代码版本，代码分支。如果你用不好 Git，很容易就会因为合并代码、升级版本等情况，产生出许多没必要的 bugo
一个用不好 Git 的团队，可能每次上线，都会带来那么几个莫名其妙的问题。
5、优先实现功能，性能问题或许没那么着急
我们都知道if-else语句是最常用的分支语句，其特点就是逐一判断，既然是判断就会消耗时间，然而对于-些处理并不是每个分支都是均匀执行的，如果你把频繁执行的相应分支放到后面，势必就需要执行较多前面的逐一判断，从而降低代码执行效率。所以我们要对各个分支的执行频率进行评估，把最有可能执行的放在判断语句前面执行。同样对于分支语句多级嵌套的情况，我们需要把频率性对较高的放到外层，频率低的放内层，这样减少不必要的外层判断。
6、先实现最确定的需求，不确定或者模糊的需求先往后放
实现需求的先后顺序，注意一定要以需求的可靠程度为准。
在分配给我们的需求里一般分两类
有的需求是我们和产品经理都非常明确的需求:
也有的需求比较模糊: 开会讨论时大家都觉得没什么问题，但是一到代码实现的时候，就发现还存在很多问题。
这时候，咱们应对的技巧是，先对这些需求搭一个统一的架子，把已经非常明确的需求先开发出来。由干架子搭建出来了，这时候再和产品经理讨论那些模糊的需求，很容易就能让产品明白困难的地方，这样就可以把沟通难度降到最低。
7、主动找项目里的问题并给出解决方案
问题是什么?问题就是在实践过程中需要解决的东西把这些问题一个个找出来，等决掉，这些解决问题中产生出来的方案，全会形成推动项目前进的推动力。那么产生这些推动力的你自己，一定会从中获益良多。
8、评估开发周期，要留出冗余时间
留出冗余时间的目的很明确，在咱们开发的时候，遇到的意外情况太多了:
需求又双最毅变了
团队人员有变化
当初估算的时间乐观了
这个功能需要动老代码
需要跨团队合作开发
领导说“加个小功能”，领导认为这个小功能不影响0开发周期(此处省略二百字)
所以，冗余时间是要留出来的。留出的冗余时间不等于摸鱼时间，开发还是按照正常的节奏干，早做完早交付。