聊聊程序员那些【越早知道越好】的道理或者建议-程序员如何提升自己-Toy模板网

这篇具有很好参考价值的文章主要介绍了聊聊程序员那些【越早知道越好】的道理或者建议-程序员如何提升自己。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

1 让自己闲起来

1.1 提升自己肌肉和神经的反应，甚至到达机械式反应。

比如好好学习ide的使用和快捷键，以及一些常用的命令。

写一个实体类：Alt+Insert，shift+ ↓ ↓ ↓（或者ctrl+a全选），回车
把代码封装成方法：Ctrl + Alt + M
代码格式化：Ctrl + Alt + L
删除无用的导包：ctrl+alt+o
构建项目：ctrl+f9
…

1.2 使用，并不断引入各种偷懒工具

比如

mybatis generate
lombok
比如引入自动化工具，使用excel函数，python工具等快速处理测试数据。
…

1.3 不要做人嫁衣收集好人卡成瘾

要产品出文档才开始做，文档没写的一律不做，等待开会
你要对接别人的，给文档才开发，不给对接文档，一律不开始.
别人对接你的，先开会告知，给出文档，甚至给mock接口，请大家帮我评估下我这个接口对不对，如果没问题我就按照这个做了

1.4 好好分析需求

不要打酱油，请提出各种问题质疑产品，遍历所有异常场景和逆向场景让产品砍掉.注意是所有，所有你能想到的和这个有关的都要提出来

1.5 估算的时候不要按照最乐观估算

老板问这接口多久好，两天做完，还是好像半天就可以，这个时候要犹豫要分析
1. 接口这么完美无缺毫无问题
2. 异常都考虑到了没
3. 逆向流程都考虑到了没
4. 有极端情况没
5. 产品改需求了,领导deadline不变怎么办
6. 单元测试包含了没，自测时间包含了、联调时间包含了?上线时间包含了? 审批时间包含了?
大概3天:
如果老板质疑
先列举出来步骤3的所有点
然后我估算了开发完成时间是这样的:
乐观1天，悲观5天，一般3天，综合考虑 (1+5+3x4) /6 三天
这是行业惯例，是非常多的教授学者专家研究出来的估算方法，国际上pmp，国内软考，二建都是这个
如果老板同事质疑你的估算，勇敢的拿出你详尽的分析啊，让老板砍需求：这样比起直接说1天的好处是，报错了，出事了，老板自己的锅，如果你直接估算一天，任何问题都是你的错。
…
好了，你之前想要半天去做的事情，现在有3天时间可以深挖业务，可以提升自己

空闲真的很重要

2 代码不要一遍写完

第一遍主要完善业务逻辑
第二遍主要修缮逻辑中的漏洞比如xxx=null，用户名为空，xxx属性不合法
第三遍梳理关联的业务逻辑比如提交订单改了，会不会影响其他业务，比如优惠卷，比如第三方支付°接口，比如通知业务报表业务。
第四遍业务回滚相关这个业务如何回滚，要不要回滚，这个回滚其他周边业务要不要回滚，一旦发生异常的情况，如何快速恢复，日志要记录哪些，数据要备份什么，第三方的问题，要不要保留调用日志以避免背锅
第五遍单元测试以及画图梳理所有分支
第六遍寻找leader ，产品各种人最终确认你的算法 (业务层面)对不对

3 不要口头承诺，也不接别人口头的需求

别人非要口头，找领导

领导流一气的，你自己记录然后发给需求提出人确认

需求包含点确认

不确认的发邮件主动确认

没邮件的发微信，直接找真人: xxx经理，这个需求我把握不准，大概梳理了下，你帮我看看?不确认的，做完了回复一句: 你好xxxx，我按照上次说的做完了老板说没有不包含的项目，全部做出来，那好

你帮我一起梳理出来所有的点，我能力有限怕遗漏
加时间加时间，做不完，抱歉，细节太多了

好了，现在有大量的时间提升编码能力了

编码能力有这几块

4 提升编码能力

