Shengnan的《構建之法》讀書筆記

由於最近回學校事情比較多，知識抽空大概瀏覽了《構建之法》這本書，整體的感覺是，這本書能用一些生動的例子去解釋一些概念或者技術，即使我這種技術小白讀起來也不會覺得枯燥。在讀的過程中，我記下了一些比較有意思的點和一些疑問，暫時就先一股腦地列在這裡，之後假如有時間再系統的整理一下。

疑問：全域性問題：書中講的內容感覺更偏向工程一些，但是如果是做research的話，有些環節（比如繁重的測試任務）是否可以在實際操作中精簡一下？

p92：「主治醫師模式」似乎會逐漸變成「抱大腿模式」（就像在學校做小組作業一樣）。要如何避免出現「大腿」承擔所有工作而其他人只在一旁喊「666」呢？

p105：mvp可以用來徵集使用者意見，但假如mvp的反饋很差，是否意味著這款產品沒有做下去的必要了？

p145：微軟提倡learning by doing，這確實是上手工作的最好方式。但是，是否會存在「揠苗助長」的問題呢？

p160：谷歌團隊爭論41中藍色哪種更好，看上去很荒唐，但到底是什麼引發了這種荒唐事？該如何避免？

p185：書中說pm要負責管理專案進度，可是pm該如何管理？

p256：那個學者師承關係樹，似乎關心的問題不是「使用者會每天都來看這個動畫麼？」，而是「使用者在搜尋時會來看這個動畫麼？」似乎僅僅當做微軟學術搜尋的小彩蛋，還是挺能吸引人的？（比如谷歌瀏覽器在沒網的時候可以玩的那個小恐龍）

p339：「扁鵲三兄弟」的問題怎麼解決？似乎功勞與「鍋」分配不均是乙個團隊內很大的不穩定因素。

p345：讓人喜歡的創新是與現有系統相容的，但是很多好的創新之所以好，不正是因為其顛覆性麼？

p359：ai技術是否已進入高科技炒作的迷茫期？

個人想法：

p66：用abcd的形式命名變數很有用，但是個人更習慣ab_cd的形式。

p87：「三明治」式的反饋確實更容易讓人接受，但假如兩個人已經很熟了，也許直接提問題能加快溝通效率。

p128：在不確定溝通效率和溝通範圍時，寧可過分溝通，也不要省略溝通。

p141：在執行任務時，全域性任務為核心，可以暫時放棄額外的誘人目標。

p155：「鞦韆圖」感覺是全書最真實的圖了orz解決這個問題，我認為關鍵在於有乙個思維清晰的全域性規劃者（比如組裡的大老闆）。

p165：似乎強調「殺手功能」和新木桶原理的長板效應很類似。

p194：會議結果得到行動後，一定要強調行動的負責人。

p235：在實現整體功能前，區域性的小bug是可以容忍的。並且不要過早的優化。

p243：「新員工上手問題」真的很有實際意義。

p250：谷歌的搜尋介面感覺很乾淨，使用者體驗就很好（對本人使用者而言）。但是hao123感覺就很凌亂，體驗很差。

p260：有時候，使用者體驗比產品質量更重要，就像**裡的視覺化有時候比資料結論更重要。

p341：靈光的出現需要有兩個基礎：前人工作的基礎與自身積累的基礎。

p348：外行人之所以能發現內行忽略的創新點，大概就是因為「只因身在此山中」吧。對住在南方的同學來說，再普通的一片雪花，也能激起極大的探索熱情。