工做中的一些感悟

不知不觉工做已三年半，准确的说是三年零五个月。在这过程当中，在技术和业务上的成长，多多少少都会有一些，但最大的收获，仍是长见识。聊聊几点感觉吧。

学会向上汇报

别只顾埋头作事，要作“对”的事情。

这是我的情社会，你的领导也只是普通人，他不太会有大把的精力去关注底下的人天天具体干些什么事情，这种状况下，若是你只知道一味地埋头作事，即使作了不少，加班累成狗，可是领导压根不知道，是没有任何意义的，典型的吃力不讨好。不少时候是须要你主动向上汇报的！按期地跟领导保持正向沟通，积极反馈工做中遇到的问题以及本身的想法，让领导感知到你的付出，固然有产出是最好的了。

什么是“对”的事情？要有全局观，审时度势。当前领导最关心最迫切的事情，就是对的事情。举个栗子，随着用户量的快速增加，系统的压力愈来愈大，原有最初的系统逐渐暴露问题，甚至所以频繁出现线上故障。这个时候，若是领导发起了“系统压测”的任务，那么当务之急，压测就是最重要的事情，工做的重心应该以此为准。即使此时业务上也有不少新的需求，你也应该作取舍，不然即使你作了一大堆需求，此时的领导根本无暇顾及，他所关注的必然是压测的进度，千万不能捡了芝麻丢了西瓜。

打破局限，解决问题才是王道

在遇到紧急状况，如线上故障处理时，快速解决问题才是关键。有的时候咱们容易陷入程序员惯有的思惟里，遇到问题会习惯性地一上来就尝试用代码去解决，而忽略了一些非代码的简单处理方式，好比粘贴/复制、excel工具、sublime文本替换等。这里列举两个工做中的小例子，深有感悟。

栗子1：故障处理

在一次故障处理过程当中，须要对一批指定用户作一个操做，这个操做能够经过curl请求来完成，当前已有的是已经导出的以userId逐行排列的userIds.txt文件和请求的url，分别长下面这样子：

userIds.txt内容：
userId1
userId2
userId3
...
userIdn

url内容：
https://www.yangbing.club/${userId}/doing

当时的第一反应就是准备写个shell脚本或者Java的Job来搞这个事，自己逻辑简单，一层循环就能搞定，伪代码大体以下：

userIds <- userIds.txt
for userId in userIds:
	actualUrl = url.replace("${userId}", userId)
	curl -H 'Cooike: xxx' actualUrl

但恰恰shell又不太熟，还得调试，想一想就头大。此时组里新来的清华实习生给出了简单粗暴的方式，直接在userIds.txt文件上作文章，用sublime的文本替换功能，将文本中每一行，如第一行userId1的行首^替换为请求url中${userId}以前的子串curl -H 'Cooike: xxx' https://www.yangbing.club/，将行尾$替换为url中${userId}以后的子串**/doing**，这样就获得以下的结果文件：

curl -H 'Cooike: xxx' https://www.yangbing.club/userId1/doing
curl -H 'Cooike: xxx' https://www.yangbing.club/userId2/doing
curl -H 'Cooike: xxx' https://www.yangbing.club/userId3/doing
...
curl -H 'Cooike: xxx' https://www.yangbing.club/userIdn/doing

而后一行命令就能搞定：

sh userIds.txt

若是处理速度慢了想要并发，又能够经过split命令将userIds.txt按记录行数拆分红多个小文件，而后依次sh，利用操做系统的多进程并发处理。

回想这个事情的处理过程，咱们的最终目的实际是为不一样的userId生成对应的url，而后curl请求执行。程序员的固有思惟就是消除重复，尽量复用！对于这种userId不一样，有相同的url模板的典型case，很天然的想到用循环。而忽略了ctrl C/V这种“重复”的快捷方式。

栗子2：平常开发

产品有个导数据的需求，要将特定筛选条件下的用户列表导出为Excel文件。这自己并不难，一个常规的Job就能搞定了。

同事A的方案也很常规，算是比较天然的思路，大概构想了一下代码流程，相似这样：组织筛选代码逻辑，将符合条件的用户列表筛出来，而后将列表转换为行数组，并构建标题数组，再经过Excel三方库或公司已有的工具类，将数据写入Excel文件。在这过程当中，除了筛选条件的代码逻辑外，转为Excel工具须要的数据格式并生成Excel文件，看起来是最耗时的工做。

这看起来好像没啥问题，但笔者并无采用上述方案。咱们来看下这个需求，首先它是个一次性的，数据导出以后就完事了，也没有后续迭代；其次，Excel文件只是产品所须要结果的一种文件格式，咱们只要能确保最终给到产品的是Excel就行，至于咱们是经过代码生成Excel的方式，仍是借用Office Excel强大功能将其余格式的文件转换为Excel的方式，产品并不关心。而咱们又知道，Office Excel能够轻松支持将特定分隔符（如逗号、tab键）的文本文件导入为Excel，于是方案天然就变为：

先筛选出符合条件的用户列表，而后经过log.info将每一个用户记录User的各字段以逗号","分割打印一行，这样咱们就获得了初版数据——日志文件，大概长这样：

......// 启动日志
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] job start
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506672,"userName1","address1",2 
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506673,"userName2","address2",3 
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506674,"userName3","address3",2
......
2019-11-25 23:00:45 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506694,"userName100","address100",1
2019-11-25 23:00:45 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] has processed 100 users
2019-11-25 23:00:45 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] user info:10506694,"userName101","address101",1
......
2019-11-25 23:00:42 [INFO] [Thread-17] [org.sherlockyb.blogdemos.ExportUserJob] job end
......// job退出日志