4.1 逻辑思维能力，高效率编码能力，debug能力

逻辑思维能力，高效率编码能力，debug能力这个决定你能不能混，具体点就是

阿里巴巴代码规范
代码优雅和消除if
effect java /thinking in java/on java 等书
debug能力这个单独拎出来重点讲讲：程序员就是能够依靠debug 找出奇奇怪怪bug的原因并修复。写程序其实很简单，写的不好逻辑正常就行，逻辑混乱能够保证不出bug也还行而出现了一个bug，你能找出来，甚至比别人快，别人几天搞不定，你看几眼，搞定。看前面那些规范和书籍可以让写出更少的bug，而debug能力让你解决那些bug，不光是你，也包括别人奇怪又痛苦的bug。如何学呢?
1. 第一为了debug而debug
  比如写一个双层for循环，先猜测第1次循环变量a=? b=? 输出什么? 然后打一个断点看下是不是这样。在逻辑思维锻炼中学习debug
2. 第二不知道怎么打断点，打一大堆断点，慢慢next调试
3. 第三先分析可能的原因，然后尝试只在必要的地方打断点调试
4. 当然实在不知道怎么用debug，那就用system.out.println好了用好syso只也不错
  自己的代码写的多了，然后是看别人代码或者你有的看不明白，那么打一个断点走一走
5. 看框架的源码，里面的一些编码的点可以膜拜一下
  
  在写好自己代码的前提下，看源码，debug源码会再次飞跃

4.2 业务分析能力，全局思考能力双，分析能力

业务分析能力，全局思考能力，分析能力这个决定你在公司混的好不好，提高办法：

首先，多沟通，了解真正的需求，而且和不同的人沟通，每一个人对同一个需求的诉求还tm不样，还等整合，如果意见冲突的时候，思考下谁是你“爸爸”(谁决定你的工资，你到底跟谁千活? )
别怕那些高大上的词语越大的老板越容易给你说一大堆高大上的，虚的很的话
比如如我们这是要做saas哦，我们要保证高可用。其实呢 saas就是 xxx管理系统，高可用就是挂了优雅的重启让客户无感，比如你系统很垃圾1秒钟挂一次，但是重启只要花0.01秒可用性达到了99.99%
接着警惕各种绝对的词语我们这个系统很重要可靠性必须百分100%，(央行，阿里，谷歌都做不到100%，年薪几百万的架构师都无法保证，稳点，有自知之明)，那么老板说的百分百是什么意思呢
1. 不要出错，不要出问题，一旦出bug，大事化小，小事化了，别影响老板年终奖
2. 好好的检查代码，分析各种场景分支，别漏了还是做得到的
3. 提前知道哪些地方可能出错，然后找到产品和老板商量对策也并不难
4. 对策是你提出来了，体现了你思维能力，对策是老板和产品定的，锅他们自己背
5. 不知道什么问题的，那记录好日志，第一时间知道问题在哪，出问题的订单号是哪个到事情求助大佬帮忙解决
6. 真的出问题了，能不能先人肉运维，能不能先人肉编码先保证老板的年终奖，先搞定客户的燃眉之急
7. 真的出问题了，除了你的问题，会不会有产品设计方面的问题，运维启动的方式、网络波动、还有开源框架的bug等原因
业务思考模式：
1. 提高容错率；总价值不变，减少工时
2. 做需求的时候，沟通的时候问清楚所有内容，所有异常情况都一起在明面上讨论
3. 一开始的时候，就让开发直接参与需求会议，甚至售前会议。销售和商务期间就可以准备起来。
4. 你主动要求参与那些本来没安排你参加的会议第一提升老板的好感值；第二让你知道更多业务细节，信息的传播有很多噪音和丢帧，导致你做出来的不对，但是程序员处于弱势地位，到时候锅甩给你。如果你一开始就去沟通了解需求，那就不好甩给你了，而且你的工作更高的概率做的事对的。第三，有准备。一个是技术上的准备，第二个是心理上的准备。
如果你在一个甲方公司，那你需要思考你的代码
1. 如何准确的，可控的执行
2. 如何保证这个业务不出错
3. 如果出错了，怎么保证伤害最小
4. 如果出错了，怎么保证责任分明
5. 如果这次出错，下一次不会再次出错
6. 如果这次出错，下次也会出错，能不能延长出错的间隔或者出错的概率7如果啥都做不了，证明你尽力了，而不是当了逃兵

