工程師懶惰的利與弊

懶惰被視為七宗罪之一，是個(gè)貶義詞，但在一定場(chǎng)景下，懶惰變成了褒義詞：在我看來，懶惰才是人類進(jìn)步的關(guān)鍵，正是因?yàn)閼校艅?chuàng)造出各種各樣的工具來提升效率。人們懶得走路，發(fā)明了自行車，后來懶得蹬車，就發(fā)明了汽車，最近連開車都懶得開了，于是出現(xiàn)了自動(dòng)駕駛汽車。對(duì)于工程師而言，懶惰也分兩種，這兩種類型的懶惰會(huì)使工程師的成長(zhǎng)出現(xiàn)截然不同的道路。

有利的懶惰

有利的懶惰是指討厭重復(fù)而低效的任務(wù)，自己懶得做，就讓工具做，將重復(fù)任務(wù)自動(dòng)化。有利的懶惰能夠極大地提高效率，節(jié)約時(shí)間。下面舉幾個(gè)例子：

CocoaPods

CocoaPods 是開發(fā) OS X 和 iOS 應(yīng)用程序時(shí)一個(gè)第三方庫的依賴管理工具。在 CocoaPods 出現(xiàn)之前，需要添加一個(gè)第三方庫需要以下操作：

下載第三方庫的代碼。

將第三方庫的代碼引入工程，并添加第三方庫所需的 Framework。

解決庫與庫之間、庫與工程之間的依賴關(guān)系，檢測(cè)重復(fù)添加的 Framework。

如果第三方庫有更新，需要將庫從工程中刪除，并重復(fù)上面的步驟。

哦買噶，這些重復(fù)繁瑣的工作能把人煩死，有些“懶惰”的工程師無法忍受這種情況，于是 CocoaPods 出現(xiàn)了，它能夠自動(dòng)下載配置文件中指定的第三方庫，處理庫與庫之間的依賴關(guān)系，并通過新建一個(gè) xcworkspace 的方式將第三方庫同工程連接起來。哈利路亞，感覺整個(gè)世界清凈了。

ARC 與 Block

ARC 為什么會(huì)出現(xiàn)呢？因?yàn)樵?MRC 下每次都要 retain/release 真是太麻煩了，而且還容易不配對(duì)導(dǎo)致內(nèi)存泄露，估計(jì)蘋果的工程師都寫煩了，既然編譯器能夠識(shí)別出對(duì)象的生命周期，那就讓編譯器去做內(nèi)存管理吧，簡(jiǎn)單省事。有人可能不放心把內(nèi)存管理交給編譯器，你放心，在識(shí)別對(duì)象生命周期這件事上，編譯器比你厲害，再厲害的開發(fā)者也有可能因?yàn)橐粫r(shí)疏忽而遺漏，但編譯器不會(huì)。另外，會(huì)有人認(rèn)為 ARC 會(huì)影響性能，這其實(shí)是不理解 ARC 的原理：ARC 不是垃圾回收，只是自動(dòng)幫你寫 retain/release，而且寫 retain/relese 時(shí)不再經(jīng)過消息傳遞，是直接調(diào)用對(duì)應(yīng)的 C 函數(shù)，這會(huì)提升性能的。另外，對(duì)于工廠方法返回值，ARC 也會(huì)做優(yōu)化，不再將返回的對(duì)象放入 AutoReleasePool 了，而是直接返回，相當(dāng)于調(diào) alloc + init。所以放心的使用 ARC 吧，這種提高效率的東西為什么不用？

