目錄
正文
One take，是幾年之前看綜藝節目聽林志炫提到的一個詞，就是說錄製一首歌曲一次性完成，無需後期的各種修音。這個概念聽起來就很酷，對不對？
作爲一個程序員，我經常也希望能夠One take：一次性把事情做好，不用反覆。但逐漸發現，追求One take是很難的。
本文地址：https://www.cnblogs.com/xybaby/p/9607331.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之後，可以互相體諒吧
本文版權歸作者xybaby（博文地址：http://www.cnblogs.com/xybaby/）所有，歡迎轉載和商用，請在文章頁面明顯位置給出原文鏈接並保留此段聲明，否則保留追究法律責任的權利，其他事項，可留言諮詢。