4.3 算法数据结构能力

大厂必备！！！这个决定你能不能跳槽

稍微好点的公司，基本都会靠你算法数据结构比如

现在要求查询快，arraylist 现在要求插入快 linkedlista，但测试过差不多的，arraylist还快一些，因为听说是arraylist更好的利用cpu缓存
接下来linkedlist 需要固定顺序的时候用 hashmap呢 concurrenthashmap呢
贪心算法呢，雪花算法呢
…

4.4 架构思维能力

一提到架构，估计很多程序员会立马心生敬畏，觉得这是一个很高端、很难、很有挑战的事情。和编程相比，架构更多的是关注宏观层面，虽然会有一些挑战，但有些时候，架构的“世界”在复杂度上可能还不如编码上的细枝末节那么大。

简单来说，架构表达的是一种关系，是多个现实元素之间的关系。这里面有两个关键词：关系、现实。其中，“关系”很好理解，就是不同事物之间以什么样的形式共存。而“现实”经常容易被人忽视，因为它显得很平常。但是，如果你在做架构的时候，对于某些现实的定义不精准的话，那么，后面的工作大概率也是错的。

要想做好架构，第一步就要先明确你当前要解决的问题，或者要达成的目标，并且弄清楚其中涉及到的相关概念所表达的业务含义。接下来jiushi架构的过程其实也就是建模的过程。所谓建模，就是进一步细化当前的事物，并且基于所得的信息做相关的延展和规划，循序渐进，得到一个完整的、可执行的方案的过程。

所谓建模，就是进一步细化当前的事物，并且基于所得的信息做相关的延展和规划，循序渐进，得到一个完整的、可执行的方案的过程。

在这个过程中，会涉及到分解、集成、复用、分层、抽象、结构化以及迭代。

**第一步：搞清楚要解决的现实问题。**当你拿到一个稍具规模的功能后，需要先弄清楚这个功能要解决的问题是什么，不要一上来就写代码或者找现成的解决方案。总是依样画葫芦的话，很难培养出自己的架构思维。
**第二步：确定边界。**你需要考虑问题所在的场景中有哪些输入数据，最终输出的又是什么，这样就把问题的边界给定下来了。
**第三步：用分解、抽象、结构化的思维来拆分问题，并梳理好每个流程。**你需要把问题进行拆解，看看解决了哪些小问题之后，这个问题就能被解决。然后，再思考每一个小问题你是否有解决方案。如果有，你可以把中间的逻辑用流程图画出来。

如果逻辑太复杂，那就说明你设置的问题的颗粒度还是太大，继续拆就好了。如果某个小问题没有解决方案，同样继续拆，直到有解决方案为止。
**第四步：借助集成、复用、分层思维给出你认为最合理的技术实现方案，形成最终一份完整的架构。**你需要根据自己的技术储备，针对每一个问题给出具体的技术实现方案，选择你认为最简单、高效的一个即可。然后把所有问题的解决方案放在一起看，提炼可复用的部分出来，并考虑用什么形式进行封装。可以是一个简单的库，也可以是一个完整的框架，或是 API 等等。
**第五步：根据对未来的预判对架构方案进行局部修正，直到合理。**你需要根据自己对业务的理解，和与产品经理、业务方的沟通，预判一下后续可能的扩展点，看当前的设计是否能满足。如果不能满足的话，就逐级逆向倒推父问题，直到找到与这个新的扩展点相关的根问题，停下来把这个根问题下面的子问题全部重新设计一下。然后再重复第四步，直到得到一个当下看起来完全满足预期的方案。