Block 為什么會(huì)出現(xiàn)呢？在我看來，是因?yàn)樵谑褂没卣{(diào)函數(shù)時(shí)，每次使用變量都要將變量整合到一個(gè)結(jié)構(gòu)體中，用 void * 指針的形式傳遞給回調(diào)函數(shù)的 context 參數(shù)，真是太麻煩了。編譯器既然能識(shí)別出在回調(diào)函數(shù)里使用了哪些變量，就自動(dòng)地跟回調(diào)函數(shù)整合成為一個(gè)對(duì)象吧，這樣在回調(diào)函數(shù)中就能直接使用了。

《iOS 開發(fā)進(jìn)階》中的腳本

唐巧的《iOS 開發(fā)進(jìn)階》中讓我印象最深的是實(shí)戰(zhàn)技巧里的一些腳本，例如刪除未使用的圖片資源、檢查圖片長(zhǎng)寬是否是偶數(shù)等，雖然都是些簡(jiǎn)單操作，但是能提升效率，感覺很棒。

我寫過的一個(gè)自動(dòng)部署工具

在中科院實(shí)習(xí)的時(shí)候，曾經(jīng)負(fù)責(zé)開發(fā)維護(hù)一個(gè)嵌入式系統(tǒng)，代碼是跑在一塊 ARM 開發(fā)板上的，因此每次交叉編譯過后需要通過 FTP 將包傳到開發(fā)板上解壓，并配置一下 rcS 啟動(dòng)腳本。開發(fā)階段只是一塊 ARM 板，手動(dòng)部署就還好，后來變成了十五塊 ARM 板，這下我不干了，手動(dòng)部署會(huì)死人的，而且一旦程序有 Bug，就要重新部署一遍。于是“懶惰”的我寫了一個(gè)自動(dòng)部署工具，思路就是輪詢目標(biāo) ARM 板的 IP 地址，針對(duì)每個(gè) IP，先通過 FTP 將程序包上傳，再通過 Telnet 輸入解壓程序包以及覆蓋 rcS 啟動(dòng)腳本的指令，將整個(gè)過程自動(dòng)化。由于懶得每次 IP 地址改變就重新編譯程序，因此將 IP 地址、FTP 賬戶密碼等信息從程序中抽出來，放到一個(gè)配置文件中，每次啟動(dòng)時(shí)讀?。ㄒ菜闶且环N依賴注入了）。同時(shí)也懶得每次 Telnet 輸入的命令改變就重新編譯程序，將 Telnet 要輸入的命令也寫到一個(gè)文本文件中，動(dòng)態(tài)讀取。寫好了之后，手動(dòng)部署估計(jì)要兩個(gè)小時(shí)的活，一行命令搞定，感覺生活頓時(shí)美好了許多。

如果仔細(xì)觀察，還有非常多的例子，其實(shí)要做到這一點(diǎn)與能力無關(guān)，與方向無關(guān)，與規(guī)模無關(guān)，只跟態(tài)度有關(guān)，包括個(gè)人與團(tuán)隊(duì)的態(tài)度。對(duì)于個(gè)人而言，遇到重復(fù)工作，是就這樣低效地重復(fù)下去，還是思考用自動(dòng)化提高效率？對(duì)于團(tuán)隊(duì)而言，是否給成員時(shí)間來完成一些能夠提高效率的工具？工程師文化越是濃厚的團(tuán)隊(duì)，各種工具就越多，效率就越高?？傊瞬⒉簧瞄L(zhǎng)做重復(fù)枯燥的工作，而這些工作恰恰是機(jī)器擅長(zhǎng)的，想辦法交給機(jī)器去做吧，遵循 DRY：

Don’t Repeat Yourself！

不利的懶惰

下面這些不利的懶惰會(huì)極大地妨礙我們成為優(yōu)秀的工程師（在寫下面的內(nèi)容時(shí)，我也在不斷反思自己，發(fā)現(xiàn)其實(shí)自己許多地方依然犯了懶惰的錯(cuò)誤，邊寫邊出汗，膝蓋各種中箭。。。）：

懶得搜索

我記得微博上有過一張亞一程 Laruence 一段群對(duì)話的截圖，里面是這樣說的：“不是我說你，這么簡(jiǎn)單的問題，你不 Google，不百度，來群里問，簡(jiǎn)直是舍近求遠(yuǎn)”。其實(shí)真正原因就是懶。在現(xiàn)在這個(gè)時(shí)代，搜索是無比強(qiáng)大的工具，想想看，世界那么大，就去搜一搜，你不會(huì)是第一個(gè)遇到問題的，也不會(huì)是最后一個(gè)遇到的，我覺得，Google + StackOverflow + Github + Dash 基本上能解決99%的問題。

我們經(jīng)常會(huì)遇到搜索不到答案的過程，于是很多人就放棄了，回到了到處去問的老路上。其實(shí)搜索不到答案的原因有2點(diǎn)：1，我們沒有正確描述以及抽象問題，找對(duì)關(guān)鍵字。2，我們沒有用搜索引擎的思維思考。遇到搜索不到的情況時(shí)，不要放棄，努力思考如何修改關(guān)鍵字與描述，多試幾次，雖然很痛苦，但痛苦說明我們的大腦在形成新的思維模式，一旦形成，我們的搜索會(huì)越來越準(zhǔn)確，效率也會(huì)越來越高。

哦，對(duì)了，最后提醒一下，對(duì)于技術(shù)問題，還是避免使用百度吧，真的搜不到什么有用的東西。有人會(huì)說用 Google 還要科學(xué)上網(wǎng)，多麻煩，相比搜索到有效答案帶來的收益，F(xiàn)Q這點(diǎn)工作真不算什么，我們可是工程師啊，反思下是不是因?yàn)閼兴圆辉敢庥?Google？

