未来两年：人机结对编程(MMPP)将成为现实
今天看到头条 一篇文章《自动编程是不可能的，我为什么不在乎人工智能》，认为存在一些“AI 狂人”，他们的心已经严重的机械化了。他们或多或少的失去了人性，忘记了人最需要的是什么，忘记了人的价值。作者过于强调”编程不过是一门失传的艺术的别名“（这个问题，之前有很多的讨论，这里就不展开讨论的，编程是艺术，更是工程技术），全篇吐槽较多，有不少的武断的结论（如“‘机器学习’这个名字，完全就是一个幌子”；“几乎没有 AI 研究者真正做过人脑或者认知科学的研究”......），甚至连Agile、Scrum、TDD躺着都中枪。作者其实不了解Agile，敏捷价值观之一：个体与协作胜于流程和工具，特别强调人的价值和团队协作沟通。
我也承认，完全自动、全生成代码非常困难（也不能说不可能，时间也许能说明一切），因为基于需求的自然语言处理、业务规则学习到自动建模都很困难，而且大家不希望千篇一律的代码，而是希望有自己的风格、个性和特色。除非：
各个企业、各个产品不追求个性，而追求组件标准化、接口标准化、UI标准化；
需求的标准化定义，类似BDD、实例化的需求描述。
做到上述两点，其实很难。但人机协作开发还是比较合理的，比较直观的说法就是：人机结对编程（man-machine pair programming，MMPP）——每个程序猿配一个机器人，程序员和机器人助手协作完成编程，机器人助手更多是领会业务、需求和程序员的意图，从已有的代码库选择合适的代码段（代码块、组件）向程序员推荐，由程序员决定是否采用，并进行修改。程序员写的代码，机器人助手可以进行静态分析和代码评审，发现代码中的问题，及时提醒程序员。这种人机结对编程对校招程序员、或能力较弱的程序员有更大的价值。即使对资深程序猿价值会低一些，但其价值也不低，例如像BAT和华为这样的大公司，假定有2万程序员，如果效率提高20%，每年相当于增加了4000程序员的输出，产生12个亿（按每个程序猿30万的成本计算）的价值。
结对编程(pair programming)，是极限编程（eXtreme Programming）提倡的一种实践，两个程序员在一个计算机上共同工作，其中一个程序猿输入代码，而另一个程序猿审查前者输入的每一行代码。两个程序员经常互换角色，写代码之前可以相互讨论程序设计思路等。在实际项目中结对是经验分享、相互学习的最好途径之一，具有很强的针对性，不仅相互之间可以学到对方的一些技术和技巧，还可以学到对方的思考问题方式、解决问题的方法。
结对编程可以提高代码质量是毫无疑问的，但能否提高工作效率一直存在争议。直观上看，两个人同时写一段代码，感觉效率不高，所以某些著名公司根本不会允许“结对编程”的实施。但也有不同的观点，认为当一个人在遇到疑难问题时，很容易走入死胡同。而结对则不同，一个人有了想法，首先表达出来让自己的同伴理解，经过讨论达成共识后才开始编写代码，这样的代码经得起考验。发现了问题可以及时的指正，并互相促进、互相鼓励，保持良好的开发节奏，使整个开发既有效率也有很高的代码质量。所以，与单独工作的程序员相比，结对编程的确增加了交付代码所需的工时（实验表明增加了15％到100％），但是生成的代码缺陷减少了30％以上，因为减少了程序中的缺陷，从而很大程度上降低了回归测试、缺陷报告和修正等返工的代价，能够抵消写代码增加的工作量，甚至还节约了总体时间成本。
结对编程还受到心理、环境等其它因素的影响，只要是两个人的结对编程，这种争议会一直争论下去，因为无法做精确的对比实验，很难找到作为结对编程的一组的两个人和另外分开编程的两个人的能力、知识和经验等都是一样或等价的，所以难以证明结对编程一定是更有效的开发方式。
要打破这种争议，只有靠人机结对编程。在程序猿编程过程中，机器人搜索代码库（公司内部代码库、开源代码库）给程序猿推荐最匹配的代码；程序猿写完代码，机器人可以对这些代码进行静态评审、分析，及时发现代码中的问题。人机结对编程绝对节省时间，又能提高代码质量，质效双收。
由机器人推荐代码倒是可以的，除了自家的代码，还有10TB数量级的开源代码，虽然有些代码质量比较差，但还是可以选出20%高质量的代码，也有2TB的代码。虽说不能节省程序猿50%或更高的工作量，可以节省程序猿（特别是非资深程序猿）20-30%工作量是比较容易达到的。
如何向程序猿推荐代码呢？
一些大学的学者和一些优秀公司（微软、谷歌等）的研究人员在“软件工程、程序设计语言、人工智能”交叉学科方面做了大量的研究工作，初见成效，推出了一些原型化工具，主要包括两个方面：
从所利用的输入信息源上看，可以分为基于功能描述、基于代码上下文、基于输入/输出样例；
从所使用的智能化技术上看，可以分为信息检索、模式挖掘、优化搜索、统计模型、深度学习。
其中，深度学习技术得到了广泛应用，也展现了良好的效果，因此被寄予厚望。这方面研究也形成了“基于搜索的软件工程”的学科分支，进一步细分为“代码自动生成与推荐”、“代码搜索与API推荐”、“智能化缺陷修复”等更具体的研究领域。从目前研究成果看，离在工业界推广“人机结对编程”已经不远了，预计两年后一些大公司会投入试用或全面实施阶段。
正如前面所述，由于需求的模糊性以及开发者意图的开放性、软件项目业务和技术领域的多样性、软件代码数据的质量问题等根本性困难，仅仅依靠深度学习技术还很难期望代码自动生成与推荐通用的实现质的飞跃。但是，如果像一些大公司，专门针对自己的业务和特定的技术领域（就像机器学习忠实于数据），然后加强需求的明确性和人机交互智能的研究，这种实现的难度会降低。而且我们不期望代码的自动生成，而集中于相似代码的推荐和程序猿新写的代码分析，就容易实现应用价值的代码推荐框架或工具。过去，我们也会经常通过代码搜索寻找可用的代码片段甚至模块，进行大粒度的代码复用。这时，机器人助手采用“拿来主义”，推荐相似的代码片段甚至模块并指导开发人员进行修改就是一种有效的方法。
当软件架构趋于SOA架构、特别是微服务架构，人机结对编程更容易获得突破。在API推荐上，人们的研究成果已经具备初步的应用价值。人机结对编程是一个更容易让机器学习的动态协作过程，有助于基于业务领域、通用 /特定API和当前软件开发技术背景等的知识发现（借助知识图谱方面的研究成果）、理解与澄清，同时也完成部分代码的标识工作，有助于无监督学习和有监督学习混合算法的实现。
人机结对编程，就是人机协同的交互式智能，在这个过程中，程序员会及时纠正机器人的错误，改进机器人学习的模型。根据之前的研究，多个机器人的竞争学习机制（类似AlphaZero学习速度是AlphaGo的十倍），使得编程机器人学习要快得多。一个大公司或大的产品事业部采用人机结对编程，将包含了程序员（人）的群体智能，而且包含了多个机器人的竞争学习机制（而不是一个机器人），以多形态、多层次的智能化推荐的方式展开，机器人之间可以相互学习，由粗到细逐步演进和优化，未来“人机结对编程”应用价值不可限量。
（最近的确太忙，此处水很深，就不展开，但能起到抛砖引玉作用
参考：