我剛入行的時候，看到什么不爽的地方就會抱怨：
這個專案怎么還用這么老舊的技術？
這代碼太爛了！
為什么沒有寫單元測驗？
......
當然，隨之而來的就是一些改進的想法：
換個新框架吧！
把這個模塊重構一下！
把單元測驗補上！
干脆重寫吧！
......
實際上，我肯定不是第一個有這些想法的人，有這樣念頭的人好幾年前就存在了，我的這些想法很可能已經被很多人提出過、思考過，
但是這些問題為什么還一直存在呢？
因為做起來很難，想到了，但是做不到，
我很喜歡的電視劇《士兵突擊》中有一句話非常精辟，當時許三多從草原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://www.uj5u.com/qita/232652.html
標籤：其他
上一篇：穩坐開發領域霸主之位，揭秘C語言無可取代的幾大原因！
下一篇：技術經理成長復盤-處理線上問題