懶得思考

我們?cè)趯W(xué)習(xí)一個(gè)知識(shí)的時(shí)候，要積極思考，不能死記硬背。一種框架/特性出現(xiàn)時(shí)，一定有它的原因，多想想為什么會(huì)出現(xiàn)？解決了什么樣的問題？為什么要這樣做？這樣做的好處是什么？原理是什么？到底是如何實(shí)現(xiàn)的？保持強(qiáng)烈的好奇心，這會(huì)使我們不斷發(fā)問，在回答問題時(shí)會(huì)不斷思考，而只有不斷的思考才能真正理解一個(gè)知識(shí)，從而能夠更好的使用。

另外，我們?cè)谟龅絾栴}后，往往會(huì)搜到解決方案只是簡(jiǎn)單的拷貝，不分析背后的原因，不分析解決方案會(huì)造成哪些影響。Bug 是那磨人的小妖精，這次不徹底搞清楚原因，下次它還會(huì)來煩我們，我們就會(huì)成為傳說中的救火隊(duì)長(zhǎng)，哪里著火滅哪里，疲于奔命，但火卻越滅越多。

懶得閱讀

現(xiàn)在不是知識(shí)匱乏，而是知識(shí)爆炸，如果想學(xué)習(xí)，有太多的東西可以學(xué)了：

書：iOS 的經(jīng)典書籍，隨便一本都能讓人受益匪淺。

博客：有太多優(yōu)秀的博客了，那都是別人深思熟慮的精華，花了數(shù)個(gè)小時(shí)寫出來的。

文檔：很多時(shí)候，StackOverflow 回答問題的方式就是貼上一段官方開發(fā)文檔上的文字，或者接口 API 的說明，在看不到源碼的情況下，官方文檔可以看出源碼的接口說明，很值得一讀。用 Dash 或 Xcode 自帶文檔工具，遇到不清楚的點(diǎn)就去看一看。

源碼。Reading the Fucking SOURCE CODE 不是一句空話，源碼之下無秘密。有些效果不知道怎么做，到 GitHub 上搜一搜，看懂了自己不就會(huì)了。

總之，Stay Hungry，Stay Foolish！

懶得動(dòng)手嘗試

看看這篇《Leveling Up》，紙上得來終覺淺，絕知此事要躬行，動(dòng)手才是學(xué)習(xí)最有效的方法：

在看別人教程時(shí)，把 Demo 下載，自己跑一跑，改改參數(shù)，或者自己嘗試重新寫一遍，效果絕對(duì)比只看要好。自己有疑問時(shí)或者有想法時(shí)，都可以寫個(gè) Demo 實(shí)驗(yàn)一下。

在看 Objective-C Runtime 原理時(shí)，親自用 clang -rewrite-objc file.m 將 .m 文件轉(zhuǎn)成 .cpp 文件看一看。用 Associated Object 給 Category 加屬性時(shí)都自己寫段代碼試一試。

想看系統(tǒng)函數(shù)的調(diào)用情況，可以用 Method Swizzle 給一些系統(tǒng)方法加一些“裝飾”，或者還可以用符號(hào)斷點(diǎn)。沒事干找臺(tái)越獄手機(jī)用 Reveal 看看別人家的 App。

懶得改進(jìn)優(yōu)化

唯一不變的就是變化。代碼在最初時(shí)由于業(yè)務(wù)簡(jiǎn)單一般都很不錯(cuò)，但往往在增加新需求/需求變化時(shí)開始出現(xiàn)壞味道，因?yàn)樾枨蟮淖兓?jīng)常導(dǎo)致大環(huán)境變化，而不同環(huán)境下的實(shí)現(xiàn)是不同的，例如網(wǎng)站支持100人訪問與支持100000人訪問是兩種實(shí)現(xiàn)方式，控件只支持一行顯示與支持多行顯示也是兩種實(shí)現(xiàn)方式。PM 有時(shí)候意識(shí)不到需求變化背后隱含的環(huán)境變化對(duì)技術(shù)實(shí)現(xiàn)的影響，覺得不就是簡(jiǎn)單的改一下，有什么難的？對(duì)啊，把大象裝冰箱里也只需要三步，有什么難的？為了應(yīng)對(duì)這些變化，工程師有時(shí)需要對(duì)結(jié)構(gòu)進(jìn)行調(diào)整，保證結(jié)構(gòu)的靈活，在下次變化來臨時(shí)更從容，這種調(diào)整就是重構(gòu)。重構(gòu)不是洪水猛獸，重構(gòu)可以很大，也可以很小，一切在于時(shí)間點(diǎn)，修改的時(shí)間點(diǎn)越早，成本就越低，不然就會(huì)欠下技術(shù)債。在邏輯的世界里，只分對(duì)錯(cuò)，欠下的一定會(huì)還。不要為了一時(shí)便利而忽略了可持續(xù)性，切記技術(shù)債是高利貸，利滾利，拖得時(shí)間越久，成本就越高，到最后一定會(huì)連本帶利讓欠債者賠個(gè)精光。

