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以后，能够互相体谅吧