本書是筆者上一篇讀書筆記高效能程序員的修煉的姊妹篇，同樣介紹了一些程序員需要了解的，有關于編程本身以外的一些事情。
和上一篇讀書筆記的風格類似，筆者摘錄了幾段原書內容并結合了作者的感悟寫下了這篇讀書筆記。筆者還是深切希望各路英雄能提出寶貴的意見和想法。
關于 To-Do list
這個冗長的To-Do列表始終存在著，像一把懸掛在我頭頂上的利刃，而且每天都在變得更加沉重和鋒利。
每天早上使勁想出這天你需要做的最重要的3件事。
其實對于待辦事項列表，筆者也讀過相關的書籍，一般都是不推薦使用待辦事項列表的。筆者總結出原因有二：
待辦事項列表上面的待辦事項只是列出了還未完成的事情而已，并不帶有“何時開始進行”和“何時完成“的信息。簡單說，就是只有“what to do”而沒有“when to do”和“when to finish”。也就是它本身能帶給列表主人的驅動力不夠高。
正是因為待辦事項列表帶給主人的驅動力不高，那么結果就是它們一直會躺在列表里持續很長時間。那么它們的主人在潛意識中一直掛念著它們，分散了主人的精力。因為主人“知道”總有一些事情還是沒有完成的。
關于探索的態度
比起專業技能或者智商，成功更需要一種探索的態度，它是一種對于可能性和失敗后果的執著。那些具備良好潛質的人總是會做出類似的回答“我總是在犯一些作物。昨天剛發生了一件挺嚴重的事情，前因后果是這樣的。。。”。
相反，那些回答“我并沒有犯過大錯誤”或者“我犯過一些嚴重的錯誤，但是錯誤的原因并不在于我”的人是不會成為杰出的外科醫生的。
探索的態度對于程序員也是尤為重要的。筆者在開始寫代碼的時候總是以“解決問題就萬事大吉”的標準，遇到了可能的坑卻睜一只眼閉一只眼。但是每每這樣的時候，后來總是會出bug。
其實這就是逃避，就是一種缺乏探索精神的表現。其實我把那些坑弄懂了也不需要多少時間嘛。弄懂了，以后再遇到就穩穩當當搞定了。沒弄懂，就還是踩坑。突然想到了一句話：遇到問題，你硬著頭皮解決了一半，就只剩下一半的問題。但是你逃避，就是兩個問題了。
不管你在做什么項目，懷揣著學習和鍛煉的態度去完成它吧，這是絕對值得的！與項目結果相比，過程才是最大的財富。如果你沒能從一個項目的過程中學到一點東西，這才是真正失敗的項目。
關于專家
這個世界上只有少數的專家，卻有大量的普通人。當你想要建立一個包含各種信息的網站時，這些普通人的貢獻是最重要的。這是一個不規則的世界，里面裝滿了無窮無盡的細節。
作為專家，重要的是不是告訴別人你知道什么。而是要清楚你應該問什么樣的問題，并且靈活運用你所掌握的知識去解決眼下的具體問題。作為專家，你的作用是提供明確的，可執行的方向。
讀到這些，筆者覺得專家理應受到種種質疑，而為了能經得起這些質疑，那么就不應該跟人家說“我讀了神馬神馬著作，精通神馬神馬技術，你看我的論文，你看我的研究成果等等”，真正證明自己是專家的途徑，一般只有幫助非專家人士或者別的專家高效地解決問題。
其實，龐大的知識體系也是對解決問題幫助很大的：因為這些有著龐大知識體系的專家的晶體智力水平很高，很多時候，他們并不需要動腦子(也就是流體智力)，直接調出相應知識就能解決。所以說，那些自稱專家的人如果連連無法解決問題的話，那么真的是low爆了。
關于軟件項目管理
鼓勵并強制要求程序員創建一張他們所要做的全部事情的列表，然后盡可能添加所有的子項，這樣就能估算這個任務話費多少時間了。
如果有人問你的時間表，你應該拿出一張你要做的所有事情的列表。如果拿不出來，你所要做的第一件事情，就是要做出這么一張列表。
這種列表和待辦事項列表稍有不同。這種列表屬于“時間表”，它的目的是監控進度:所以說，它的時間總長度是不變的。但是待辦事項列表的時間總長度是趨于“無限的”(當然，只對于執行力很差的人來說)。
關于“一夜成名”
一夜成名的傳說容易讓人誤入歧途，并且遺毒不淺。如果你打算做一個全新的東西，要有打持久戰的準備。
勤于練習：不是一遍又一遍的簡單重復，而是要不斷挑戰略微超出自身能力之外的任務-努力嘗試，并在做的同時以及之后對自己的表現進行評估，然后糾正錯誤，如此反復。
這里談到了程序員對自己本身的迭代：快速迭代。其實同軟件開發是一個道理：軟件迭代的速度遠重要于迭代的質量。也就是說，我們在學習的過程中，對自己的提升也應該是快速而輕盈的。
切忌一口氣吃個胖子，肯定是吃不消的。應該結合自己已有的知識水平，再尋找對自己來說稍微有點挑戰性的技術來攻克，一來學習效率高，二來可以提升自信，進入到新一輪的學習中去。
關于優秀和平庸程序員之間的鴻溝
- 成為更加優秀的程序員的方法是拋開編程。
- 你的興趣越廣泛，就能越勝任你的工作。
- 為了真正地成為一名更好的程序員，你必須培養自己對于編程周邊所有事情的熱情。
- 單單靠編程，你只能補足或者增強自己已有的變成技能，永遠也無法成為一名優秀的程序員。你需要嘗試去了解你的客戶，你所處的行業以及相關的業務。
- 聰明的開發者知道，他們的工作遠遠不止編寫代碼和發布產品：他們的工作是開發出人們真正想要使用的軟件。這當然包括編碼，但還有大量全局性的其他事情，比如撰寫技術文檔，交互設計，培養用戶社區，乃至產品愿景，這些對于軟件的全貌成功都是至關重要的。
關于修復bug
在對報告數據的廣泛分析之后，我們看到：80%的客服問題在修復了用戶報得最多的20%的bug之后就得到解決。即使修復用戶報的最多的1%的bug，也能解決50%的客服問題。這個分析結果通常對于各家公司都是成立的。
如果你修復了一個真實用戶永遠也碰不到的bug，那你修復有什么價值呢？
你越快將你的軟件推到真實用戶面前，就會得到越多的數據來改進你的軟件。問題不在于你在發布軟件的時候帶去了多少bug，而是在于你能多快地修復那些bug。
因此，筆者認為在bug管理的問題上，要注意兩點：
- 不要怕將bug暴露在用戶面前，盡早地收集用戶的反饋數據是關鍵。
- 而且，在收到大量的反饋數據之后，也應遵循二八定律，要以bug的影響程度來劃分bug的優先級,不應盲目排列修改bug的順序。
關于衡量軟件的成功
多少用戶在真正使用你的軟件？這才是衡量成功的終極標準。
其實無論交互多絢麗，功能多么吊炸天，一旦用戶不需要，用戶不喜歡，不掏錢，其實是沒有任何卵用的。而且在一定的技術水準上，如果無法“說服”大量客戶使用產品，也同樣是讓人心痛的。
- 技術再牛也要從用戶體驗出發，少做一些中看不中用的東西。想出數百個功能很容易，但是從中挑出幾個可以提升用戶體驗，真正能吸引用戶，讓用戶掏腰包的功能實在不易。
- 產品做出來了，產品有沒有人用，營銷和推廣同時占有舉足輕重的作用。突然想到以前在一本營銷書籍看到的：能做出比麥當勞好吃的漢堡包很容易，但是能比麥當勞賣得好卻是很難得，眾人難以模仿麥當勞整體的營銷模式。相同的，像ZARA品牌的生產模式和營銷模式之高效，是其他品牌無法超越的，這也是其風靡全球的原因。
關于用戶的謊言
- 我們必須根據用戶的實際行為模式來設計產品。
- 他們會說喜歡你的軟件。但是我們應該去觀察他們是否使用了軟件，以及他們是怎么使用的。基于行為數據去設計軟件，而不是靠用戶說的“謊言”。
筆者認為，我們很少能從用戶言語上得到用戶特別真實的感受。那些善良的客戶們有時礙于面子，有時想當和事老，憑著“你好我好大家好”的原則，說一些心里沒有的，善意的謊言。
所以那些問卷調查什么的，走街串巷訪問什么的其實意義不大。真正能“窺視”用戶內心的是那些技術埋點。我記得有一次參加一個分享會，觸寶科技的CEO跟大家分享了他們的埋點:他們通過埋點的方式，甚至會知道導致用戶刪掉app的是哪幾個界面和動作。這讓我感觸很大，既然能做到這些，那么如果想知道用戶喜歡點擊那里，喜歡看哪里，喜歡做那幾個動作，豈不是輕而易舉？知己知彼，百戰豈殆？
最后作者推薦的書籍
- 《代碼大全(第二版)》
- 《點石成金：訪客至上的網頁設計秘籍》
- 《人件》
- 《程序員修煉之道：從小工到專家》
- 《軟件工程的事實與謬誤》
其中第1本和第4本筆者在看。第1本對于非科班出身的筆者來說實在是晦澀難懂。不過既然作者說讀完此書就能超過90%的程序員，那么不失為一個節省時間的好方法。以后有機會的話，希望能和各路英雄討論討論個中奧妙。
筆者最后的話
其實還是希望能和各位相互討論，其實相比于文章被“喜歡”，筆者更希望諸位能留下評論，毫不留情地指出小弟想法中的不妥之處，這些是遠比“打賞”和“喜歡”更讓小弟高興的呢！
本文已經同步到我的個人博客：傳送門，歡迎常來^^
本文已在版權印備案，如需轉載請訪問版權印。48422928
-------------------------------- 2018年7月16日更新 --------------------------------
注意注意！！！
筆者在近期開通了個人公眾號，主要分享編程，讀書筆記，思考類的文章。
- 編程類文章：包括筆者以前發布的精選技術文章，以及后續發布的技術文章（以原創為主），并且逐漸脫離 iOS 的內容，將側重點會轉移到提高編程能力的方向上。
- 讀書筆記類文章：分享編程類，思考類，心理類，職場類書籍的讀書筆記。
- 思考類文章：分享筆者平時在技術上，生活上的思考。
因為公眾號每天發布的消息數有限制，所以到目前為止還沒有將所有過去的精選文章都發布在公眾號上，后續會逐步發布的。
而且因為各大博客平臺的各種限制，后面還會在公眾號上發布一些短小精干，以小見大的干貨文章哦~
掃下方的公眾號二維碼并點擊關注，期待與您的共同成長~