因此工程師在實(shí)現(xiàn)需求時(shí)一定要留出 Buffer 來處理結(jié)構(gòu)變化引起的重構(gòu)與遺留代碼帶來的技術(shù)債，不能懶，這樣以后的需求才會(huì)更好做。而團(tuán)隊(duì)在每個(gè)迭代中也應(yīng)考慮將一些技術(shù)債與優(yōu)化作為需求加入到需求池中，不然代碼的壞味道就開始在工程中彌漫，需求越做越慢，Bug 越做越多，為了速度，開始拼命加班招人，效率卻越來越低，進(jìn)入惡性循環(huán)。

懶得總結(jié)

在我看來，經(jīng)驗(yàn)從來不是比拼總時(shí)間，而是比拼效果。有些人多年經(jīng)驗(yàn)卻不如有些人一年經(jīng)驗(yàn)，這是為何？關(guān)鍵在于總結(jié)。就拿圣斗士星矢來說，如果單論時(shí)間，他能當(dāng)上青銅圣斗士都很勉強(qiáng)了，為什么他能打敗黃金圣斗士，因?yàn)樗f過：圣斗士不會(huì)敗給同一招兩次！犯錯(cuò)掉進(jìn)坑里不要緊，誰沒有犯過錯(cuò)？但掉進(jìn)同一個(gè)坑兩次就不太好了，而有效的經(jīng)驗(yàn)?zāi)茏屛覀円院蟛辉俜赶嗤蝾愃频腻e(cuò)誤。

如何克服這些問題

我仔細(xì)觀察過一些優(yōu)秀的 iOS 工程師，發(fā)現(xiàn)：

每年都有 WWDC，大家都能看，但喵神 onevcat 總能寫出高質(zhì)量的筆記與總結(jié)。

同樣是學(xué) Objective-C，陽神孫源能玩出花來，挖掘出各種特性與原理。（我曾經(jīng)在陽神的博客上問過一個(gè)問題，陽神告訴我他是通過反解匯編代碼得出的，我就意識(shí)到自己犯了懶于嘗試的錯(cuò)誤了）

動(dòng)畫狂魔葉孤城_與動(dòng)畫小王子 KITTEN-YANG 的動(dòng)畫屌炸天，不用問他們?yōu)楹稳绱藢?，去他們?GitHub 上看看他們各種嘗試動(dòng)畫的 Demo 就知道了。

唐巧的《iOS 開發(fā)進(jìn)階》讓我收獲最多的不是里面的知識(shí)，而是他學(xué)習(xí)與總結(jié)的方式，我不斷的反思自己，我平時(shí)學(xué)習(xí)時(shí)，是否能像他一樣總結(jié)出一本自己的 iOS 學(xué)習(xí)筆記。

還有許多優(yōu)秀的 iOS 工程師這里就不一一舉例了，我認(rèn)為，這些優(yōu)秀的 iOS 工程師并沒有比你我聰明，跟我們一樣只是普通人，但他們?cè)谏厦孢@些事情上不懶惰，積極思考、嘗試、總結(jié)，在同樣的條件下收獲多一點(diǎn)點(diǎn)，日積月累，于是他們變得優(yōu)秀。不要小看這一點(diǎn)點(diǎn)，我們要相信積累的力量，水滴石穿啊，tinyfool 說過，這種積累所達(dá)到的層次，很難被人短時(shí)間追趕上，需要?jiǎng)e人同樣去積累，是非常具有競(jìng)爭(zhēng)力的。

