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

有利的懶惰

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

CocoaPods

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

下載第三方庫的代碼。

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

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

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

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

ARC 與 Block

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

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

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

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

我寫過的一個自動部署工具

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

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

Don’t Repeat Yourself！

不利的懶惰

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

懶得搜索

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

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

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

懶得思考

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

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

懶得閱讀

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

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

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

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

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

總之，Stay Hungry，Stay Foolish！

懶得動手嘗試

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

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

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

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

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

唯一不變的就是變化。代碼在最初時由于業(yè)務(wù)簡單一般都很不錯，但往往在增加新需求/需求變化時開始出現(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 有時候意識不到需求變化背后隱含的環(huán)境變化對技術(shù)實(shí)現(xiàn)的影響，覺得不就是簡單的改一下，有什么難的？對啊，把大象裝冰箱里也只需要三步，有什么難的？為了應(yīng)對這些變化，工程師有時需要對結(jié)構(gòu)進(jìn)行調(diào)整，保證結(jié)構(gòu)的靈活，在下次變化來臨時更從容，這種調(diào)整就是重構(gòu)。重構(gòu)不是洪水猛獸，重構(gòu)可以很大，也可以很小，一切在于時間點(diǎn)，修改的時間點(diǎn)越早，成本就越低，不然就會欠下技術(shù)債。在邏輯的世界里，只分對錯，欠下的一定會還。不要為了一時便利而忽略了可持續(xù)性，切記技術(shù)債是高利貸，利滾利，拖得時間越久，成本就越高，到最后一定會連本帶利讓欠債者賠個精光。

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

懶得總結(jié)

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

如何克服這些問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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