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

原文地址：https://www.cnblogs.com/xybaby/p/9607331.html