工作想法小计 (2)：2/14 - 2/18

1. 接口文档没有改

接口文档不仅是写给自己也是写给调用的人，交付的东西不是代码改完就完了，想要让别人少问，文档得先写好。

1. 部署的服务配置文档要记录

做好记录，方便自己，方便他人

1. 想要根据并发设计写一个包，还是很难的，不熟练

看了并发的文章，想要设计一个基于通信共享数据的代码，还不是很会，但必须得有这个设计思维

1. 想要设计代码，之前那些链路式，什么设计都想不起来，感觉很零散，不够熟练

不想在写简单的业务，想要封装出有设计的代码，之前学了很多设计，看了很多设计，但是到真的自己要开发的时候，想不出来。源码还得多看，代码还得多写，不是一天达成的。

1. 应该先分析一下别人的做法，再讲自己的方法，不然会觉得等着说我这个更好的方法

在跟别人沟通方案的时候，往往会觉得自己的方案比较好，而且在自己提问的时候。这个时候不要急于讲出自己的想法，而是认真听完对方的方案，给出合理的评价或建议，然后再说出自己的解决方案，更合适。

1. 想要和自己设计的差不多，十分困难，但是得追求。必须追求

一直追求先设计文档，再代码流程图(伪代码)，再写单元测试，最后写代码。这种方式，我只能做到第二步，第三步就写不出来了。而且最后写出来的代码和第一步的设计差很多，很难，但我坚信这是写代码的最佳逻辑。

1. 大胆地说出想法

不要畏畏缩缩，讲出自己的想法，真诚的沟通，说不定有意向不到的收获，不然受伤的都是自己。

1. 学链路追踪，从 tracing->Opentracing->OpenCensus->OpenTelemetry 现在学习要开始注重知识的框架搭建，而不是只为了会而已

想要往高级工程师走，不能再 CURD，必须建立并总结自己的知识框架。

1. 项目也好，产品也罢，进度的跟进，不同项目之间的穿插开发。即考验 leader 安排工作的能力，也考验开发汇报，进度安排的沟通能力。

2. 好的代码逻辑，从命名开始

写代码其实就是写文章，好的命名不仅让自己看得懂，让别人也可以看得懂，我坚信这一点。

1. 做得不够好，我就直说，从目标出发，然后提出来想要给你提点意见，看你要不要聊，要聊我就做，不聊再说

如果同事做得不够好，应该站在帮助他的角度，说明问题，而不是嘲笑或者是故意让他错追责。当然，如果别人不在乎，也不要热脸贴冷屁股。

1. 对一个事情的专业程度和认真程度是 2 码事

一个人专业，做事情不认真，或者懒散，我认为不是一个高级工程师该有的做法。更不要以为自己专业，就可以随意。

1. 多文档阅读整理，转换为自己的文档，这个能力是很重要的

别人的文档终究是被人的，怎么总结别人的转换为自己的，需要提升这个能力。

1. 工作完成度的至高境界，交付出去的时候，无需校验，无需转换，直接用。别人能够直接用，是一件很爽的事情。或许自己当下膈应，但别人或许会对你有不一样的看法。

做事情不要嫌麻烦，不要一直觉得做事吃亏，幸运会不期而遇。

1. 当时间充裕的时候，应该对自己交付的东西，无论是代码还是文档，都应进行打磨

当你做每件事都只到完成，不再往深地想想怎样做会更好，就不会知道另一个层次会碰到什么问题。久而久之，就会觉得没趣，每天都是做重复的事。想要突破，无非每件事比别人多做一点点。

1. 把细节记录下来，5 年之后，无论如何都能出一本书，只不过是文笔的区别而已

回想过去的一年的当下，你做了什么？回想前年的当下，你做了什么？不是你写不出来，而是没有积累。我还留着高三时候给自己打气的话，曾经的自己，那么地努力过。记录下来平时的细节，回顾的时候，会显得尤为重要。

1. 写单元测试绝对有用，奇奇怪怪的问题都会冒出来，因为有一些问题我们习以为常，很容易忽略

单元测试很多人嫌麻烦，要做很多设计，甚至写的比自己的代码还多。但是，只有写了单元测试，测了覆盖率，才会注意到自己之前习以为常对待的地方原来也有可能出现问题的。没有什么很难，没什么麻烦，只有自己愿不愿意去做。

1. 单元测试的状态重置，会很让开发人员注意，初始化的情况

单元测试写起来，碰到的一个主要问题就是每个参数的状态，初始化问题尤为明显，会让你反复思考，为什么这个单元测试可以，那个不行，往往是初始化的时候出的问题。