我认为的一个程序员能独当一面的标准
一.掌握计算机、软件工程的基础知识
程序员会分为负责不同职能的岗位，比如前端、后端、大数据等，而这些里面又会有更细的划分，每一个具体的岗位都会有各自需要掌握的技能图谱。我说的独当一面指的是在这些负责某一个具体职责的岗位上能独当一面。虽然我们处在某一个具体的岗位上，但是如果要想做到能独当一面，以我个人的经历，其实需要掌握的能力一定不止于这个岗位所要求的技能，但是我们又很难有精力去了解不同岗位的所需技能，所以我们需要掌握计算机、软件工程的基础知识，有了这些基础知识，再临时去了解其他岗位的技能难度会小很多。
二.对接需求的能力
产品需求对内可以说是我们工作任务的直接来源，对外也可以说影响产品商业价值的重要因素，因此对接好需求对我们的工作开展非常关键，那如何对接？我觉得要：
- 要有辨别需求是否合理的能力，如果不合理，要有根据产品动机提出更合理的需求的能力。我在《产品思考》中说的更具体一些。
另外，个人觉得，我们不能仅仅站在研发的角度来判断需求是否合理，也要有全局意识，能从用户、运营的角度去考虑一下需求的合理性。当一个需求从用户、运营角度是合理的，从研发角度不合理时，面对这种矛盾，我们可以先采用用户优先的临时解决方案，后期最好从整个系统层面来重新思考这个需求，将其更合理的纳入整个系统的逻辑闭环中，不过往往都没有这个后期了。
要能深入的去过一遍需求，看看这些需求能不能构成一个完整的逻辑闭环，避免开发中才发现需求有遗漏的地方。
要能比较准确的评估自己的工时的能力，在这基础上再视具体情况加上一些缓冲时间才是对外提供的工时安排。
三.善于使用或制造工具
从某种角度上说一个趁手的工具就像是一个封装好的方法，我们只需要调它的API就能实现我们想要的功能，至于具体是怎么实现的，那是工具内部做的事我们不必关心，而这就能很好的提高我们的工作效率。所以，这里的工具也可以看成一个笼统一点的概念，一个基于业务逻辑上的数据清洗的方法、一个图片上传的组件、一个项目自动部署的开源库都可以称之为我所说的工具，除了工作上如此，生活中也是如此，比如我的早点经常是热干面，这种热干面的塑料盖子是直接热压封印上去的，不方便直接撕开，我吃之前，拿筷子把塑料盖子捅破一个洞然后把口子划开，再用手把盖子掀掉，吃一次这样做还行，经常吃的话每次都这么做其实挺麻烦的，后来我就专门买个一个剪刀，这样每次吃面就方便太多，这也是工具带来的好处。
如果我们能直接找到现成的工具那自然最好，如果不能，就需要我们自己创造工具，而创造工具的能力是很有挑战性的，因为这要求我们对工具的使用场景和需要它发挥的作用有着非常深入的理解，而这点像是想好产品文档了，至于怎么实现，又是一个有挑战性的任务，从这个角度看来，创造一个工具，其实就像自己独立打造一个小而美的产品一样，一旦创造出来，会给自己或他人带来效率上的提升，这是一件具有挑战性也很有意思的事情。
四.解决相对陌生领域问题的能力
在工作中，我有时候会遇到一些相对我来说是陌生领域的问题或者需求需要解决，但是人的精力是有限的，我们不可能做到面面俱到的知识储备，所以这时候其实最需要的是我们分析问题的能力，搞清楚问题产生的原因，再根据这个原因将问题拆成若干个独立的小问题，再结合前面说的信息检索能力，去找到每个小问题的解决方法。
但是就像我之前一篇文章 《关于问题的扯淡》中所说的，要想搞清楚问题产生的原因，就要明白其内部的逻辑，而对于陌生领域的问题，我们很难在短时间里搞清楚其内部的逻辑，我一般是用两种办法解决的：
既然导致问题的内部逻辑我们不清楚，对于我们就像是一个黑盒，那我们就先找到影响这个黑盒内部逻辑的外部变量，通过分析这些变量来推测产生这个问题的内部逻辑。具体来说，先大概划定一个产生问题的边界，然后找出这个边界内的变量，再逐个的改变某一种变量，看看是否还会出现问题，是否是一样的问题，用这种笨办法找出导致问题产生的变量，然后分析这个变量起到的是什么作用从而推测出导致问题产生的一个大致逻辑，即大概了解了问题产生的原因，如果我们找到的这些变量比较复杂，可能会出现改变一个变量导致另一个变量也发生改变，这说明我们找到的变量还不是正交的，所以我们需要再往下一层，找出导致问题的正交变量，再接着上面说的分析下去。
第二种方法有点玄学，是基于一个我发现的规律，就是任何复杂的逻辑其实往上抽象后，都是一个很简单的逻辑闭环，如何还是觉得复杂，那说明我们还需要进一步的往上进行抽象（这好像也是一些专业人士像大众科普一些专业的问题采用的一种方法）。基于这个规律，当我们面对相对陌生领域的问题后，因为至少都是包含于计算机或者软件工程这个大领域的，所以我们还是可以弄清这个领域相关的上层的比较简单的逻辑，基于这个比较上层的简单的逻辑，针对一部分问题，我们还是可以推测出其大概的内部逻辑，然后对这个内部逻辑进行一个模块化分析，其实就是对内部逻辑通过抽象的手段进行拆分解耦，从中分析出导致问题的模块，再对问题模块再进行一次拆分解耦，直到找出问题的所在。
五.编写可维护可扩展代码的能力
我觉得编写可维护可扩展代码的根本方法就是要有能进行合理抽象的能力，这个我觉得除了天赋就是通过不断踩坑的经验积累了。
六.沟通能力
程序员虽然看似只要对着显示器敲代码，似乎不怎么需要沟通能力，但是以我个人的一点偏见，往往是搬砖级的程序员才是只需要成天敲代码，越是核心的程序员越是需要和产品沟通需求、和研发讨论技术方案以及向boss汇报工作，这里面都需要良好的沟通能力，那如何提高沟通能力呢？
经过参考知乎徐强的相关回答，发现日常沟通的能力主要体现在以下2个方面：
表达自己想法的能力
理解别人想法的能力
具体来说：
在表达自己想法的能力上通常存在以下几个问题：
自己没说清
自己没说清又有以下几点原因：
- 自己没想清楚要说什么
非闲聊的表达都是有目的性的，在做一次表达前要想清楚自己的目的是什么，然后围绕这个目的来，表达相关的内容，要保证一次的表达内容就一个目的，如果有很多不同目的的信息要说，那就分次说出来。
- 想清楚要说什么了，但是组织不好表达的逻辑
确定好自己一次表达的所有信息都是围绕一个目的后，还要对于自己想说的信息最好要有一条逻辑主线串联起起来，如果是逻辑比较复杂点的内容，可以对要内容按照逻辑进行分层，形成一个树状图，每次表达只表达同一层面的内容，如果是太复杂的那种树状图，其实也就不适合口语表达了。
另外，我们在表达前自己组织一段内容的逻辑时，有可能潜意识里并不会那么严谨的环环相扣，而是会跳过一两环，然后当我们把它表达出来时，从别人的角度看由于缺乏那跳过几环逻辑，往往就不能理解我们的表达内容了，这究其原因，还是我们没说清，逻辑上有缺失。
自己说清了，别人不易理解
这种问题有以下几点原因：
自己表达的内容信息量太大
人脑一次能接受的信息量是有限的，尤其是在即时沟通这种场景下，如果一次表达了太多信息，别人是很难接受的了的，所以我们需要对我们要表达的信息做一个过滤，只表达比较关键的想法，至于细枝末节，适合以书面的形式甚至配图表表达出来。
表达的内容包含一些专业概念
如果涉及到专业概念，可以通过打比方的方法来解释，而能否用比较形象的比方来描述一个专业概念，其实也能反映我们自身对于这个概念的理解程度。
别人自身问题
理解别人想法的能力
这点要有个前提条件：我们自身的理解能力是合格的。 如果对方是一个表达能力很强的人，那一般情况我们自然能理解对方要表达的想法，所以如果理解不了，往往是理解的角度不同或者别人的表达存在问题。为了避免或者解决这两点问题，我们在和别人沟通时，要适时对对方的表达内容做个总结以便对方确认我们的理解是没有问题的。