工程師的懶惰

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

有利的懶惰

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

CocoaPods

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

1. 下載第三方庫的代碼。
2. 將第三方庫的代碼引入工程，并添加第三方庫所需的 Framework。
3. 解決庫與庫之間、庫與工程之間的依賴關系，檢測重復添加的 Framework。
4. 如果第三方庫有更新，需要將庫從工程中刪除，并重復上面的步驟。

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

ARC 與 Block

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

Block 為什么會出現呢？在我看來，是因為在使用回調函數時，每次使用變量都要將變量整合到一個結構體中，用 void * 指針的形式傳遞給回調函數的 context 參數，真是太麻煩了。編譯器既然能識別出在回調函數里使用了哪些變量，就自動地跟回調函數整合成為一個對象吧，這樣在回調函數中就能直接使用了。

《iOS 開發進階》中的腳本

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

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

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

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

不利的懶惰

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

懶得搜索

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

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

哦，對了，最后提醒一下，對于技術問題，還是避免使用百度吧，真的搜不到什么有用的東西。有人會說用 Google 還要KX上網，多麻煩，相比搜索到有效答案帶來的收益，KX上網這點工作真不算什么，我們可是工程師啊，反思下是不是因為懶所以不愿意用 Google？

懶得思考

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

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

懶得閱讀

現在不是知識匱乏，而是知識爆炸，如果想學習，有太多的東西可以學了：

• 書：iOS 的經典書籍，隨便一本都能讓人受益匪淺。
• 博客：有太多優秀的博客了，那都是別人深思熟慮的精華，花了數個小時寫出來的。
• 文檔：很多時候，StackOverflow 回答問題的方式就是貼上一段官方開發文檔上的文字，或者接口 API 的說明，在看不到源碼的情況下，官方文檔可以看出源碼的接口說明，很值得一讀。用 Dash 或 Xcode 自帶文檔工具，遇到不清楚的點就去看一看。
• 源碼。Reading the Fucking SOURCE CODE 不是一句空話，源碼之下無秘密。有些效果不知道怎么做，到 GitHub 上搜一搜，看懂了自己不就會了。

總之，Stay Hungry，Stay Foolish！

懶得動手嘗試

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

• 在看別人教程時，把 Demo 下載，自己跑一跑，改改參數，或者自己嘗試重新寫一遍，效果絕對比只看要好。自己有疑問時或者有想法時，都可以寫個 Demo 實驗一下。
• 在看 Objective-C Runtime 原理時，親自用 clang -rewrite-objc file.m 將 .m 文件轉成 .cpp 文件看一看。用 Associated Object 給 Category 加屬性時都自己寫段代碼試一試。
• 想看系統函數的調用情況，可以用 Method Swizzle 給一些系統方法加一些“裝飾”，或者還可以用符號斷點。沒事干找臺越獄手機用 Reveal 看看別人家的 App。

懶得改進優化

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

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

懶得總結

在我看來，經驗從來不是比拼總時間，而是比拼效果。有些人多年經驗卻不如有些人一年經驗，這是為何？關鍵在于 總結 。就拿圣斗士星矢來說，如果單論時間，他能當上青銅圣斗士都很勉強了，為什么他能打敗黃金圣斗士，因為他說過： 圣斗士不會敗給同一招兩次！ 犯錯掉進坑里不要緊，誰沒有犯過錯？但掉進同一個坑兩次就不太好了，而有效的經驗能讓我們以后不再犯相同或類似的錯誤。

如何克服這些問題

我仔細觀察過一些優秀的 iOS 工程師，發現：

• 每年都有 WWDC，大家都能看，但喵神onevcat 總能寫出高質量的 筆記與總結 。
• 同樣是學 Objective-C，陽神孫源能玩出花來，挖掘出各種特性與原理。（我曾經在 陽神的博客 上問過一個問題，陽神告訴我他是通過反解匯編代碼得出的，我就意識到自己犯了懶于嘗試的錯誤了）
• 動畫狂魔葉孤城_與動畫小王子KITTEN-YANG 的動畫屌炸天，不用問他們為何如此屌，去他們的 GitHub 上看看他們各種嘗試動畫的 Demo 就知道了。
• 唐巧的 《iOS 開發進階》 讓我收獲最多的不是里面的知識，而是他學習與總結的方式，我不斷的反思自己，我平時學習時，是否能像他一樣總結出一本自己的 iOS 學習筆記。

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

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

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

總之，借用 《學 iOS 開發的一些經驗》 里的一段話來激勵自己，努力成為一名“懶惰”而不懶惰的優秀工程師：

與技術無關的懶惰

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

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

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