我刚入行的时候，看到什么不爽的地方就会抱怨：
这个项目怎么还用这么老旧的技术？
这代码太烂了！
为什么没有写单元测试？
......
当然，随之而来的就是一些改进的想法：
换个新框架吧！
把这个模块重构一下！
把单元测试补上！
干脆重写吧！
......
实际上，我肯定不是第一个有这些想法的人，有这样念头的人好几年前就存在了。我的这些想法很可能已经被很多人提出过、思考过。
但是这些问题为什么还一直存在呢？
因为做起来很难，想到了，但是做不到。
我很喜欢的电视剧《士兵突击》中有一句话非常精辟。当时许三多从草原5班被调回702团本部，看见了团长办公室的一辆战车模型，非常喜欢。
看到这种情形，团长用浓重的武汉话地来了一句鸡汤：想要和得到，中间还有两个字，那就是做到。
许三多应该是听进去了，后来真的“做到”了，在进老A的时候把战车模型抱走了。
回到我们编程领域，对于这些难题，怎么才能“做到”呢？
如何才能找到办法，推动自己的想法，把它给实施成功了呢？
01
一个经典案例
1990年，杰瑞·斯特宁受命前往越南，他要在6个月内改善当地儿童营养不良的问题。
当时的研究报告普遍认为，营养不良原因是：卫生状况差、生活贫困、饮用水问题和缺乏营养品。这些都是正确的废话，关键是怎么改变呢？
杰瑞四处拜访村庄，调查各个地区的状况，测量各种儿童成长的数据， 他终于发现一组家庭的孩子，虽然家里穷，但是却比一般小孩更健康。
原因就在于喂养孩子的方法：少吃多餐，让孩子吃些小虾小蟹，以及在米饭中加入红薯叶。这正是杰瑞需要的，在不增加花费的情况下，提升孩子们的健康水平。
找到榜样以后，杰瑞找到村民，告诉大家：只要饭前洗手，少吃多餐，加入虾蟹和野菜作为辅食，孩子就能健康成长。这个简单的方法很快就被当地人接受了。
杰瑞抵达越南6个月后，当地65%的儿童营养问题得到改善，并且继续保持下去。
从杰瑞的案例可以看出，想做成一件事情，至少需要：
1. 让人砰然心动的前景
2. 成功的榜样
3. 和切实可行的办法。
02
回到编程领域
我们举一个编程领域的案例：如何在自己的部门推动建立一套自动化测试？
自动化测试的美妙前景不必多言：它可以给整个项目织起一张大网，如果新的代码破坏了已有功能，立刻就会被“捕获”，以后程序员修改代码会非常有安全感。
接下来找一个成功案例，让大家看到榜样的力量。
很不幸，你的部门在这一方面还是一穷二白。你需要身先士卒，把路子趟出来：
1. 哪些部分需要做自动化测试？
主推单元测试还是功能测试？
哪些地方单元测试投资回报率高？哪些地方最好用功能测试覆盖？
2. 需要用什么样的工具？
市面上有没有合适的？需要自己开发吗？
3. 在现在系统上搞自动化测试，有哪些障碍？
是不是需要重构代码才能写单元测试？遇到难以测试的组件怎么做Mock？
......
做为第一个吃螃蟹的人，把这些问题都解决了，是挺辛苦的。
在努力的路上，有志同道合的伙伴更好，有些开明的经理还会搞一个兴趣小组，大家一块儿研究，就看你有没有这样的好运了。
有了榜样成果以后，就是展示和说服了，你要展示出你是怎么做自动化测试的，遇到了哪些障碍，取得了哪些显著效果，例如通过自动化测试捕捉到了错误，修改代码更有信心， 代码覆盖率提升了xxx， 重构以后的代码更容易读，更容易维护等等。
用示例，图表，数字来说明，这样更容易打动人，最好要给出一个可以实施的步骤、评价方法和最佳实践，这样别人不用怎么思考，跟着做就行了。
和杰瑞在越南的情况不同，在编程领域改变一件东西更难，会遇到更多阻力，例如有人会说：太忙了，天天加班，没有时间。
所以想实施成功，得双管齐下：
1. 和部门/经理的KPI保证一致
部门也有优化流程，提升代码质量的KPI，和部门的目标保持一致/作为辅助，最容易成功。
2. 利益驱动
人是利己的，什么都比不上自我提升重要！学会UT，重构，Mock， 做了自动化测试，对于初级程序员来说，写到简历中也是不小的亮点啊，这样动力不就来了嘛！
03
总结
想推动着做成一件事情不容易啊，尤其你不是领导、没有权威的时候。你得想尽一切办法去建立远景，树立榜样，找到可以推广的方法。
但是难题才会有区分度，能够做成的就不是一般人了，绝对会脱颖而出了。
建议各位小伙伴找一个自己擅长的领域，尝试一下，收获是巨大的。
转载：https://blog.csdn.net/coderising/article/details/110152505