Group Details Private

Global Moderators

Forum wide moderators

Member List

  • 【转载】代码搜索引擎和代码浏览器 Sourcegraph 宣布开源

    文章转载自 https://static.oschina.net/news/100516/sourcegraph-is-now-open-source

    知名流行的代码查看工具 Sourcegraph 日前已宣布开源(Apache License),代码托管在 GitHub 上 https://github.com/sourcegraph/sourcegraph。

    替代文字

    Sourcegraph 被大众广为熟知正是因为它支持在 GitHub 上轻松浏览和搜索代码,Sourcegraph 这款 Chrome 插件称得上是开发者必备的插件,它可以让我们像使用 IDE 一样浏览和搜索 GitHub 代码。

    Sourcegraph 是一款能够根据语义来把 Web 上的开源代码编入索引的代码搜索浏览工具。你可以从代码仓库和安装包,甚至是函数里搜索代码,同时也可以直接点击被完全创建了链接的代码来阅读文档、跳转到变量定义或者马上找到可用的 Demo。总而言之,你可以在你的 Web 浏览器上完成这一切,而不需要配置任何编辑器。由 Sourcegraph 出品的这款 Chrome 插件,可以非常方便地浏览和搜索 GitHub 上的代码,持跨仓库(repository)搜索、跳转到定义、查找引用等功能,宛若一个功能强大的 IDE。核心功能如跳转到定义(Go-to-definition) —— 浏览文件或查看 pull 请求时,将鼠标悬停在代码上可以查看文档提示,单击即可跳转到定义、查找引用或全文搜索。

    官方表示,开源 Sourcegraph 是为了给更多的开发者和开发者生态系统提供代码搜索和代码语义智能感知,并帮助实现 Sourcegraph 总体规划:

    • 使基本的代码语义智能感知无处不在(适用于所有语言、所有编辑器和代码主机等)
    • 使代码审查持续且智能化
    • 提升开源代码的数量和质量

    事实上,Sourcegraph 的核心分析库早已开源,而且使用起来非常方便。它被称为 srclib(发音“Source Lib”)。强大的 srclib 支撑着所有你在 Sourcegraph 上看到的和语义分析相关的特性,同时也支持能跳转到函数定义和语义感知功能的编辑器插件。

    本次开源除了开源 Sourcegraph 的代码之外,还开放了其他产品和公司流程。如 Sourcegraph 的产品路线图、浏览器扩展、about.sourcegraph.com 网站等。Sourcegraph 的总体规划也一直是公开的。

    而成为 Sourcegraph 开源项目的 contributer 将可以:

    • 将 PR 提交给 Sourcegraph 开源项目
    • 在 Sourcegraph 上搜索/浏览 sourcegraph/sourcegraph,并讨论代码和文档
    • 查看、讨论并提议对正在进行的产品路线图的更改
    • 添加和改进文档
    • 构建 Sourcegraph 扩展以增强 Sourcegraph 和 GitHub 上的查看/审查代码

    相关链接
    Sourcegraph 的详细介绍:点击查看
    Sourcegraph 的下载地址:点击下载

    posted in The Tower of Babel 共建巴别塔
  • 【转载】智能化开发实践路在何方

    文章转载自 CodeWisdom,原文《智能化软件开发沙龙微访谈系列第3期-智能化软件开发实践路在何方》,地址:https://mp.weixin.qq.com/s/EPbHHTY4n1LNdoHaqwuQqA

    智能化软件开发微访谈是由CodeWisdom团队主持的围绕代码大数据与智能化软件开发相关主题的线上沙龙。通过线上交流的方式将学术界和企业界的专家学者汇聚到一起,共同探讨实践问题、技术发展现状以及未来发展前景。


    0_1540435874751_640.jpeg

    访谈简介

    随着规模和业务的不断增长,许多软件和互联网企业都积累起了大量的软件开发数据,同时所面临的软件开发进度、质量和效率等方面的压力也越来越大。大数据和人工智能技术的发展使得数据驱动的智能化软件开发成为许多企业的关注热点,甚至一些软件开发岗位即将被AI取代的言论也不绝于耳。
    一些业界领先的企业已经率先在这些方面进行了深入的探索和实践,他们在哪些方面已经取得了显著进展?未来的智能化软件开发将会是怎样的一番景象?哪些智能化软件开发方向值得企业长期追寻和投入?哪些企业亟需解决的智能化软件开发技术问题需要学术界进一步关注和探索?
    围绕这些问题,我们在2018年10月20日晚19点邀请了几位来自业界领先的软件和互联网企业且在智能化软件开发有深入实践的专家,以微访谈的方式与大家分享和交流相关观点和看法。

    嘉宾

    彭鑫(兼主持人)
    复旦大学计算机科学技术学院
    教授、博士生导师
    Dr. Xin Peng Professor
    School of Computer Science, Fudan University
    个人主页:http://www.se.fudan.edu.cn/pengxin
    Email:pengxin@fudan.edu.cn

    黄泥
    华为研发能力规划负责人,软件工程方法和工具专家。长期从事软件开发模式方法、测试自动化和工具平台的规划设计工作,支撑研发效率提升和高质量交付。


    李涛
    百度工程效率总监,百度平台化委员会秘书长,CCF软件工程专委会成员,软件案例研究峰会TOP100 Summit2017联席主席,全球运维技术大会CNUTCon2018联席主席。目前在百度致力于工程领导力(Engineering Leadership)、卓越工程能力(Engineering Excellence)和软件智能开发(Development Intelligence)平台规划与建设,关注领域主要在人工智能、开源、平台治理、精益、敏捷、DevOps、微服务等方向。译有《用户故事地图》、《移动计算原理》。

    张刚
    软件工程博士,软件开发方法学专家,Emergent Design Inc.创始人,CCF软件工程专委会委员,Bell Lab DMTS(杰出工程师)。
    长期致力于领域工程、软件架构及敏捷与精益开发方法的一线实践。


    楼建光
    博士,微软研究院软件分析组首席研究员,CCF系统软件专委委员。近年来从事软件分析方面的研究与应用,将机器学习、数据挖掘与软件工程相结合,研究项目包括大规模系统日志的分析和挖掘,在线系统的智能监测、智能诊断与运维等方面。多项成果在微软公司的大规模在线系统实践中得到广泛应用,其中部分相关工作发表在软件、系统及数据挖掘相关的知名国际会议(ICSE,ATC,ASE,KDD,ICDM等)。

    孤尽
    在阿里历任技术研发、架构师、部门主管等不同的角色,承担过双十一、国际化、代码中心等大型项目,有着丰富的一线编程实战和架构经验。目前是集团代码平台负责人,在大数据、高并发、分布式、代码效能等领域均有较深的造诣,目前带领团队正在部署代码智能化方向的建设。


    访谈主题

    1. 对于数据驱动的智能化软件开发是如何理解的?它能从哪些方面改变现有的企业开发实践?
    2. 所在的企业或者您所了解的企业在数据驱动的智能化软件开发方面开展了哪些探索和实践,在哪些方面已经取得了显著进展?
      3.未来(五年、十年、二十年之后)的智能化软件开发将会是怎样的一番景象?哪些软件开发岗位会发生显著的变化,例如现有的岗位消失、新的岗位产生、原有岗位的职责和工作方式发生重大变化?
      4.哪些智能化软件开发方向对于企业具有长期的价值,值得企业长期追寻和投入?
      5.有哪些企业亟需解决的智能化软件开发技术问题需要学术界进一步关注和探索?对于从事智能化软件开发技术研究的学术界研究者有什么建议或期望?请工业界的专家给学术界提一下期望。

    Q&A记录

    数据驱动的智能化软件开发大家都很关注,但其含义很广泛,不同的人有不同的理解。有的人抱着乐观和激进的观点,认为很多企业软件开发工作都将被AI取代了;有的人则抱有较为保守和现实的观点,只是希望某些开发工作的自动化以及工具支持的程度能够再高一点。为了对智能化软件开发实践有个深刻的认识,我们邀请了几位来自业界领先的软件和互联网企业且在智能化软件开发有深入实践的专家,以微访谈的方式与大家分享和交流,让我们来听一听他们对于智能化软件开发实践方面问题的观点和意见。

    Question 1

    您对于数据驱动的智能化软件开发是如何理解的?它能从哪些方面改变现有的企业开发实践?

    黄泥:
    对智能化软件开发的理解,AI/Data Enable/Driven Software engineering。即用好软件全生命周期的代码,需求,用例等海量数据数据及文档,文件等通用领域信息数据,改进软件开发过程,改善开发者体验,提升开发测试作业活动的自动化程度,生成部分交付件,优化性能 /UI 人机交付/安全性等运行时属性。智能化软件开发的三个目的:1)改善开发者体验,程序员还是个比较辛苦的工作;2)提升软件开发/测试工作的自动化程度,现在从时间和空间看很多事情都在重复和反复的做;3)代码或者软件能不能自动生成,或者进行自动的优化。

    李涛:
    数据驱动是互联网的基本工作方法,过去更多用在产品上,比如数据驱动决策,通过实验来决定一个功能的取舍,并发展出非常多的方法和平台,比如抽样机制、生效机制、数据的获取与分析。不过在企业研发环节所用很少,工程方法在一定程度上滞后于产品机制创新。现在更多是补课,过去都是鞋匠的孩子没鞋穿。工程师主要的时间在查资料和读代码,写只占很少一部分。每天的代码量都在50-100行之间。我们更关注对代码的学习和理解辅助,尤其一些常犯的错误。

    张刚:
    我从自己辅导团队和自己编程的经历来谈一点自动化之外的看法。除了自动化之外,我觉得有几个方面智能化软工对程序员会有很大的帮助。它们是:1)未知的未知; 2)膨胀的信息; 3)解决方案的复杂性。

    先说未知的未知,我最近几年和创业团队打交道很多,接触了不少初级程序员。很多时候,这些问题往往并不复杂,而是缺乏做出对应决策的知识和经验。举一个例子,一个程序员看到别人的接口定义很优美,但是不知道Swagger可以自动生成这么一个Spring Server,只好自己在代码中加了很多Swagger的标记,结果花了一个多星期还没搞定。这是“不知道自己不知道”带来的一个很典型的例子。这种问题,也许如果我们的专家知识能有AI帮助的话,程序员说:我要写接口文档,也许就会有相应的像专家那样的提示,是不是很好。这个问题,本质是因为软件的问题在于解决方案非常多,但是在特定的上下文约束下解决方案就变少了。现实的问题是:上下文非常丰富,特定程序员遇到所有上下文的场景不可能。但是如果把这个问题放到所有的程序员群体的话,这个上下文就足够丰富了。我认为数据驱动的智能化软件开发,在大量数据的支持下,必然能够拓宽程序员知识的边界,有希望从本质上解决这个问题。

    第二个方面,信息膨胀。比如说日志,海量的日志,很难理解。还有在微服务构架下,非常多的服务实例,一般系统,不停增长的代码。这些膨胀的信息,挺难被人掌握的,他们有结构,但是结构性又不是那么强。这一类问题,我觉得智能化软件工程能够有所作为,无论是知识的梳理、归类,还是抽象。
    第三个方面,是问题域之外的复杂性。软件中除了问题本身的复杂性,还有很多由于解决方案带来的复杂性,比如具体的框架,具体平台,具体数据库,特定的通信方式,特定的语言特性,都需要程序员掌握。这些我觉得太细节了,AI应该能帮上忙。

    楼建光:
    我认为,数据驱动的智能软件开发是在软件的整个生命周期中的每一个环节收集各种数据,并通过对数据的分析和建模来提高软件开发维护的效率和提高软件质量的方法论与实践,具体可以分为几个层次包括数据支持决策,开发流程自动化,以及智能化。数据驱动的智能化软件开发需要软件开发团队甚至整个公司营造以数据决策为中心的文化,仔细为开发的每一个环节设计需要收集的数据,搭建数据收集、存储、处理、分析建模的基础平台和技术工具,并在实践中应用和不断改进。在当前软件即服务的时代,软件自动化技术包括测试自动化、部署自动化、维护监控自动化、在线A/B测试等等技术极大地提高了软件系统开发和维护的效率,同时也保证了超大规模软件服务的质量。使得软件版本更新周期变得很短,缩短新功能的面市时间,建立软件全生命周期的闭环,特别是将用户对软件功能的反馈融入在闭环中。

    孤尽:
    我认为接近人类自学习思维的智能化,在当前是不可能的,也很难趋近,大脑的记忆和信息处理方式,目前也是一个科学难题。现在做的软件研究更多的是基于数据的自动化。个人认为,软件开发的生命周期中,软件工程师需要做的事情过于沉重,需要理解需求、编码开发、构建发布、测试等,为了提高开发效率,需要综合各种自动化的方法去帮助工程师减负,而目前所谓的智能化本身就是数据驱动的自动化,在软件开发过程中目前已经有了丰富的数据量及数据种类,单靠传统规则的方式很难有效的利用起来,所以需要利用智能化的方式去挖掘软件开发数据的二次价值。比如说之前工程师需要花费60%的时间去排查问题,如果能通过智能化的方式去协助排查,那么为工程师带来的效率提升也是很可观的。所以软件研发的智能化不仅能提升工程师的开发幸福感,也能帮助企业快速达成战略目标,减少研发成本。总得来说,软件智能化的本质是有效提升代码产能,推动软件产业进步。

    讨论环节

    彭鑫: 看来所谓智能化,很大一部分含义还是在自动化上。软件开发本身就是一个智力密集型劳动,所以很大程度上自动化就意味着智能化。很多人都认同的一点是,智能化开发能够减少重复性劳动和重复性思考就已经很好了

    黄泥: 自动化是关键,特别是重复性,开发者比较讨厌的工作。

    彭鑫: 数据和量化管理早在CMM/CMMI中就已经非常重视,但当时还是只是从软件开发过程能力的角度。与大数据与人工智能技术相结合直接,数据和量化与自动化工具相结合将直接提高企业以及个人的软件开发能力。另外,建光还强调了当前软件系统的一个特点,那就是超大规模服务化软件系统逐渐成为主流。

    彭鑫: 大家可以明显感受到,阿里这样的互联网企业也非常重视软件工程能力的建设。

    楼建光: @孤尽 的看法比较接地气,从实际工程师角度看待问题,更加有亲切感。

    张刚: 自动化在智能化中很重要,但是也肯定很不容易。自动写代码,自动运维,自动发现缺陷,这个场景,想想就觉得幸福。

    彭鑫: 确实,我们现在说的智能化与人类智能相比还很遥远。但是从工程本身的含义来看,我们本来追求的也是好用实用。所以我们说的智能化其实只是一种更好的自动化。传统的基于规则的自动化已经很难进一步提升,大数据和AI技术的发展为我们提供了一条新的途径。

    彭鑫: 刚才说到了智能化软件开发的一个现实目标:减少重复性劳动和重复性思考。张刚这里提到了另一个:让初级程序员做出像高级程序员一样的工作。

    孤尽: 让初级程序员做出像高级程序员一样的工作。这个我非常认同。

    黄泥: 这个目标HR和老板都喜欢。

    孤尽: 是的。如果未来能够让一个程序员通过智能化干两个程序员的活,那更好。

    楼建光: 不过,一般知道自己不知道的人,往往是比较好处理,而@张刚 提到的不知道自己不知道的问题是最难的。

    张刚: 嗯,知道不知道,就去找方案了,比较好办。不知道不知道,确实很痛苦。

    彭鑫: 学术界有这方面的研究,例如今年ICSE上的Nick C. Bradley, Thomas Fritz, Reid Holmes: Context-aware conversational developer assistants. 993-1003这类工作目的是让小助手统一接入各种开发工具,根据用户的命令(例如语音)打通各种工具完成用户交代的任务。这需要以上下文和知识为基础融合各种开发工具。

    黄泥: “未知的未知”搜索空间太大,不确定性大,需要更多的信息定义边界。

    彭鑫: @黄泥 所以AI小助手的主动提醒和推荐就很重要了。

    黄泥: 要能理解工作的上下文,你是谁,在干什么。

    彭鑫: @黄泥 对,共享的任务上下文是智能化集成各种工具的基础。

    彭鑫: 信息膨胀是个大问题。很多企业对于自己所拥有的软件资产是什么样子的都没有一个清晰的全貌,因为太复杂同时在不断演化,文档基本指望不上。
    张刚说到的解决方案的复杂性反映了现在软件开发整体的工具和技术栈过于复杂了。一般我们可以通过抽象来降低复杂度,即底层的一些细节我们就不关心了,但需要关心的还是不少。
    鞋匠的孩子没鞋穿。百度应该已经属于业界比较领先的企业了。我们很多软件企业对于自己的软件开发数据的处理和分析能力其实还很弱。

    李涛: 不管是自动化还是智能化,路都还比较长,有了很好的工具,还要推广使用才能产生影响。目前不论是SE+AI,还是AISE,工程方法上明显都滞后。

    彭鑫: 看来阿里和百度的智能化软件开发实践都是从基本的开发规范开始的,这部分其实没有那么智能更不神秘。

    楼建光: @李涛,对,其实现在智能化还很初级,能先尽量过程自动化已经很好了。


    Question 2

    您所在的企业或者您所了解的企业在数据驱动的智能化软件开发方面开展了哪些探索和实践,在哪些方面已经取得了显著进展?

    黄泥:
    华为一些实践:1)大规模测试执行日志的自动分析,华为的代码规模和测试用例规模都特别大,测试执行自动化了,分析结果,分析失败原因,定位是哪个部件和人的问题很花时间。目前的进展非常好,用1年的执行日志数据/问题数据训练,能够判断50–60%的问题。2)代码静态检查规则和告警修复的优化。

    李涛:
    像代码搜索、缺陷预测、克隆检测、程序理解、代码生成和补全,大多都已经在小流量,代码搜索是最喜闻乐见的,其中的大部分大规模应用都还有些距离,对外产品化和提供服务会更遥远。

    楼建光:
    作为全球最大的软件企业微软很早已经开展了数据驱动软件需求和质量分析的实践探索。例如,OFFICE team十多年前就开始一个名为SQM的大规模数据处理分析项目,收集数据并分析数据用来帮助Office产品的开发。几乎同时,为支持微软的十几个软件的开发,像Watson、PerfTrack等数据驱动软件分析项目纷纷启动(如果有谁对相关工作感兴趣可以参考SOSP及ICSE的文章了解)。到2012年,我们公司全面转向云计算服务后,全面拥抱数据驱动软件自动化,软件自动化技术特别是测试自动化技术的成熟使得测试工程师这个传统软件开发中的职位消失了,取而代之的是很多产品线配备了数据分析团队,软件过程自动化技术和工具得到大力发展和更加广泛的应用。例如,autopilot这个自动化工具极大地提高了效率,使得部署和管理超大规模集群变得轻松高效。再如,大量与数据挖掘和机器学习结合的软件分析方法应用到大规模在线软件服务的开发和日常运维实践中(代码推荐搜索、基于日志自动分析的监测、诊断、预警等技术),在保证质量的同时大大提高了效益。在这些方面,我们研究组与不同的在线部门开展了卓有成效的合作,从最早的SQM数据分析直到现在Azure云计算平台数据计算,将很多上述提到的数据驱动软件分析技术和方法应用到生产实际中,并取得了非常好的效果。

    孤尽:
    阿里巴巴的代码体量是比较庞大的,整个体系内的代码包括淘宝、天猫、优酷、高德、菜鸟等等,当前我的团队以智能与效能两线并行的方式,这两条线都由我来统一作为Leader,相对来说更加容易形成化学反应,智能能够效能来实践和落地。有些功能点,我们会在明年适当时间进行整体开源。举例来说,当前在缺陷检测及修复领域,像ubisoft的commit assistant、facebook的SapFix等有过一些实践;在代码生成或者Code clone领域,微软、谷歌、intel等都有过一些探索,但是没有比较成熟的产品发布。目前阿里在缺陷检测、代码补全、代码推荐等领域正在做一些探索和实践,其中在缺陷检测和优质代码推荐方面已经取得了一定的进展。

    讨论环节

    彭鑫: 我们来为微软的实践介绍划重点:测试工程师这个传统软件开发中的职位消失了,取而代之的是很多产品线配备了数据分析团队。

    彭鑫: @楼建光 测试职位的“消失”(估计也没有完全消失)是不是与DevOps实践有关?

    楼建光: @彭鑫 跟DevOps有关系,职位消失了,测试工作没有消失。

    孤尽: 测试工程师消失了,从组织、流程、程序理解度、智能化都有一定的原因。以前阿里巴巴还有专门的质量保障部。

    彭鑫: @孤尽 能否简单概括下缺陷检测和优质代码推荐方面目前达到的水平?

    孤尽: 目前这个数据还在试验校准中,后续活动可以同步给大家。

    彭鑫: 看来大企业的智能化软件开发实践水平已经很高了,这对于我们的研究工作也提出了更高的要求。

    张刚: 失败原因的定位确实占去了错误修复的大多数时间,而且很没有幸福感。如果这方面能有突破,价值不是一般的大。@黄泥

    苏亭: 错误的定位这个问题确实很重要,但很多时候和特定的软件相关,并不一定有通用的方法。

    黄泥: 不期望有通用的方法,目前看用一个团队的历史数据比其他团队的数据更有效。

    彭鑫: @苏亭 其实刚才谈到的很多技术都有这个问题,例如代码推荐,容易做的可能首先是一些通用功能代码。

    楼建光: @苏亭 有一定道理,这也是@孤尽 说的市面上没有通用工具的一大原因。

    苏亭: 恩,最近我们做了一个针对android app发生crash信息的分析,看了很多crash的错误,发现root cause的原因也很多。但是确实存在一些pattern,能用于自动化的缺陷修复。

    蔡元芳: @彭鑫 软件开发实践都是从基本的开发规范开始的,我们的体会是开发规范直接影响数据质量,否则garbage in garbage out. 是不是可以说数据驱动可以有效实施的前提是规范的管理?

    彭鑫: @蔡元芳 是的,就从基本代码质量来看,为什么Google的代码复用率那么高,因为代码规范,不光是命名也包括模块划分。这样即使用简单的信息检索可能效果已经很好了。

    黄泥: 目前的实践看训练出的模型泛化能力很一般,比人总结的规则要差很多。

    楼建光: @蔡元芳 特别有道理!数据质量问题是一个很大的问题。

    蔡元芳: @彭鑫 除了代码规范,提交,设问题单,都得规范吧?

    李涛: @蔡元芳 很多错误都是重复再犯,考古意义重大。

    楼建光: @蔡元芳 目前大部分公司数据收集和数据质量管理还比较粗放,对数据收集时如何回答"where,when,what" 等问题和如何提高数据收集的效率和效益方面,缺少系统的方法和工具。比如开发人员在决定在哪里打印log和打印什么数据时相对比较随意,也不知道log会带来什么开销,使得很多资源浪费和损失,数据中的噪声也给分析算法制造了不必要的难度。

    蔡元芳: @楼建光 我们的体会是在开源好用的工具到企业就不好用了。

    彭鑫: @楼建光 是的,这些问题都是学术界考虑比较少的。


    Question 3

    根据您的分析和判断,未来(五年、十年、二十年之后)的智能化软件开发将会是怎样的一番景象?哪些软件开发岗位会发生显著的变化,例如现有的岗位消失、新的岗位产生、原有岗位的职责和工作方式发生重大变化?

    黄泥:
    5年后专职测试工程师大幅度减少,数据工程师,数据工程师专业角色,发布工程师,SRE减少(占比),绝对数量持平。大幅度降低质量保障的人力投入。
    10年后low code开发 UI开发难度大幅度降低,维护难道和工作量大幅度降低。大幅度改善软件重用。
    20年后初级编程变为如同开车和英语一样普通技能,软件的自主演进。大幅度降低新创和软件维护难度和成本。

    张刚:
    我按目前的岗位划分说一下个人理解:1)更靠近需求侧的岗位,产品经理、需求分析人员,价值会变得更大;2)资深的领域分析人员,资深的架构师,应该更重要,但是数量应该会变少。上述两种岗位都应能从智能化软件开发的发展中提供的更多信息和知识中得到更多支持。
    测试岗位,目前就已经逐渐和需求、开发融合;像缺陷修复这类事情,有希望能完全消失;程序员的工作应该会更偏向于创新的动作;重复的增删改查肯定是不用写了;重复发明轮子的情况应该是越来越少;复杂的非功能性决策,例如如何缓存等等,应该可以基于运行时信息自动调整和修复;架构会变得动态;甚至会和运维深度融合;专业领域来看,软件的安全类问题这是一个程序员都不太熟知,但是出问题很多的领域;AI成长起来之后,不再会是一个核心困扰;此外,框架和系统的使用应该变得更加容易。

    楼建光:
    当前智能化软件开发主要在软件过程全面自动化阶段,智能化开发尚处在初级阶段,还没有大规模普及应用,还有很多问题亟待解决。
    随着数据驱动的软件开发技术的发展与成熟和普及,很多工作岗位都会发生很大变化。近几年已经出现了对数据分析技能的强大需求。比如目前在在头部公司已经发生的现象,原来的测试工程师、DBA等的部分工作会被自动化工具所替代,而同时产生对数据分析建模技能的需求,在5年内这样的情况应该还会继续深入在整个行业发展。
    当然程序员也一样需要适应新技术的革新,将来随着程序片段的自动生成和自动优化技术的发展,使得程序员可以更关注程序的逻辑和功能,而不是具体代码实现。十几年前,最流行的编程语言是C/C++,而现在大部分程序员可能只写python代码,学习门槛降低很多。将来很可能像Declarative language那样写程序,只要写清楚"what"而不需要关注"how",因为很多实现细节和优化通过智能化软件开发工具自动搞定了。甚至新近才出现的算法工程师的工作内容也会不断革新变化,比如类似AutoML这样的工具可以帮助快速找到最优机器学习算法和参数从而替代一部分人力。

    孤尽:
    第一、在未来5年内,期望出现一个研发智能助手的概念,现在各种语音助手、购物助手有很多,那么我相信在短时间内,属于软件开发的助手也会出现,它能根据工程师的需要协助工程师编码开发、智能测试、缺陷检测、提供API文档等,形成真人工程师与虚拟工程师的结对编程。5年之后的,自动化分析基本成型,程序员的能力模型发生了变化。

    第二、未来10年内,能进一步提升智能助手的智能化能力,具备初步的语音理解能力,完成更多低级工作,解放工程师的生产力。或者说三极管与十极管出现,计算机的架构方式有了重大转折,更高的计算复杂度,促进神经网络海量运算的完善和智能化思维的出现。

    第三、20年之后,说不定能出现根据需求文档自动实现功能模块,根据软件运行状态,自动的完成代码的进化,并依靠的代码的进化,实现智能助手的自我成长。或是自然语言甚至是语音的编译器产生,大大人类文明进程。

    第四、智能化软件开发的出现,对软件测试工程师、交互工程师、运维工程师等都会形成竞争压力,同时也会孕育出智能训练师等新岗位的出现,说不定以后工程师不需要再写代码,而只需要作为智能机器人的老师,去教育它,让它从软件开发的新生儿,成长为软件开发的大牛。

    李涛:
    YY一下,哈哈。五年内,每位工程师都会有一个云端的结对编程的助手,水平还比较一般,相当于毕业生一年经验的水平,每五年可以提升1年的经验,人机协同进化,只是速度不会太快。现有的测试和运维积累的技术和平台,大规模左移到编程现场,流程右端的人力需求和占比都会越来越小,20年后全部消失。大家都可以到编程环节做更多创造性的工作,同时也更好满足社会对于软件日益增长的需求。

    讨论环节

    彭鑫: 看来专职测试工程师首当其冲,跟医疗领域的影像科读片医生一样,最容易被取代。

    张刚: 测试工程师减少,还有有一部分原因是开发者测试成为主流。

    刘旭: @张刚 是的 现在自动化测试用例基本都是开发在写。

    苏亭: 这个观点挺合理的,开发需要写测试。

    彭鑫: 因为测试反映对需求和设计的理解,程序员如果不会写说明对需求和设计没理解。

    楼建光: 是的,开发写了部分测试,再结合测试自动化。

    刘旭: @楼建光 只要写清楚"what"而不需要关注"how"。从控制学科的角度,这是我们追求的自动化,以前只是写单元测试 现在什么测试都是开发在写了。

    刘烃: @黄泥 你的意思淘汰速度与智力程度直接相关?但未来是否会类似其他行业,一部分机器可以代替的工种依旧会长期存在?

    黄泥: 不一定同智力程度相关,有时同经济性和社会分工也有关系。

    彭鑫: 旧有岗位被取代往往伴随着新的岗位诞生,软件开发企业自身的开发数据收集和分析将会越来越重要。

    彭鑫: 智能化软件开发的一个远期目标可能是最终用户编程。专业程序员负责提供软件构造块,最终软件应用由最终用户以声明式的方式来产生。

    苏亭: @张刚 缺陷修复能完全用机器取代吗?

    张刚: 哈哈,反正是畅想嘛,dream一下美好生活。

    彭鑫: 总之以后软件开发的饭碗数量可能会减少,低端程序员会大量消失。不过也许另一类工作岗位会出来,就是给AI打工的人,例如帮助AI小助手提供反馈和测试校验的。
    苏亭:这么多新的智能软件开发技术出现后,好奇如何保证这些软件本身的质量。比如新型编译器出来后,如何保证他们的正确性也是个问题。而且这类智能软件的测试可能更难。

    彭鑫: 我也没那么乐观。语音助手连日常闲聊都还不是做得很好,更不用说创造性的编程任务了。


    Question 4

    您认为哪些智能化软件开发方向对于企业具有长期的价值,值得企业长期追寻和投入?

    黄泥:
    软件工程师规模大,工资待遇高,研发投入巨大。软件工程师工作中,重复性的、让人厌恶的事情多,加班时间长,还需要持续的学习新知识,新技能。对于人多、重复性、数据量大的环节,能够产生数据->利用数据->评估结果的闭环的活动。下面几点我认为值得长期追寻和投入。
    A 测试用例,测试代码的自动生成,已有测试代码的自动升级和演进;
    B 软件的自动化演进(编程语言,工具,库,补丁,接口,开源软件的升级的自动化适配,升级);
    C 软件工程信息的自动化生成或者补全,比如注释、代码提交信息、Review信息、问题单。
    D 代码生成或者转换技术,编程语言To编程语言,DSL To编程语言,自然语言To 编程语言 ,编程语言的补全。
    E 下一代的编程开发环境(AI助手,触摸屏,语音交互,VR,降低脑力和体力负担).

    张刚:
    我觉得高层的信息决策支持更重要,高层往往看不到细节。智能化运维,这一块在应用场景上我觉得比较现实,现在的运维还是挺痛苦的。

    楼建光:
    我说的可能没有@黄泥 那么具体,因为内容太多了。对软件企业来说,应该收集与分析整个软件生命周期的数据,在智能开发助手、测试自动化、部署和管理自动化等技术方面不断投入,提升软件过程自动化水平,提高开发过程效率和资源利用效率。

    孤尽:
    对于企业来说,最具有价值的无疑是如何提高工程师的开发效率和质量,带动企业代码文化成型和发展。只有开发效率提升了,才会迅速将企业的战略目标落地,快速抢占市场份额,而只有开发质量提升,才会提升企业的信誉度以及用户的好感度,扩大市场的规模。针对开发效率的提升,代码片段级补全、代码推荐、代码克隆、API文档实时推荐等都会为工程师带来较强的体感,在一定程度上能提升工程师的开发效率;而针对开发质量,代码的缺陷检测、缺陷修复、自动生成测试用例、优质代码挖掘等方面同样会为工程师带来研发幸福感的提升。

    李涛:
    我觉得是对数据的理解,包括程序代码、软件运行过程中的历史数据、编程现场数据等等。从现在我们的进展看,越往前推进,越觉得对这些数据的理解有很多欠缺。也期待各位老师和同行的指导。

    讨论环节

    彭鑫: @黄泥 看来都避开了需求和设计等高度经验化和不确定的环节。在很长一段时间内,智能化开发比较现实的追求还是在测试、演进以及一些信息补充和转换方面。

    彭鑫: @楼建光 收集软件生命周期数据是第一要务。

    楼建光: 我感觉目前阶段还是要把大头放在提高自动化水平上,收集数据是数据驱动的前提。

    彭鑫: @孤尽 软件开发效率上升到了抢占市场的高度,软件工程的重要性进一步提升了。

    蔡元芳: @彭鑫 其实软工的根本目标就应该是如何帮助产品尽快占领市场,长期占领市场。

    彭鑫: @蔡元芳 也包括可持续发展,能够支持软件的长期持续和快速演化。
    @李涛 提到了数据理解的问题,当收集的数据多了之后如何理解会是个问题。
    @张刚 那我问一个问题,为什么云计算发展这么多年后,运维仍然问题那么多?虚拟机、容器等多个层次上的可伸缩性为什么不能保证软件的可靠运行?

    张刚: 现场问题的复杂性,远超过设计时能想到的复杂性。除了缺陷因素之外,运维复杂性的很多问题是其本质复杂性导致的。

    孤尽: 决策、执行、制度,都不可能是100%完美。这三个因素又是互相制约的。云计算不是药方,而是一个药店。

    李涛: @孤尽 因为本身坑就很大,开发绝大多数不懂运维,设计的时候也就不会考虑可运维性,系统最后就不可运维了。

    彭鑫: 我自问自答一下,现在很多在线软件系统都是复杂的生态系统了,之间的相互影响可能已经超出了原有的认知范围。混沌这种复杂系统中的名字现在也经常用在微服务系统等在线服务系统中了。


    Question 5

    您认为有哪些企业亟需解决的智能化软件开发技术问题需要学术界进一步关注和探索?您对从事智能化软件开发技术研究的学术界研究者有什么建议或期望?这个是请工业界的专家给学术界提一下期望。

    黄泥:

    1. codenet和基准测试比赛,标准代码分析模型和数据格式,编程语言的分析模型。
    2. NLP+AST?
    3. 大幅度降低机器学习+形式化设计与验证的应用成本,以适用于大规模软件。
      第一个建议是标准数据集和竞赛;第三个没想好,意思是数据驱动的技术如何同传统的技术结合,如软件分析,形式化设计验证。

    孤尽:
    学术界是有着非凡想象力的群体,可以不受企业机制、流程的束缚。而企业有大数据和大规模集群的优势。缺陷预测、代码补全、代码摘要等领域对于企业和工程师而言是非常有体感的,也是企业非常关注的重点,虽然部分领域已经取得了非常惊艳的成果,但是有些成果对于企业来说实用性、可落地性、可移植性等都略显差强人意,对于开发效率和质量的提升仍是有限的。比如有些成果在公开数据集上可能能达到较好的效果,但是一旦应用到真实的企业数据中就略显不足了。所以期望学术界能在研究过程中多结合企业的实用性及问题场景,多与企业达成良好的合作关系,各取所需,形成良好的学术与产品化的闭环,阿里期待与各位学术研究者有更深入的交流与合作。

    李涛:
    有意愿的教授可以创业,多开几家公司,就可以有更多可落地的产品。每个领域的繁荣,都会有成功的商业公司佐证。

    楼建光:
    我觉得大规模在线软件系统的快速诊断和修复技术是一个值得继续深入的从多个方面研究的问题(这个问题很复杂,刚才各位也有所讨论,一个词“混沌”)。不仅仅是数据分析,快速诊断也给软件构架提出了新的要求,现在流行的SoA软件构架有很多好处,非常灵活,但同时给在线系统的自动问题诊断和快速修复提出了挑战,因为现代大规模系统的子服务之间关系非常复杂而且是动态更新变化的。DOCK的提出和采用在一定程度上缓解了问题,但怎么自动基于运行数据来优化是一个值得进一步研究的问题。

    张刚:
    第一个,作为在一线工作多年的人,很盼望技术发展能取代各种相对简单、重复工作的技术;这个能给开发者带来更好的生活;自动化做不到,能辅助也很好!
    第二个,刚才大家提到了复杂性,我理解各种解决软件的“不可见”问题的技术也非常有价值;软件的复杂性,很多时候来自于不可见的细节太多。
    第三个能把信息按照人类的需求,进行抽象和概括的技术;人类的认知能力比较弱,需要机器帮助。
    第四个是需要大量信息才能决策的技术,例如刚才说的非功能性需求的满足和优化,自动调整等等。

    讨论环节
    彭鑫: @黄泥 代码大数据平台和基准、大数据如何与传统软件工程技术相结合。今年ICSME上有一个文档动态生成比赛,指定为开源POI项目生成API文档
    https://dysdoc.github.io/dysdoc3/index.html

    彭鑫: @孤尽 是的,需要合作。例如代码推荐和补全,很多文章实验结果已经很好了,但是不知道整体上处于什么水准,特别是应用于企业实践后是什么样子。

    彭鑫: @楼建光 这是AIOP智能化运维的范畴。已经看到一些应用机器学习和知识图谱进行在线系统故障和性能问题分析预测的研究了。

    楼建光: @彭鑫,是啊,SaaS时代DevOps变成AIOps了。

    彭鑫: @张刚 @李涛 对于学术界有什么建议和期望?

    张刚: 刚才我说的这些事情其实都挺困难的,软件的本质是复杂性。所以应该还有不少基础的事情也很重要,比如知识如何更好的表示,上下文如何更好的表示等等。

    李涛: 不敢说期望,我只是觉得很多软工的硕士、博士最后没能在公司继续做软件工程方向挺遗憾的,其实在百度和阿里,做软工的跑道都是很长的,可以说上不封顶。都空前的重视。

    彭鑫: @李涛 是的,我们很多做这方面研究的研究生最后都去做普通开发去了,确实很可惜。也可能是你们宣传还不太够。

    吴文胜: @彭鑫 我对程序员的命运是比较悲观的。在被取代之前做低头族看来是逃不掉的命运。问题就出在大家所提到的复杂度。软件复杂度的增长似乎是没有止境的。

    黄泥: 赞同老吴的观点,帮助缓解软件规模(复杂度)给开发者的困难,就很不错了。

    彭鑫: @吴文胜 嗯,所以智能化技术的发展速度要超过软件系统复杂度的增长速度。

    吴文胜: @彭鑫 我觉得在这两年看到了软件工程方面不少可喜的进展。

    彭鑫: @吴文胜 企业界的反馈也很重要。有时候学术界提供了一些原型工具给企业后就没下文了,哪怕能得到一些负面的反馈也好,因为知道哪里不足。企业界的认可是我们前进的最大动力,因为我们大部分研究都不是理论而是工程技术研究。平台、基准系统、比赛等都很重要。NLP和图像处理等很多领域这方面做得比较好,好处是整体的研究和实践水平大家一目了然,后续的研究工作针对性都很强。而我们领域可能是因为多样性和复杂性,导致这些方面做的不够好,其结果是各说各话,大家都生成自己的技术效果很好,但整体上处于什么水平大家心里都没数。

    posted in The Tower of Babel 共建巴别塔
  • SCC Project Progress Report NO.4_2018.10.21

    0_1540126715093_climb-2125148_1280.jpg

    Dear Community Members,

    Effected by some labour and financial issues, some of our projects have been delayed. Although we have successfully developed and launched the Task Distribution System 1.0 and Tool platform 1.0.

    Despite of all the difficulties and challenges we encountered, the SCC team still firmly believes in the necessity of intellectualizing software engineering, and will move forward on this path. We would also promote cooperation with universities to improve the status of the industry.

    Task Distribution System

    1.Complete the development and launch the product.
    2.Tasks are now being collected and would be released later in community.

    Tool Project
    1.0 version has been completed and launched.
    2.Business cooperation is now guaranteed. For more information, please contact: (Platform link) http://tools.sourcecc.io/Cloudtest-server/html/index.html

    Community Building

    1.dingdang-robot Smart Speaker Forum has officially been a part of the SCC community.
    2.Clear numbers of users who violate the activity rules or registered malevolently.

    👏 The number of valid registered members of the community are now exceeding 2,500. Thanks a lot for your attention and support towards SCC project! We shall strive without cease and live up to everyone’s expectation.


    SCC Team

    posted in English
  • SCC项目进展报告NO.4_2018.10.21

    0_1539865545519_climb-2125148_1280.jpg

    社区成员们好,
    近期因人力及资金问题,部分项目工作推进较慢,尽管如此我们仍成功开发并上线了任务分发系统1.0版本工具平台1.0版本

    虽然遇到一些困难,但SCC团队仍坚信软件工程智能化必要性,并将在这条路上继续前行,后续我们将大力发展与高校的合作,共同改善行业现状。

    任务分发系统

    1.已完成开发,并已上线
    2.正在募集任务,后续将在社区发布

    工具平台
    1.已完成1.0版本开发并上线
    2.可以支持企业合作,如有意向欢迎联系
    平台链接:http://tools.sourcecc.io/Cloudtest-server/html/index.html

    社区建设
    1.dingdang-robot 智能音箱论坛已正式迁入scc社区
    2.清除数名违反活动规则,恶意注册用户

    👏 社区有效注册成员已突破2500名 ,非常感谢大家对scc项目的关注和支持,我们也将继续努力,不辜负大家的期待。(小声说:希望大家活跃起来,不要一直潜水哦)


    SCC团队

    posted in 中文
  • 【转载】迈向按需的开发文档生成:开源软件项目API文档生成

    文章转载自 CodeWisdom,原文地址:https://mp.weixin.qq.com/s/EPbHHTY4n1LNdoHaqwuQqA

    软件项目开发文档缺失或陈旧是困扰开发者、影响开发效率和质量的一个大问题。针对这一问题的传统解决方案是通过各种信息检索技术搜索各种软件开发文档、制品和代码来获取所需要的信息,但其效果十分有限。为此,软件维护与演化领域的研究者提出了按需的开发文档(On-demand Developer Documentation,简称OD3)[1]的思想。其设想如下图所示:在开发者给定的查询及上下文信息的基础上,OD3引擎动态地从各种相关的文档、代码及其他制品中抽取相关信息并动态生成易读、易理解的开发文档。

    0_1538324793711_f8fb1a4d-487d-4e18-82df-34637cb4b9a4-image.png

    针对这一设想,相关研究者组织了动态软件开发文档研讨会(International Workshop on Dynamic Software Documentation),并在今年与ICSME 2018共同主办的第三届会议(https://dysdoc.github.io/dysdoc3/index.html) 上第一次举办了软件文档生成挑战赛(Software Documentation Generation Challenge,简称DocGen)。本次比赛要求针对开源的Apache POI项目(面向微软Office的Java API项目,http://poi.apache.org),动态生成针对每个类的API文档。POI项目有着广泛的应用,在StackOverflow等开发论坛上也有大量的讨论,但是其API文档非常不健全。

    复旦大学CodeWisdom团队参加了本次挑战赛,并获得了全体观众投票产生的唯一优胜奖。相关同学包括刘名威、刘阳、王翀、谢文凯、王拓、邢双双、白雪芳、张晓欣、汪昕、赵逸凡、张峰逸等。

    研究方法
    我们在前期积累的API知识图谱及相关的语义检索技术基础上,针对比赛要求开发了一个开源软件项目API文档生成系统OpenAPIDocGen。我们针对比赛指定的POI项目构建了一个API知识图谱,其中既包含基本的API元素定义结构也包含与通用概念的链接。在此基础上实现了针对StackOverflow上相关的讨论文本内容的分析识别,可以抽取与指定API相关的使用场景或问题解决相关的讨论内容。除此之外,我们也集成了注释信息抽取、样例代码抽取、基于规则和深度学习的注释生成等技术。最终实现的自动文档生成工具可以针对给定的POI类(给定完整类名)动态生成一个包含类描述、相关API和概念推荐、API知识图谱展示、API使用提示、API样例代码等丰富内容的API文档。

    目前,我们在CodeWisdom平台上部署了OpenAPIDocGen,在线访问地址为:http://bigcode.fudan.edu.cn/OpenAPIDocGen/。 在该系统中输入完整的POI项目类名(例如org.apache.poi.xslf.usermodel.XMLSlideShow)后即可动态生成文档。

    文档内容

    • API类基本信息 包括继承层次和功能解释

    0_1538324916972_eadd5c63-20f9-4f78-b724-12a64f70e4f2-image.png

    • 相关API及概念推荐 包括相关类与概念

    0_1538324952580_5f000267-2b34-4eb1-bf91-58daefacefc1-image.png

    • 概念图谱 与当前类相关的API元素及概念图谱
      可以设置不同类型实体和概念的显示并逐层点击展开。

    0_1538324967577_49e5fd3f-fc0a-43da-bcfa-ac66d1f4b4f1-image.png

    • 使用提示 当前类的使用说明
      通过从StackOverflow相关讨论中抽取相关的句子得到。

    0_1538324984304_3a5b3f8d-97d8-4594-8309-5830ad72a758-image.png

    • 相关讨论 当前API类的相关讨论
      通过从StackOverflow相关讨论中抽取相关的讨论得到。

    0_1538324996649_1369748c-8e63-447e-b671-9f6984403401-image.png

    • 类方法 当前API类的方法信息
      包括声明信息、方法描述及相关API元素和概念推荐。

    0_1538325013681_df7de519-af9f-4cfc-83e1-bc49e2c4d904-image.png

    • 类详细 息 API方法详细信息
      包括相关提示语句和讨论推荐等。

    0_1538325023905_daf77e0d-6a34-4adf-b2ed-06177a8cd4e1-image.png

    引用文献:
    [1] Martin P. Robillard, Andrian Marcus, Christoph Treude, Gabriele Bavota, Oscar Chaparro, Neil A. Ernst, Marco Aurélio Gerosa, Michael W. Godfrey, Michele Lanza, Mario Linares Vásquez, Gail C. Murphy, Laura Moreno, David C. Shepherd, Edmund Wong: On-demand Developer Documentation. ICSME 2017: 479-483

    posted in The Tower of Babel 共建巴别塔
  • SCC Community Would Embrace Loopring Protocol

    0_1532084929366_路印.png

    Big Decision! SCC community would embrace Loopring Protocol, and become a node in the Decentralized Token Exchange Ally.

    posted in English
  • SCC社区将要拥抱路印协议

    0_1532084929366_路印.png

    SCC社区决定拥抱路印协议,参与路印“去中心化交易联盟计划”,成为其生态中的节点!

    posted in 中文
  • 去中心化交易平台是区块链行业的下一个机会

    0_1532086121348_technology-3243375_1920.jpg

    2018年开始的时候,圈内人都在预测,今年会是区块链应用落地的大年。从截至到5月的全球投资数据来看,这几个月的投资金额,已经超过了去年全年,而某个渠道的统计数据,说现在的项目方已经有接近30万。无论从哪个角度来看,今年确实是一个应用落地的大年。

    但是,我们也应该认识到,行业的蓬勃发展,有赖底层基础建设的完善和成熟。但是目前从行业的状况来看,基础建设离完善成熟,还有非常遥远的距离。基础建设,不限以下的设施:主要公链,钱包,交易平台(包括中心化交易平台,去中心化交易平台),支付网关,实时兑换网关,跨链协议等等。区块链领域的基础实在是非常薄弱,而且我们也可以看到,随着交易平台的爆发式增长,各种乱象造成了非常恶劣的影响,实际上是对行业造成了严重的伤害。但是人性如此,没有监管的市场本来就是很血腥的黑暗森林,中心化的交易所需要一段时间的自我淘汰,行业也需要另外一种力量来对中心化交易所进行钳制,让交易所回归促进流动性的本源,而不是收割行业的镰刀。而在这个阶段有能力担当起这个重任的,去中心化交易平台是一个可能性非常大的选项。

    不托管用户资产,订单透明,手续费低并且是用来奖励提供交易节点,提供实时流动性,这些都是去中心化交易平台的协议。每一个钱包和社区天然都是去中心化协议的拥护者,只需要接入去中心化交易协议,摇身一变,就可以变成去中心化交易平台,为钱包用户或者社区成员提供优质的数字货币交易功能。只有到这个时候,中心化交易平台才会被制约,从而洗牌,最后剩下哪些为用户提供最优质的资产托管服务和交易服务的平台。中心化交易平台和去中心化交易平台形成某种平衡,共同为整个行业的发展提供最稳定最高效最便捷最便宜的流动性服务。只有这样,行业才有一个扎实稳定的基础,才能支撑起更多的token,才有机会让更多的垂直领域的应用落地。(参考下现在不到两千种token,8万多个中心化交易平台。其实数量反过来是比较理性的,比如十万数量级别甚至更多的token,几百家甚至更少主流中心化交易平台,百万级别甚至更多的去中心化交易节点)

    接下来的公链之争,有可能是在去中心化协议上爆发,几种主要的去中心化交易协议可能迎来最佳的发展时间,潜在的或者还没有公布的协议也可能蠢蠢欲动。战争还没有打响。谁的技术更好,谁能提前布局,建设起去中心化交易的生态,谁就有可能笑到最后,成为新一代的霸主。
    在众多的去中心化协议中,LRC(路印协议)非常有机会,但是生态建设是其弱项。但是生态是靠大家建设起来的,SCC社区决定拥抱路印协议,成为其生态中的一个节点,大家拭目以待。


    SCC团队

    posted in 中文博客
  • 编码=挖矿

    我们之前已经讨论过,源代码是开发者最有价值的劳动成果,是开发者终身的财富。然而在当前的分配制度下,我们对开发者的劳动成果的保护和尊重做的很不够,这导致了行业发展的种种问题。(前文:开发者如何通过源代码获得持续性收入

    为了改变这样的状况,经过多年积极探索,群策群力,我们在软件开发行业中引入区块链技术,期望通过区块链来建设一整套全新的激励和分配机制,解决行业发展问题。

    我们采用 开发者社区->源代码大数据->智能开发助手 多级火箭推进发展模式,发行的每一个码力(SCC Token)都代表代码的价值。SCC项目的价值包含了所有认同这个项目的开发者所编写的源代码的价值;如果全世界的开发者都认同项目,全世界的源代码的价值都将包含其中。每一个开发者就是一台矿机,工作时挖矿,不工作时离线(可以认为团队或公司就是矿池)。

    开发者主要通过编码来挖矿。挖矿最后能获得多少的矿(码力),需要通过自动计算-专家审核-社区公示的过程,最后写入区块链才能真正生效。比如最简单的为社区贡献一段源代码,按照规则,自动计算出应该获得200码力,然后社区专家审核这个贡献值,如果觉得不合理就做修改,如果合理就直接发布社区公示。公示时间一般为一周。如果期间没有反对意见,到期后将直接写入区块链,贡献者就获得相应的码力。如果有反对意见,社区将投入人力做审核。这个社区共识算法,我们称为 Proof of Equivalent Labor of Developer,开发者等效劳动证明(PoELD)。

    开发者也可以通过为社区建设投入时间和资源来挖矿。这是一种补充方案,其劳动价值的计算,会等效成编码的工作来计算。比如参与社区运营推广,为社区主题论坛提供技术文章等等。提供资源就是为社区提供硬件和软件,或者直接为社区提供经费,都是挖矿的一部分。

    SCC社区期望成为开发者自己的社区,而不是别人的社区,完全由开发者自主决定社区应该做什么不应该做什么。源码链和智能开发助手只是其中一个产品,社区的其他团队,都可以根据需要发起自己的项目。码力是社区价值交换的媒介,也是社区正常运作的基础。

    开发者是最有创造力的群体,也是数字社会背后的建设者。开发者通过SCC社区聚集在一起,交流想法分享知识,寻找志同道合的伙伴,一起合作完成项目,共享项目和社区发展带来的红利。

    posted in 中文博客

Looks like your connection to SCC was lost, please wait while we try to reconnect.