写在前面的话：
由于每天要坐2小时地铁，所以有时会在地铁上阅读一些文章，在这里做个分享。
以下这几篇文章表达的意思相近，所以我将其都归在这一期里面。
PS：时间比较仓促，加上高中毕业后就没怎么写东西了，不论是思绪还是排版，写得都比较乱，望见谅。以后会锻炼自己这方面的能力。
本周推荐阅读(第二期)
推荐阅读
个人感想
沟通能力
学会聆听：聆听和尊重他人意见是沟通能顺利进行的前提。如果总是打断别人的发言，你的信任槽也会相应地减少。当别人不再信任你的时候，你的工作也会很难开展下去；
达成一致：沟通不是辩论赛，一味的坚持己见不见得是上策。沟通的最终目的是解决问题，需要彼此达成一致意见并通力合作；
换位思考：关于这点，我就直接引用一个大佬的观点：
Paul Graham 曾在他的书《黑客与画家》中写到：判断一个程序员是否具备“换位思考”的能力有一个好方法，那就是看他怎样向没有技术背景的人解释技术问题。
以下为摘抄信息：
程序员著名网站之一 StackOverflow 的两位创始人 Jeff Atwood 和 Joel Spolsky 都对此有正面的认识和见解。
Jeff 说：
成为一名杰出的程序员其实跟写代码没有太大关系。
做程序员确实需要一些技术能力，当然还要有坚韧不拔的精神。
但除此之外，更重要的还是要有良好的沟通技巧。
Jole 的观点：
勉强过得去的程序员跟杰出程序员的不同之处，不在于他们掌握了多少种编程语言，也不在于他们谁更擅长 Python 或 Java。
真正关键的是，他们能不能把他们的想法表达清楚，杰出的程序员通过说服别人来达成协作。
通过清晰的注释和技术文档，他们让其他程序员能够读懂他们的代码，这也意味着其他程序员能够重用他们的代码，而不必重新写过。
要不然，他们代码的价值就大打折扣了。
学习能力
犹记得我大一新生入学的时候参加过一个讲座，讲座的主题和内容都忘了，但台上一个师姐说的一句话至今仍然鞭策着我：“不要问我能教会你什么，要问自己能从我这里学到什么。”
刚进公司的时候，我接的任务也是经常延期，而且总是身陷“业务代码”之中（延伸阅读：天天写业务代码的程序员，怎么成为技术大牛，开始写技术代码？）。
后来，我厌倦每一次实现分页需求都要写两条几乎一模一样的SQL，所以研究了一下Mybatis分页拦截器；
后来，我厌倦每次前端传个日期参数进来后端都要手动转换一下，所以学了一下Spring的Converter；
后来，我厌倦每次都要拼接千篇一律的SQL语句，所以写了个自动拼接SQL的工具类（参考了某同事的写法）；
后来，我厌倦每次有新需求都要写机械代码（Entity、DTO、DAO等），所以写了个代码生成器脚本；
以上问题都是我在写业务代码过程中遇到的问题，以上产出的“副产品”就是我个人的收获，有些东西甚至可以帮助团队成员提高工作效率。
PS：当然，写业务代码本身的价值在于业务，而不是那些“副产品”。
就技术人而言，我更倾向于以技术痛点为驱动，解决对团队最有价值的技术问题。以团队利益为导向，顺势而为，可以持续为团队带来更大收益。
例如：（抛几块砖头）
- 测试环境隔三差五地崩，崩一次要花半天修复，有没有办法优化其结构？
- 每次新建项目都要植入上传图片的代码，有没有办法抽象出来？
- 每个项目都有定时任务，是否可以独立出来服务化或做成SDK？
- etc…
如果你没有对重复感到厌倦，那可能是已经麻木了，如温水里的青蛙。
经验
你不是有十年工作经验，你只是一个经验用了十年。
有的人，用一年的时间就获得了三年的工作经验（这里不是指那个加班梗……）。
就技术水平而言，我发现第二年开始我的技术已经出现停滞信号了。做的好像都是独立设计和实现某个模块/平台/系统的工作，但其本质都是需求进来产品出去，并没有涉及到很多新技术方面的知识或挑战。（PS：或者说，手撕需求的能力强了？）
所以我会不时地问自己：自己是不是那个一个经验用i++年的人？
然后就会强迫自己滚去学习了。
解决问题
发现/提出问题并不难，但对于发现/提出的问题，你做了什么？
对自己问这个问题，然后就可以知道自己是个行动派，还是抱怨派；
建立个人品牌
不要经常出现错别字(或<=1)：见字如见人；
尝试教导他人：教学相长，教导别人的同时也是让自己不断学习；
当别人对你产生信任，你要做什么事情都会变得简单；
总结
聆听他人意见：劳谦虚己，则附之者众；骄慢倨傲，则去之者多；
学会换位思考：用上帝视觉看待事情，用第一、第三人称视觉思考问题；
多与身边人对比：以铜为镜可以正衣冠，以人为镜可以明得失，以史为镜可以知兴衰；
敢于承担责任：世上哪有等你完全准备好以后才开始做的事情，你觉得完全准备好以后，可能已经散场了；
尝试教导他人：实践这一点将会包含以上所有内容，你是想成为可以1带5的王者，还是那条只会喊666的咸鱼？