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

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 代码不要一遍写完

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

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

别人非要口头，找领导

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

需求包含点确认

不确认的发邮件主动确认

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

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

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

编码能力有这几块

4 提升编码能力

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

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

1. 阿里巴巴代码规范

2. 代码优雅和消除if

3. effect java /thinking in java/on java 等书

4. 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 业务分析能力，全局思考能力双，分析能力

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

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

4.3 算法数据结构能力

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

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

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

4.4 架构思维能力

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

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

---

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

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

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

1. **第一步：搞清楚要解决的现实问题。**当你拿到一个稍具规模的功能后，需要先弄清楚这个功能要解决的问题是什么，不要一上来就写代码或者找现成的解决方案。总是依样画葫芦的话，很难培养出自己的架构思维。

2. **第二步：确定边界。**你需要考虑问题所在的场景中有哪些输入数据，最终输出的又是什么，这样就把问题的边界给定下来了。

3. **第三步：用分解、抽象、结构化的思维来拆分问题，并梳理好每个流程。**你需要把问题进行拆解，看看解决了哪些小问题之后，这个问题就能被解决。然后，再思考每一个小问题你是否有解决方案。如果有，你可以把中间的逻辑用流程图画出来。

   如果逻辑太复杂，那就说明你设置的问题的颗粒度还是太大，继续拆就好了。如果某个小问题没有解决方案，同样继续拆，直到有解决方案为止。

4. **第四步：借助集成、复用、分层思维给出你认为最合理的技术实现方案，形成最终一份完整的架构。**你需要根据自己的技术储备，针对每一个问题给出具体的技术实现方案，选择你认为最简单、高效的一个即可。然后把所有问题的解决方案放在一起看，提炼可复用的部分出来，并考虑用什么形式进行封装。可以是一个简单的库，也可以是一个完整的框架，或是 API 等等。

5. **第五步：根据对未来的预判对架构方案进行局部修正，直到合理。**你需要根据自己对业务的理解，和与产品经理、业务方的沟通，预判一下后续可能的扩展点，看当前的设计是否能满足。如果不能满足的话，就逐级逆向倒推父问题，直到找到与这个新的扩展点相关的根问题，停下来把这个根问题下面的子问题全部重新设计一下。然后再重复第四步，直到得到一个当下看起来完全满足预期的方案。

整个流程下来，你就完成了一次架构设计工作，这些工作可以帮助你培养自己的架构思维。等你慢慢熟练之后，也可以根据实际情况自行删减一些步骤。