面對(duì)這些優(yōu)秀的 iOS 工程師，我們經(jīng)常會(huì)犯另一種懶惰的錯(cuò)誤：我們總想加好友，攀交情，甚至用拉低姿態(tài)的方式，總覺得自己抱上大腿就能迅速成長(zhǎng)，迅速變牛。這其實(shí)是種假象，是自己不自信不獨(dú)立的表現(xiàn)。即使加了好友，他們能夠答疑解惑，甚至手把手教，親自幫忙解決問題又怎樣，那還是別人的東西，自己沒有任何成長(zhǎng)，自己不就犯了懶惰的錯(cuò)誤嗎？

學(xué)習(xí)與成長(zhǎng)從來沒有捷徑，也只能靠自己！

除了欣賞與欽佩這些優(yōu)秀的人外，我覺得更重要的是默默地觀察與努力，觀察他們是如何成長(zhǎng)的，學(xué)習(xí)他們的好習(xí)慣，努力提升自己，向他們看齊，當(dāng)有一天達(dá)到了他們的水平之后，無需刻意培養(yǎng)，同他們自會(huì)相熟，因?yàn)閮?yōu)秀的人總是互相吸引互相欣賞，“臭味相投”，不是嗎？

總之，借用《學(xué) iOS 開發(fā)的一些經(jīng)驗(yàn)》里的一段話來激勵(lì)自己，努力成為一名“懶惰”而不懶惰的優(yōu)秀工程師：

我覺得支撐我們不斷探索和前進(jìn)的動(dòng)力不是興趣，而是永不滿足的好奇心，和對(duì)優(yōu)雅代碼的追求。

與技術(shù)無關(guān)的懶惰

最后提一下工程師非常常見的懶惰：懶得鍛煉，不注意自己身體。在我看來，我們可以熱愛編程，熱愛自己的工作，熱愛自己的事業(yè)，熱愛自己的公司，但這些不是最重要的，最重要的是我們自己的身體與我們的家庭。為什么呢？因?yàn)閷?duì)于公司而言，我們是可以替代的，無論我們多么牛，多么重要，少了我們，公司依然可以運(yùn)作。但對(duì)于身體與家庭而言，我們是不可替代的！身體不是程序，不能重置，一旦身體壞了，就很難恢復(fù)，甚至繼續(xù)惡化，伴隨一生。一旦我們走了，我們的父母、配偶、子女就失去了唯一的我們，這帶來的傷害與損失對(duì)于家庭而言是無法估量的，甚至為持續(xù)一輩子（看看那些失孤的老人，讓人心碎?。?。孰重孰輕，我相信理智的工程師會(huì)做出自己的決定。

我這里不是說我們不要奮斗不要拼搏，這跟鍛煉身體完全是互不影響的，鍛煉身體甚至能讓我們能夠更好的拼搏與奮斗。我們不能學(xué)習(xí)現(xiàn)在敏捷的一些錯(cuò)誤做法，只強(qiáng)調(diào)快，卻忽略了可持續(xù)性（敏捷強(qiáng)調(diào)的是可持續(xù)性的快速迭代），所以不要拼一天的工作時(shí)長(zhǎng)，留出點(diǎn)時(shí)間鍛煉健身，我們都加過班，長(zhǎng)時(shí)間加班加到后面其實(shí)腦子已經(jīng)不夠敏銳了，效率極低，對(duì)編程這種強(qiáng)腦力勞動(dòng)是很不利的，易出問題，還不如回去跑跑步，早點(diǎn)休息，明天更高效完成就好了。有時(shí)候公司或團(tuán)隊(duì)的氛圍就是不把工程師當(dāng)人看，瘋狂加班，幻想著靠十個(gè)女人懷孕一個(gè)月就能把孩子生出來，我覺得實(shí)在受不了就換一家吧，沒什么大不了，開心健康地活著其實(shí)就是在賺錢。（醫(yī)院才是真正的銷金窟，錢到那個(gè)時(shí)候就是個(gè)數(shù)字，醫(yī)院里充斥著痛苦、無助、絕望、麻木，唯獨(dú)沒有幸福，誰經(jīng)歷過誰知道）

另外，在工程師的眼里，既然一切都是邏輯，為什么不把自己的身體當(dāng)做程序來調(diào)試與優(yōu)化呢？一樣的都有輸入輸出，對(duì)高熱量食物防御式編程等，我曾經(jīng)這樣試過，成功減肥30斤，當(dāng)我能夠穿上一條許久都穿不上的褲子時(shí)，相信我，那種成就感比寫100個(gè)牛逼程序或 GitHub 上有一個(gè)10000+ Star 的倉庫都要強(qiáng)。