这时候，强大的文本编辑工具sublime就登场了。能够看到，日志中除了含有user info的行尾是咱们须要的数据，其他都是无用信息，冗余数据处理分为以下几步：

• job起始和结束咱们一般会打印job start和job end，那么这两行分别以前和以后的内容能够直接删除
• 像has processed xxx users这种打印job进度的信息，能够经过正则**.*has processed [\d]+ users\n**替换为空串，这个地方须要注意一个细节，就是正则中要包含"\n"符号，不然替换后会留下空行，比较尴尬。
• 前面两步处理完后，就剩下数据行了，而后用正则**.*[org.sherlockyb.blogdemos.ExportUserJob] user info:**把无用的前缀替换为空串便可。
• 剩下的数据行其实就是标准的CSV格式文件了，改下后缀，而后打开文件，将内容复制到Excel文件便可。或者在打印日志时咱们用"\t"分割，这样在获得剩下的数据行时，能够直接复制到新建的Excel文件也是能够的 能够看到，这个方案的核心在于，经过Office Excel已有的强大功能，代替了经过写代码生成Excel的方式，从某种意义上说，这也是复用，只不过复用的不是现有代码，而是现有的软件功能，而这些强大的软件功能，一样也是别人写代码实现的，间接地复用了"已有代码"。

同事A后来听我跟他讲完个人实现方案，表示“秀了我一脸”，真实。。。。

用“好工具”，“用好”工具

好的工具能让咱们极大地提高作事效率。

之前我对于平常开发工具的认知就是，够用就行，不用太深究，专一代码和技术。直到后来，当我见识到周围的朋友如何熟练地经过各类工具快速达到目的的时候，感受真的被秀了一脸。

好的工具备哪些呢？笔者有个推荐清单：

• IntelliJ idea，真的比eclipse好用太多，用过的才知道。可配置各类经常使用快捷键，如项目切换、代码视图回退、代码跳转等
• Sublime，强大的文本编辑工具，平常的文本处理用它就行
• Excel，再普通不过了，基本用过pc的人都了解过一些基本用法，但又有多少人用过筛选、列隐藏、多列排序、指定分隔符导入文本数据等功能呢？多研究多使用，你会发现不同的天空。
• Alfred，mac下强大的搜索工具，真的很强大。在一个小小的命令框内，它能够快速定位本地文件，使用计算器、词典，等等。好比经过idea 项目名，你能够快速打开指定的idea项目，这比你每次点击File -> Open -> 选择项目目录 -> ok，但是要快的多！
• open-falcon，小米开源的监控平台，虽然使用上不太友好，但东西仍是挺全的，须要的监控指标和功能基本都有

除了上面列的，还有不少平常可用的工具，基本只要你能想到的，都会有。在挖掘新的可用工具的同时，对于已经常常在使用的工具，能够深究，也许你会发现不少好用的feature，用好它，让你事半功倍。

积极主动，要有owner精神

积极主动反映的是良好的工做态度，团队须要积极的氛围，领导更须要积极的人才。

owner精神，则须要较强的责任心，对所参与的业务以及团队负责的业务负责，开发时积极推进项目进度，协调各方优先级，确保项目如期高质量上线；遇到线上故障时，积极响应，确保在最短的时间内解除故障。

沟通很重要，对上和对下

没有什么事情是沟通解决不了的，若是有，就屡次沟通。

对上沟通，能让领导对你有所知，有所指望，可能还会有额外的指导，能及时暴露风险，尽早解决；对下沟通，能让你带的小伙伴感觉到温暖，知道你时刻在关注着他，这是正向反馈。另外，你也能及时了解他当前的情况，若有困惑，帮助他解决，让他少走弯路；若有新的想法，拿出来讨论，或许会给你带来新的启发。

爱钻研，有技术追求

我在面试的时候，常常会看这一点。对于爱钻研，有技术追求的候选人，他首先必定是自驱力不错的，由于技术钻研这个事儿纯粹是出于我的意愿，能坚持下来，不容易。其次，他对于技术是有好奇心的，好奇心会驱使他去研究这里面的细节，搞清楚原理，不会浮于表面。

反对过分设计与优化

技术架构必定是依托于业务的。

公司发展的不一样阶段，业务量级的不一样，所须要的技术架构是不同的。初创期，业务规模小，产品迭代速度快，此时须要的是快速支持，快速开发，好比不少统计数据的场景就直接实时计算了，后端服务可能就是一个单体应用，这些都是能够接受的；随着业务发展，业务形态多样化，用户量快速增加，致使系统压力、复杂度倍增，此时就须要考虑微服务拆分、分布式、性能优化、Redis缓存、分库拆表等技术方案了。

技术架构除了要考虑可否支持业务发展，技术先进性外，也要考虑成本，这里面既有数据库、服务节点等资源成本，也有开发成本，更多时候是取一种折中方案，收益最大化。

成也经验，败也经验

过去的经验能让咱们在处理新的问题时有参考依据，尽可能少走弯路，一般这是没问题的。但有一个误区是，过度相信此前的经验，认为那绝对是对的。工做中就遇到过这类case，关于thrift新增字段，是否须要设置为optional的，同事A很自信地认为用默认的required就行，由于以前这么干过没问题。但很快实验代表，新增required字段，会致使新老版本不兼容，call端会报异常。

经验有对有错，咱们须要有质疑心态，不能尽信之。

同步到原文