One take，可望而不可即

　　One take，是幾年以前看綜藝節目聽林志炫提到的一個詞，就是說錄製一首歌曲一次性完成，無需後期的各類修音。這個概念聽起來就很酷，對不對？

　　做爲一個程序員，我常常也但願可以One take：一次性把事情作好，不用反覆。但逐漸發現，追求One take是很難的。

　　本文地址：http://www.javashuo.com/article/p-fturmvqx-gp.html

關於讀書

　　坦白的說，我看書很少，不論是技術書籍仍是人文。除了自己不夠熱愛、不能堅持的主因，忙碌是不可忽視的客觀緣由，如今你們都提倡碎片化閱讀，這對於非技術書籍還行得通，但對於技術書籍，尤爲是本身不是很擅長的領域，仍是須要大塊集中的時間去閱讀。

　　由於花在閱讀上的時間少，我就特別但願One take：一本書讀一遍就基本掌握，至少掌握我所感興趣的部分。但事實上，基本是不行的，讀完一遍以後常常是一遍空白，究其緣由：（1）年紀大了，記性變差，這是天然規律；（2）碎片化閱讀，撿了芝麻丟了西瓜，缺乏連貫性；（3）也許閱讀原本就不是一件能一蹴而就的事情。

　　那麼我也在繼續努力，試圖最高效的閱讀一本技術書籍。我本身目前的閱讀大約是這樣的：首先看前言（Preface），看看這本書想要講得是什麼，重點在哪裏；第一遍通讀全文，作好筆記，包括寫得好的地方以及暫時不明白的地方；第二遍，結合書籍的目錄和筆記，以及每一章的總結（summary），回顧整本書的內容，有一個全面的掌握，梳理內在邏輯關係。第三遍：整理成讀書筆記或者思惟導圖，以便以後檢閱。

　　固然，實際狀況是，以後用到的時候，還得去查看原文（畢竟原文比筆記詳細）。

　　書讀百遍，其義自見，古人誠不欺我。在閱讀（精讀）這件事情上，彷佛並無什麼捷徑，想要One take，太難。

關於需求

　　程序員與產品經理之間不可調和的矛盾，是你們津津樂道的話題。

　　做爲程序員，天然常常會罵：PM傻逼，啥都不懂瞎指揮，鄙視！固然，PM也在罵：程序搓逼，這都實現不了，鄙視！

　　要和諧相處，其實須要雙方的努力，尤爲是在知識背景差別很大的狀況下順暢地溝通，以達到共識。不過，在這裏，僅從程序員的角度出發，討論PM改需求的問題。

　　讓程序（或者還有UI、美術）最爲頭疼的事情，就是PM改需求。對於改需求，程序天然是深惡痛絕的。不過，這不就是追求One take嗎？但願策劃的需求一次性肯定，程序實現以後就不要再改動了，這是最好的、最理想的狀態，一鼓作氣，不過現實基本都不是這樣的。

　　對於PM，當他有一個idea的時候，僅憑腦補是很難驗證的，這個時候就得須要程序幫忙實現一個原型，幫助去驗證、完善想法。在《你的燈亮着嗎》裏面提到，不管表面上表現得如何，在你提供他們所要求的東西以前，他們極少知道本身想要什麼。即便在需求實現以後，在老闆的要求下、在與其餘同事的交流中、在用戶的實際體驗反饋後，都會發現一些須要完善、調整的地方，這個時候就會有需求的改動。換個角度思考，一個功能、產品實現出來以後，如沒有任何進一步的迭代需求，那麼多半是沒有用戶使用。所以，不是說PM不想一次性搞定，而是根本就作不到。

　　在《怎樣纔算得上合格的程序員》一文中也提到，一個合格的程序員須要在業務的角度去思考、討論需求，既能幫助本身和PM搞清楚真正須要解決的問題，又能爲以後可能的需求變化作必定的準備。

　　另外，對於程序寫代碼這件事情，也是不存在One take的。由於不能一次作好，纔會有重構、纔會有敏捷開發、纔會有大牛說「好的架構不是設計出來的，而是演化而來的」。只不過，重構這個事情，是由程序員自身去驅動的，在程序員看來以爲是合理的、值得投入的；可是在PM上看來，也可能會以爲是浪費時間。而該需求這件事，在程序看來多是浪費時間，但對於項目、對於業務來講是值得的。

　　有的時候，咱們應該反思，本身是否「嚴以律人，寬以待己」了。　　

　　也許，當明白，提需求--實現需求不大可能One Take以後，能夠互相體諒吧