月度归档:2019年10月

【实践】使用在线研发中台进行HelloWorld项目开发

前言

使用研发中台,低代码开发好一个学生管理系统的CURD功能,整个过程预计【1个小时】左右 ,实现如下的效果:

学生管理系统效果(一下找不到合适的页面,暂时用这个替代,效果差不多)

研发中台是目前开始尝试做的第一个对外应用,期望就是在线配置非需求功能,调用现成的基础组件模块的服务,专注于需求和业务进行开发

研发中台提供了一些开发常用的能力,为开发提供相应的支持,减少研发成功:

1、开发支持:分布式配置中心、开发技术文档、开发规范、开发数据库、私服 等

2、基础组件:通知组件、日志组件、工作流组件、单点登陆、存储组件、打印组件、网关组件,为开发提供便利,前端控件代码

3、权限配置:菜单管理、角色管理、用户管理、部门管理、代码管理、参数管理、通知公告管理等。

这也是研发中台的第一个学习示例,其中开发使用的平台是alinesno研发中台:http://cloud.linesno.com

开发准备

开发准备,目标是生成代码,是包括【数据库建表 — 建立开发基线 — 生成代码】这几个操作过程。

数据库设计

数据的话,平台已经准备了一个在线版本的,为了图方便,使用的是公网的,在开发中使用还是可以用的。在平台找到开发的数据库入口,账号密码平台已经有注明,然后建立两张学生表,如下图:

数据库入口

建立了两张数据库表,如下图:

github注册

开发一般都有代码库进行版本管理,这里推荐使用github,因为是个人的,需要自己注册,假设你已经注册好,我们建立一个学生系统的基础,如下图:

建立学生库

生成代码

登陆平台门户,通过【创建项目】指引,填写相关配置(这里github基线要做成公开的,这个下一版本会调整问题,比如公司内部可能就不用考虑项目公开性的问题):

jenkins如果没有,则可以不用填写

点击【完成】,等待代码生成完成即可,这个时候,我们再查看一下git基线,已经看到我们生成的代码:

运行工程

运行工程主要流程按【工程导入 — 平台账号配置】过程,实现在线的配置。

导入工程

这里使用的开发工具是【idea】,导入基线即可,可以看到生成的代码结构,如下图:

过程要下载一些包,所以工程显示错误的,等包下载完成即可

然后运行springboot,访问地址:http://localhost:8080,应该出现如下界面:

会发现,需要一个登陆账号,这个账号,是通过研发中台配置的,看下一章节。

配置应用

登陆平台门户,研发中台是在线研发的,配置也是在线的,所谓的配置,就是一些常见的【菜单】、【角色】、【权限】、【用户】、【参数】、【通知公告】、【代码生成】等,如下图:

研发中台提供非需求性基础功能

在研发中台菜单项目先进行菜单配置,如下图:

菜单链接指向的是代码生成的list文件,即templates下的文件路径

再配置一个角色【学生管理员】,分配菜单权限给这个角色,如下图:

分配角色所拥有的资源

配置完角色之后,我们建立一个账号,同时分配【学生管理员】角色给他,这样他就跟菜单关联上,如下图:

添加账号和关联角色

有了账号之后,我们就可以登陆系统刚刚运行的系统,登陆之后,如下图:

显示菜单功能

发布k8s

整体按【Jenkins打包 — 发布k8s】这个过程,这里可以集成自己的Jenkins和k8s,平台目前的Jenkins和k8s不对外。

通过研发中台提供的【jenkins】进行发布,jenkins的配置和maven配置都已经整合,同时平台也集成好了k8s,为开发提供便利。

配置jenkins

此处由平台提供,但不对外,开发者可以使用自己的jenkins或者其它构建工具。

Jenkins配置是自动发布操作,同时为我们打成docker镜像,为发布k8s做准备。下面是jenkins的配置,Jenkinsfile已经在代码生成时自动生成:

通过平台jenkins入口进入,此处账号不对外(可自己安装jenkins配置)
配置的jenkins
构建过程和结果

访问应用

发布完成之后,访问地址,此处使用【NodePort】进行开发端口,只为演示方便。

开发支持

提供开发者过程中需要的一些技术资料和文档,可查可参考:

开发技术支持文档

最后

此处演示了整体研发中台的开发过程和企业集成流程,整体中台还在完成中,此处演示的只是一个示例和整体研发愿景,也希望有更多人参与我们中台的建设。

中台开源代码: http://gitee.com/landonniao

【实践】我参与的一个千万级软件项目平台架构设计与落地过程心得

基本背景

项目是在16年立项,前期主要进行需求调研,17年进入研究阶段,两广的城市信息化项目,整体项目的规模在3千万左右(不包含硬件,硬件是使用另一厂家云平台和阿里云),整体项目采用分布式,组件化开发,从设计到初步验收(只是初验)大概3年时间。整体项目包含有两个外包团队和两广团队,还有很多第三方的采购件,如工作流,APM等,相对来说,团队组织结构是比较复杂的,内部的组织结构还是部门型,即按开发组,测试组等,软件开发较为传统,还是老的单体结构,原项目架构非常老,还是Servlet、Strtus2、JDBC、EJB等,内部很多员工都有8年以上工龄,研发思维思维都以保守为主。

项目中我的角色是平台架构设计和平台组负责人,属于新血类型。整个记录过程,大多是以自己心得体会做过主线。整体过程按《前期 — 中上期 — 中下期 — 后期》几个过程进行描述,着重写这几个过程中出现的心得。

前期阶段

沟通是落实最实在也是最重要的一步

保守的研发观念,与新的平台架构观念融合过程

开始的时候,我这边是负责技术的吸取和学习,这个过程中,出现激烈讨论是相对比较多的,互相埋怨也是较多,互相沟通也是最多的。

打破传统,让团队接受并快速成长,接受平台的观念,是项目前期的比较重要的工作。 是于项目开始的时候,邀请了一个做过类似大型项目架构设计,有经验的架构师在公司搭建了一套平台,同时做了一段时间的内部培训,造成内部不少的讨论,平台可行性,是否可以这么做,事务怎么办,所谓的可靠消息,是否真的可靠等。引入分布式思维,统一研发平台思维。我这边的责任,便是与他学习,快速积累经验和了解平台结构。

很快,在为期1个月的熟悉之后,了解整体分布式结构(其实就是微服务架构),同时熟悉整体开发平台(其实就是PaaS平台),很快投入了前期试点项目,我这边协助开发平台的搭建和运维,保障前期项目的顺利进行。在这个过程中,也不断的邀请总公司的负责架构人员,或者技术负责人一起到广州进行讨论。方式也很简单粗暴,一帮人坐下来,针对设计的平台进行讨论,坐而论道。难免,一坐下来,就是意见不同,然后激烈的讨论(无可否认,讨论也是一项比较有技巧的技能)。

很快,试点项目就发现问题,工期有延期,无法达到平台预期的效果,整体开始针对试点项目进行讨论,两广一起讨论。平台组无法给开发组提升相应的开发支持(规范、规划、要求等),再加上前期对平台是否可落地的不明确,结论很显然,吵架又是再所难免,同时也预示着:平台落地出现了问题。整个会议几乎从开始到结束,都是针对平台的批评,技术的抨击,几乎让我无法抬头,甚至几乎无法面对开发,包括下一步的实施,甚至几乎到产生自我怀疑的态度。

平台初步落实的问题,这样的情况下,推广新平台,包括后期的内部实施,无非是又加一层难度 。几乎进行了为期一个多月的反思,找问题:为什么照着现成的平台,而且有成功实施经验的平台架构,在内部一实施就出现问题,问题点在哪里。之前平台架构整体规划及演示都很完善,为什么在内部实施一走就出问题。在不断的吸收前人平台设计经验的同时,也是不断的网上找各种资料(资料都说好,真的好么?),更是考虑内部实际的情况,光这几步,也差不多够折磨人,心态也开始有些浮躁,焦虑,不安等,更别说要休息,闭着眼就想着怎么落实的问题。

虽然过程中问题很多,待处理的问题也很多,但最终项目还是能落地下面,同时顺利上线。正是因为有了前面的各种讨论,意见的磨合,为下一步大项为了一个准备。

针对于跨团队,跨部门,跨地域,进行沟通过程

在后面的时候,由于各种各样的原因(可这么理解,家家有本经,即根据实际情况),内部做了一些组织调整,平台的设计和管理工作,转到我这里,从技术负责转变成平台管理,也就是平台组的负责人。

前面阶段的试点,讨论,还有各种或者说N多的技术问题积累之后,对平台做了重新规划,对之前的那套研发平台进行整体规划,然后服务器资源,还有管理方式都做了进一步调整,以符合实际场景。在进一步内部评审之后,新的平台架构通过大家的意见,这一步无非给自己增大了很大信心。并升级的平台架构,对前面试点过程中的问题处理,比如包括规范更好明显,沟通更加明确,还有组织结构也更加清晰等,在进行讨论确认新平台架构和方向之后,便是团队怎么消化和落实平台,怎么结合实际大项目,投入实施。

开始的项目组织结构就已经让我头疼不已,外包都有相对应的负责人,而且经验和资历都不浅,还有南宁这边的团队。内部除了开发以外,还有测试,运维这些部门,开始的第一步落实,怎么沟通,就让我已经倍有压力。

项目组按业务进行分组开发,平台为他们做好服务设计和组件设计 。不出所料,项目组一开始就有出现小组意见不合的情况,同时各个负责人都有自己的想法,各有各意见,负责人之前,很难说服对方。而平台组按目前的情况,还属于前期,是无法去统一的所有意见的,更别说去跟这些负责人碰,要么头破血流,要么自讨没趣。这样的情况,协调领导,把情况表明反馈领导,组织,开始进一步讨论, 又是一个个非常激烈的讨论,但最终的,还是统一意见下来。

在这样的情况下,平台组在各个负责人之间,作为基础服务,难免会有委屈,如受到一些非议,还有一些不认可。但总的来说,这个过程好,至少来说,都是往更好的方向发展。前期开始工程规划,到小组成员沟通,这几个过程还是比较顺利,沟通习惯和制度也慢慢的有形式。也正是因为前期,还没有过多的外部压力,同时也是内部的一种讨论,相对来说,还比较可接受。

平台与业务的碰撞,落实过程怎么走好第一步

怎么驱动开发接受新的技术,让他们成长,同时利于平台的进一步实施,这几乎是前期最难的。驱动一个人学习,让他学会思考,还在照着你的方向去思考,这几乎就是矛盾的开始点,但也是需要去做的点,而且是必须要做的点。

前期规划得最好的方式,也是要求的很严格的操作,就是文档。在每一个问题,还有每个操作过程都产生文档,让开发可查询,可操作。整体前期在研究过程中,便积累了大量的文档,这些开始培养,然后介绍,过程都很完善,并显示了怎么编写上传等,原以为准备那么充分,以为可以为开发提供更好的便利。

但是在真正落实的时候,才发现,文档与实际的项目过程问题有区别,而且很不完善(开始已经对文档了很严格的要求),文档可实施性真正结合到项目里的时候,各个N多的场景根本无法融合。更有一点致命的是,原习惯使用Office文档的,而规划的时候,操作使用线上文档,内部根本不习惯这样的操作。同时还有一个更好有意思的问题,文档太多,过程中不知道怎么查找符合自己的场景的,可能有很多关键字类似的,但是查询几次之后,发现与开发编码过程中实际想要不一样,等等这些问题。然后开发过程中发现,还不如百度出来的更快。

在文档规划及实施这块上,各种问题的出现,无非给平台组一个打击:给了一个好像很好,但是可用性不高的东西,多少有些鸡肋。还有类似的就是平台任务管理平台(类似于Jira),前期的时候,可能还能接受,但是后面实施也一样的鸡肋,根本不符合团队实际的习惯。开始尝试压着使用,但是这样的情况往往更槽糕,反弹的效果,很可能直接引起冲突,甚至相关负责人的否定,引起团队对平台的进一步怀疑。

不得不做内部反思,调整平台落地的方案,不得已,把平台规划再做一次调整,并做组内讨论(大的方向是正确的,只是调整部分),把一些“美好”的规划去掉,避免开发过程中的冲突,然后在遇到问题的时候,进行平台方向的引导,慢慢的过渡这个过程。要团队接受这个过程,非常长,近乎1年,很大一部分促进的功能,是开发过程及相关条件(比如压力,团队的文化的积累),而且有一些还是不能很好落地,比如原规划的自动化运维。

怎么让研发接受新的开发技术和管理过程

从开始到慢慢接受这个过程,几乎是一个一言难尽的过程。这几乎要改变的不是一个人的开发习惯,而是一群人的开发习惯,不仅仅如此,还要面对未知新技术带的各种未知问题,如接口开发前后的问题,开发版本管理的问题,还有各个各样环境(如网络)导致的各个异常引发等等。

当时有两个办公室,还有一个开发群,几乎有一段时间,都是两边都跑,然后一坐下来,可能群上或者就有各个QQ信息,包下载不了,怎么调用不了服务,这个异常那个异常等,还有包打错的,再加上maven一连串的依赖(这个证实前期设计的疏忽,是一个很小的细节引发),导致各种莫名其秒的问题,每天的工作就是沟通,处理,然后再沟通,再处理。当时很是担心,就怕这块异常引发开发的对平台组的信心减少,开发来上班,自己就比他们提前一点检查环境,开发加班,也跟着加班,如果开发走不下去,可能就是各种电话沟通,信息发过来是各个平台的问题,甚至的,有一段时间,通讯信息都不想打开,一听到电话,就猜到哪里哪里可能出问题了。这样的情况前期持续了差不多2个多月,几乎让我喘不过气。

后来才发现,前期这样的情况还好一些,中后期的时候,可能更为严重,异常处理都是半夜的,而且持续好长时间

经过这段时间的不断融合,可能产生各种问题,比如沟通,或者不理解,还有一些压力,甚至包括一些冲突等,但最终还是把这个过程落地下来。在持续了一段时间的 “问题” 热度之后,技术和整个新的研发流程,研发管理流程也已经慢慢理下来,后期遇到的,更多的就是业务性的问题,这个便是由业务组沟通处理,平台组做技术协助。

中上期阶段

做事过程,就必然有问题,不要指望完美

平台组成员压力太大,怎么克服

这个问题的出现,有必然,也有偶然。并不是说什么样的条件,也不是说什么样的环境,最终由实际的团队情况,环境,约束等方方面面来决定的。投入开发过程中,开发对平台组提了要求,需要完成的任务有没有达到的情况比较多,还有各个方面的经验还有实际情况,无法满足开发组,这个时候,便意味着,冲突的开始。

从上往下过程中就发现问题点,平台组并不是直接面向项目组,所以有一些隐藏性的问题,并不是一时的出现,这个过程可能会包含有遗忘、异常、侥幸、研发等,不过最终还是会暴露,这也不得不明确一点,遇到问题要及时提出,以避免进入深一层次的问题出现。而面对这样的情况,业务组在项目中期的时候,就全面暴发。异常多的问题冲向平台组,计划不断的被打断,一些原来基础简单的工作,几乎无法完成。常常一有问题就得马上响应和处理,而原计划的工作却又落下,不断重复和积累 ….

很快,以上的表现很快到人能力,小组能力的质疑,进行对平台能力的怀疑,是否能撑起业务组的开发过程。同时各种不满的意见,声音,反馈开始慢慢在项目组低下传播,业务组开始出现脱离平台组进而用自己解决技术处理问题的情况 …. 等等以上的异动开始出现。

明显,我在当局中,不得不思考和处理方案,这也是让我最头疼的方式。压力大与小的情况如何分配和调整,确实比较难办。在这样的情况和内部不满的情况下,还有对各种质疑不断,把一些业务针对比较锋利的压力转到我这里,然后小组进行工作考核和评估。原本考虑人心安定的问题,但是最后发现,不能满足的考核根本无法抵挡得住业务组的压力。沟通上的冲突与不理解很快就出现,这样更加激起业务组的情绪。

很显然,沟通能力和抗压能力的要求很快体现,而且体现得很明显

最后的表现是不管是上层和业务组,都慢慢有排斥平台的情绪,质疑和不合作,不接受的情况慢慢表现。这也是我最害怕的,最担心的,这样下去,可能的结果就是,平台组在项目组中的位置降低,同时更可怕的是,整个平台组可能为此而受莫大的打击,更别说其它的后期想落实什么什么方案或者意见。最无奈的办法,考虑左右,把研发出的组件效果体验最差的人员移出平台组,调入业务组,一方面是减压和挡住业务组的压力,另一方面是为平台组保留住核心人员,即表现能力比较好的,然后一步步的慢慢啃之前留下的各种技术债和业务债。但是之前的一些原本脱离平台管理,包括规范,要求等,只能在后期中慢慢的一点点的与业务组进行沟通和调整,只能在后期慢慢积累经验和找机会调整,有些可能无法调整的也只能默认(这步却为后期运维和后期各个工程上的不统一,研发意识和项目结束后的不统一埋下了隐患)

其中这个过程早就应该这么做,而且不应该犹豫,这是前期最优柔寡断的错误,同时也是自己实际管理能力不足的最直接体现

这样,在调整结构和人员的工作之后,平台组在协助业务组方面的效果有提升,认可度也很快有了改观,直到第一部分项目的上线。这个过程几乎经历了几乎慢慢转变了整体平台组的观念的改变和认可。

项目开始落地,内部抱团,相关工作安排沟通困难怎么办

第一个部分项目上线,落地部署的过程也是极困难的。平台基础环境搭建过程较为困难,迁移搭建的前一个星期,就几乎是每天到晚上2左右,然后早上8点半又得去验证。难并不是安装部署一些软件(如jenkins、redis之类)有多难,而是工程依赖,版本库,数据,第三方厂家的沟通等。工程就有近乎80个,而且开发过程中有可能发布新的代码,而之前工程发布有先后,还有一些工程(如基础组件)已经很长一段时间没有动,新的接口可能还没有做好验证(或者说没细考虑到)等等。

原自信满满的认为可能最多3天部署完成的,但是整整拖了近乎5天 ….. 这不得不让我心里崩溃,也明显体现出原平台架构的不合理,规划的失误。以前参考和培训的平台架构规模相对较小,整体完全不是一个级别的,这让我不得不为自己的背锅,所谓的坑,可能自己在挖着,而这些坑只能自己跳然后自己填。

项目上线,原考虑分人员运维已经上线的项目,做前期的过渡支持,然后我这边负责广州核心业务开发支持。这个安排,直接导致了平台组内部问题的出现,意见开始出现不统一,这也意味着,沟通上出现了问题。深入沟通过程发现,平台组原能力较好的人员保留,直接对接业务组(以前都是我直接对开发组,做第一步沟通),两边能力的差异,很快产生对业务组的不理解,比如注册中心,可能业务组开发人员也不怎么清楚原理(这其中也很正常,毕竟很多平台技术对业务组是透明的,他们可能都没有感觉到自己做的是分布式项目)

这样的问题出现,很快导致业务组的一些工作落实不顺利,不能满足要求,不久,很快就出现互相抱怨的情况,最常见的,你说他技术不行,他说你组件问题多。开始我并没有注意到这些,原认为是让接触一些也比较好,可以磨练,但是后来问题突出的时候,已经开始有些进入激化(比如互相抱怨)的程度,这个时候不得不介入首期项目的运维管理。

抱团就开始出现。开始自己也是比较难接受这个,毕竟小组内开始出现的,然后与其它业务组抱成内部小团体(确实开发太年轻,有可能出现稳定性不足的情况)。最开始的操作是内部办公室分隔,这步的效果不是特别好,可能是前期项目组工作压力,导致一些满情况有压抑,抱团成一个比较突出的反抗方式。考虑到矛盾的进一步激化风险,接下来就是沟通,即慢慢沟通,了解情况,然后就是安静,观察。公司明显也体会得出来这样的风险,进行了一些物质奖励,以安定人心。前期确实有一些效果,但是这样的抱团往往形成的隐患是有后遗的,一旦开始,各种消极的思维(比如逃避困难、互相指责)就可能变得固化,为后面的风暴期埋下了隐患。(比较建议的抱团应该是团队一起面对目前的困难,积极表达,针对问题进行沟通,解决困难,每个项目都有困难期,事事都顺利可能比较难)

组件近乎无法使用,开发崩溃怎么办

平台组经过了前面一段时间的躁动,这段时间大概为1个月左右,内部开始变得稳定一些。同时第一个项目运维支持的工作也差不多结束,在结束完第一阶段,很快就要面对第二阶段的挑战:有些基础组件在测试期间出了问题,而解决不顺利。

基础组件涉有几个是第三方的,在业务测试过程中,积累了几十个问题,一直在沟通调整中。有一些第三方公司本身就出现了问题,对接人员不断换,两年的时间里面,差不多换了4个开发。每调整一个版本大概是2~3周,还不包含测试。有些第三方组件,在实际的生产环境中(如接入银行,银行网络内部多了多层的NAT转换),一直出现异常,如客户端电脑不兼容,网络莫名的提示异常,还有各种硬件出现冲突等等。

以上的表现实际上在开发和内部测试阶段是比较不明显,但是实际到用户测试,安排的测试人员有近乎200人,用户在实际业务中,已经很娴熟,在测试过程一用就发现卡,要么就是这个接口不行,那个提示浏览器崩溃,这样对业务人员几乎无法忍受。开始业务人员第一施压对象便是业务组,业务组一汇总,压力进一步转移到平台组,然后平台组再转到第三方。第三方根据问题调整的周期长,每次验证都是正常的,平台组这边也验证,但是一上用户测试就是一大堆的问题,这样所有压力都开始针对于平台组,与第三方沟通也是存在各种不确定,可能人家忙,不接电话,问题延期,第三方发布的版本不稳定等等,这些沟通过程,都差不多消耗了2个月,效果还是不怎么理解。每次开会,都是提到这几个问题,平台的开发人员几乎很无语,也很无奈。过程大概都是,每个阶段都说自己的是正常的,第三方说调整版本没问题,是业务集成的问题,业务组说集成是平台组问题,平台组说第三方集成的问题,两头夹,或者谁都说谁有理等情况,接下来再走一次内部查找,排查,沟通等等。

这样不是办法,效率太慢,我也实在是无法忍受,一个问题可能拖很长时间。后面,调整策略,与商务和用户沟通,直接要求第三方人员现场驻场一到两周,集中把问题处理,由业务人员直接对接第三方,项目例会涉及到第三方,第三方各种问题先处理完,再回去。

这些组件的问题,从用户测试到有比较稳定的第一稿,差不多经过了半年的时间,用户才稍稍接受,这个过程也几乎把平台组折磨得差不多。

中下期阶段

不上不下的,要的不仅仅是会做事,也要学会做人

前期架构某点技术问题,实际线上场景无法使用,怎么面对客户和内部双重压力

开发和测试都经多很多次验证,在用户测试和试运行阶段还是出现了很多猜想不到的问题。

最明显的,网络层面的开通和阻力远远超过原预期的设计和考虑,原中间件的选型也是不能完全满足要求,还有分布式事务的设计与实际场景差异等等。那么多人前期在讨论着,看着方案,也有很多的验证过程,而且别人也是这么用的,为什么别人就可以正常,我们一用的时候,就出现异常。之前甚至找了原厂的人(比如Weblogic),也一样说是某些技术场景也没见过。这个几乎是一把虚汗,因为在开发,测试中都验证过的,可能来说,都已经正常的,到实际试运行就不行,这让内部测试、用户测试人员很难接受。

能用得起来的人都说正常,你能确定你用起来就一定正常的么?

首先发现的是网络,最典型的,也就是上面说的第三方组件也一样出现类似的问题。接入各个使用机构(如银行、管理部)的时候,他们自己本身内部就有一套网络结构,在使用过程就发现,有些第三方路径回调不回来,网络出去了,找不回原来的地址,系统一进入就是空白,这无话可说,加班调整和修改。

再有的就是事务这块,交易过程也一样发现各种各样的重复交易,记账数据不正确,或者说消息发送找不到记录等等。这也无话可说,直接加班调整。比较无奈的一点是,原找使用说是在生产做正常业务的人过来处理,他们也只是看了一下,大多也是回复“不清楚”,“没遇到过这样的情况”,那只能自己内部开会调整找方案。

这个过程加班,熬夜也是最深的,因为技术架构的问题,有可能直接导致整个业务和项目跑不起来,或者无法应用实际的生活环境场景。这个时候你没办法,只能临时调整,大调整也得调整,小调整也得调整,实际环境就是如此。有的时候,还需要跑去实际现场查看问题,最典型,就是银行小妹窗口那里查看,看着人家办业务,然后有问题,及时处理。或者在用户电脑上调整,跑去那个银行网点,这个银行网点,Debug调试,实际验证等等。因为一旦试运行上线,业务一般就不能停太久,这个不管是在各个方面来说都是一个挑战。

这个过程差不多有2个月的时间,前一个月调整,后一个月运行验证,整个也差不多到17年低,也差不多告一段落。这个阶段都是直接技术处理,但是更多的是平台的压力,几乎也差不多折腾人,所幸的是,只是技术上问题,沟通及矛盾上不会那么多。

用户测试出来的问题几千个Bug,平台组怎么更好支持业务组

项目往往是越到后期,压力就会越大,加班也是越多,接触过几个公司,项目开发貌似不管大小,都存在类似的现象。而面对大型项目,多项目组,多部门的情况,这个方面就更加突出。

项目至少我是这边接触的,从一开始就一直在大量的加班情况,也近乎两年,再加上各种压力,确实一开始适应起来并不是那么顺利。前面也提到,每个阶段都有问题,而且是异常多的问题。几乎每次开会,都是拿问题进行投影讨论,定位到人,平台组的问题,几乎就没有断过。

分布式项目,都存在关联,A组会提到是B组的原因导致,B组会提到C组的原因导致,最终又转到平台组,组件不完善,技术支持不到位,环境各种异常等等。这个过程是比较折腾人的,前面抱团的原因让我也是让我更担心人心的问题,有些工作安排已经开始不到位的情况。

用户测试阶段几乎是一个灾难(并不是说不好),测试规模也比较大,安排了两个大间,类似于两个教室一样,安排的测试人员大概也近乎200人。用户的这个安排,也着实让我们出了一把汗,结果是果不其然,这把汗真的是流了不少。

几个业务系统一投入用户测试,就积累了大量的问题,差不多有4千多个,而且每天还不断有新的问题产生。加班、熬夜、外卖几乎是常态了,周末的时候,也许再安排点水果。这个时候,体重也慢慢提升,头发也在掉,也是比较意外的(所以程序员需要注意好身体是关键)。

问题修改,不断往上,改了近乎2个多月,几乎把人搞得人困马乏,再加上各种情绪的产生,人很容易,也很快就产生了消极情况,这种情况在项目组内部开始产生苗头。工作的消极情况,意味着上层就很难再给开发组压力,几乎只能找组长沟通,交流,这个过程人心和业务已经慢慢变消极,离职,招聘也就这个时间段也在同时进行,这也是我压力,情绪比较消极的阶段,甚至有一些提项目无法上线的说法,整个项目组信心不是特别大,抱怨也成了常事,这个过程更多的是志气上的提升,需要更多的互相沟通,依赖等。很显然,这个过程我并没有做好,也是自己需要认知的地方,平台核心成员也开始提离职,那个时候我压力最大的时候,特别是团队成员的离开,虽然有预知,但是那个时候的离去,确实一开始有些难接受。不过这也意味着自己的成熟,平台的成熟。

业务组在前期测试,对平台组的压力,几乎把平台组主要的问题都已经消化得差不多,不能说很好,但是不影响业务的进行(这不得不说,前期的问题暴露和施压了正确的),所以业务组在消化系统Bug的同时,平台组当中担当的角色几乎都是技术支持,加速问题排查和调整。同时也慢慢的支持开发过程的问题,这个过程是很容易积累平台威信的,同时也很容易获取到业务组的信任。在前期的积累和各种经验上,其实很快解决技术问题,同时认可度也慢慢提高,这也意味着,平台组开始变得稳定,也开始变得成熟。

在处理研发问题的时候,就开始慢慢把前期的坑补上,比如一些规范,一些工具的使用,一些技术的统一等。这样的过程差不多变得统一,如在消息的使用上,在业务上的整合极度容易出现重复消费的情况,前期讨论的时候,平台的意见有被排斥情况,这样业务组自己整合的前期貌似情况比较理想,但是业务组用完即走即不管理后期的维护,维护方是平台,这也是前期说的遗留问题),也开始按平台的规范,要求来编写,这样的排查的时候,就更加容易,也提高了排查效率,认可度也慢慢提升。

这个过程也是持续了很久,直到上线试运行到较稳定,大概有1年多的时间,都还是持续,只是紧与慢的区别。但是坚持到这个过程,已经留下人员不多,原平台组一开始的核心人员已经都走完了,没有坚持到最后,也是在中下期的时候。

后期阶段

这只是一个过程

后续的问题怎么调整和总结

平台前期架构设计和管理,当与实际整合中出现的问题,怎么样可以更好的落地。这个过程不断的在总结,同时在架构上做了进一步的调整,技术调研,还有自我工作反思总结。及时进行一些工作内容的合理梳理安排,以达到跟实际场景,实际团队更好的切合。

平台经过了差不多3年时间的磨练,出来的东西并不是相当的完善,反而让我发现,需要调整和需要走的路还很远,并不是说技术,而是怎么样更好的为业务服务,更好的在多种场景下进行落地。技术只是说一种手段,但是这个手段又不能没有,但是使用过度使用,怎么样能适中,两者怎么权衡,这些都是平台需要考虑的。

在大项目场景下是这样,但是在迁移到小项目场景下,是否可以实行得通,可能完全不是一回事。在项目过程中可以使用,但是项目结束后是否也符合后期团队的实际情况,也不敢一定。这个时候,需要的不是断的升级,不断的听取业务组,项目组的意见,切合实际的去协助他们的工作,帮助他们的工作,这才使得平台的意义有提升,更好的在实际中落地。不断的进行某个节点的改造,更好的结合内部场景来实现这个过程。

最后

整个过程下来差不多3年,直到现在,自己也是撤场不久(原在客户现场开发),整个过程有些唏嘘。回头看,整个过程真的到处碰,说得头破血流,有点悲壮也不为过,路要自己走,要自己体会。这相对于团队来说,几乎相当于一次改革,从上到下的新的思维引进,有非常非常多的阻力,也有非常非常多的困难,也会有人离开,也会有人失望,但是整个下来发现,需要的更多是学会团队的合作,更多的是学会引导,宽容,同时也更多的学会成长,个人整体素质的提高,人格的提高等,同时也感谢自己前期的不放弃。

整体感悟。

Using Nexus 3 as Your Repository – Part 3: Docker Images

This is the third and last part of a series of posts on Nexus 3 and how to use it as repository for several technologies. (Part 1Part 2.)

Stop-OutdatedContent

Installation

Check out the first part of this series to see how we installed and ran Nexus 3 using a single docker command. Just do that and the installation is done.

Configuring Nexus as a Docker repo

What we will do:
– create a private (hosted) repository for our own images
– create a proxy repository pointing to Docker Hub
– create a group repository to provide all the above repos under a single URL

I suggest you to create a new blob store for each new repo you want to create. That way, the data for every repo will be in a different folder in /nexus-data (inside the Docker container). But this is not mandatory for it to work.

By default, the Docker client communicates with the repo using HTTPS. In my use case I had to configure it with HTTP, because we didn’t have the certificate nor the knowledge on how to obtain it.

Important to notice: the Docker repo requires 2 different ports. We are going to use 8082 for pull from the proxy repo and 8083 for pull and push to the private repo.

I had some problems with slightly older versions of Docker, so I strongly suggesting you to start with the version that I’ve tested with, that is 1.12.3.

private repo

A repository for Docker images that your team creates.

Create a new Docker (hosted) repository and configure it like:

rafael-1

proxy repo
A repository that proxies everything you download from the official registry, Docker Hub. Next time you download the same dependency, it will be cached in your Nexus.

Create a new Docker (proxy) repository and configure it like:

rafael-2
rafael-3


group repo
This will group all the above repos and provide you a single URL to configure your clients to download from to.

Create a new Docker (group) repository and configure it like:

rafael-4
rafael6

You can create as many repos as you need and group them all in the group repo.

This step is actually optional to use Nexus 3 as a Docker repository, because we can stick to pulling and pushing to the proxy and hosted repositories as will be discussed later.

Configuring your clients and projects to use your Nexus repos
To interact with your repo, the first thing is to configure the Docker daemon in your machine to accept working with HTTP instead of HTTPS.

How exactly to do this config depends on your operating system, so you should check dockerd documentation. On RHEL I did it putting this content in /etc/docker/daemon.json:

{
  "insecure-registries": [
    "your-repo:8082",
    "your-repo:8083"
  ],
  "disable-legacy-registry": true
}

You have to restart the daemon after setting this (sudo systemctl restart docker).

On Windows or Mac you should config your deamon in a box like this:

rafael-5

Now we have to authenticate your machine to the repo with:

docker login -u admin -p admin123 your-repo:8082
docker login -u admin -p admin123 your-repo:8083

This will create an entry in ~/.docker/config.json:

{
	"auths": {
		"your-repo:8082": {
			"auth": "YWRtaW46YWRtaW4xMjM="
		},
		"your-repo:8083": {
			"auth": "YWRtaW46YWRtaW4xMjM="
		}
}

To pull images from your repo, use (notice port 8082 being used):

docker pull your-repo:8082/httpd:2.4-alpine

To push your own images to your repo, you have to tag the image with a tag that points to the repo. This is strange to me, since I was trying to think about Docker tags the same way I do about Git tags, but they seem be somewhat different (notice port 8083 being used):

docker tag your-own-image:1 your-repo:8083/your-own-image:1
docker push your-repo:8083/your-own-image:1

To pull your own images from the repo, you can use:

docker tag your-own-image:1 your-repo:8082/your-own-image:1
# or
docker tag your-own-image:1 your-repo:8083/your-own-image:1

Both ports will work. I suspect that is because using port 8083 will connect directly to the hosted repo, whilst using port 8082 will connect to the group repo, which contains the hosted repo. I suggest you to stick to port 8083 to avoid duplicate images in your machines. If you chose to stick with port 8083 to pull your own images, you probably could skip creating the group repo, if you prefer.

Git 分支开发规范

Git 是目前最流行的源代码管理工具。 为规范开发,保持代码提交记录以及 git 分支结构清晰,方便后续维护,现规范 git 的相关操作。

image

分支管理

分支命名

master 分支

  • master 为主分支,也是用于部署生产环境的分支,确保master分支稳定性
  • master 分支一般由develop以及hotfix分支合并,任何时间都不能直接修改代码

develop 分支

  • develop 为开发分支,始终保持最新完成以及bug修复后的代码
  • 一般开发的新功能时,feature分支都是基于develop分支下创建的

feature 分支

  • 开发新功能时,以develop为基础创建feature分支
  • 分支命名: feature/ 开头的为特性分支, 命名规则: feature/user_module、 feature/cart_module

release分支

  • release 为预上线分支,发布提测阶段,会release分支代码为基准提测
当有一组feature开发完成,首先会合并到develop分支,进入提测时,会创建release分支。
如果测试过程中若存在bug需要修复,则直接由开发者在release分支修复并提交。
当测试完成之后,合并release分支到master和develop分支,此时master为最新代码,用作上线。
复制代码

hotfix 分支

  • 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似
  • 线上出现紧急问题时,需要及时修复,以master分支为基线,创建hotfix分支,修复完成后,需要合并到master分支和develop分支

常见任务

增加新功能

(dev)$: git checkout -b feature/xxx            # 从dev建立特性分支
(feature/xxx)$: blabla                         # 开发
(feature/xxx)$: git add xxx
(feature/xxx)$: git commit -m 'commit comment'
(dev)$: git merge feature/xxx --no-ff          # 把特性分支合并到dev
复制代码

修复紧急bug

(master)$: git checkout -b hotfix/xxx         # 从master建立hotfix分支
(hotfix/xxx)$: blabla                         # 开发
(hotfix/xxx)$: git add xxx
(hotfix/xxx)$: git commit -m 'commit comment'
(master)$: git merge hotfix/xxx --no-ff       # 把hotfix分支合并到master,并上线到生产环境
(dev)$: git merge hotfix/xxx --no-ff          # 把hotfix分支合并到dev,同步代码
复制代码

测试环境代码

(release)$: git merge dev --no-ff             # 把dev分支合并到release,然后在测试环境拉取并测试
复制代码

生产环境上线

(master)$: git merge release --no-ff          # 把release测试好的代码合并到master,运维人员操作
(master)$: git tag -a v0.1 -m '部署包版本名'  #给版本命名,打Tag
复制代码
image

日志规范

在一个团队协作的项目中,开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘,最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们,它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的:

  • 加快review的流程
  • 帮助我们编写良好的版本发布日志
  • 让之后的维护者了解代码里出现特定变化和feature被添加的原因

目前,社区有多种 Commit message 的写法规范。来自Angular 规范是目前使用最广的写法,比较合理和系统化。如下图:

image

Commit messages的基本语法

当前业界应用的比较广泛的是 Angular Git Commit Guidelines

具体格式为:

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
复制代码
  • type: 本次 commit 的类型,诸如 bugfix docs style 等
  • scope: 本次 commit 波及的范围
  • subject: 简明扼要的阐述下本次 commit 的主旨,在原文中特意强调了几点 1. 使用祈使句,是不是很熟悉又陌生的一个词,来传送门在此 祈使句 2. 首字母不要大写 3. 结尾无需添加标点
  • body: 同样使用祈使句,在主体内容中我们需要把本次 commit 详细的描述一下,比如此次变更的动机,如需换行,则使用 |
  • footer: 描述下与之关联的 issue 或 break change,详见案例

Type的类别说明:

  • feat: 添加新特性
  • fix: 修复bug
  • docs: 仅仅修改了文档
  • style: 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑
  • refactor: 代码重构,没有加新功能或者修复bug
  • perf: 增加代码进行性能测试
  • test: 增加测试用例
  • chore: 改变构建流程、或者增加依赖库、工具等

Commit messages格式要求

# 标题行:50个字符以内,描述主要变更内容
#
# 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险? 
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档
复制代码

参考链接

【需求】我是怎么带几个学生从零开始做一个研发中台的

接触中台的概念是在18年,互联网还在流行DevOps,微服务,资料异常多,但是却又是异常的敷衍,几乎没有一套完整的可落地的开源框架,大多就是一个权限系统、一套微服务脚手架,或者说一套似乎有完善落地的Docker或者K8s,但是能不能真正落地起来,到底怎么落地,不清楚,也不知道,符合不符合场景,查找到的资料都是说好,但是能不能落地,心里很是没底。

考虑左右,从零搭建了一套开源的研发中台,带着几个大学生,利用业余时间,用了大概1年多的时间,从过程的团队建设,试点尝试,过程分工,到形成一套中台项目管理流程,整个最终可以勉强实现下来,也是感慨万千,唏嘘不已。

整个研发中台架构 (http://cloud.linesno.com)

为什么要做这样的中台,还要从零开始

1、需要知识积累和沉淀,不断的反思,不断的吸收,不断成长

有一定工作的经验的开发肯定知道,企业开发中包含有大量的、重复的CURD(增删查改),以及重复性组件,还有不断的获取和重复使用的学习资料等等,这些重复性的东西,每次使用都有新的感悟和感受,如果没有积累,每次都可能从零开始,无法达到沉淀和积累,从而浪费大量的时间和精力在上面,如温水煮青蛙,久而不知,而自茧作缚。

而相对的另一个例子,滴水穿石,之所以可以穿石,就是因为不断在前面的积累基础上,加上不断的坚持,如果每次从零开始滴,也许也可以穿石,但是消耗的成本和时间,也是很巨大的。学习也是如此,加上不断的积累,在一项技能上不断的学习积累,日积月累,不管有没有达到”穿石“,但是一定有会不小的进步。

2、不想把时间浪费在无用的点上,更想专注,不用站在巨人的肩膀,自己就有肩膀

有一种慢慢的体会和感悟,叫“ 欲速则不达 ”, 每个事情都有消耗时间、精力、过程,而人本身就是一个有限的特种,怎么样可以在有限的时间里面,更好的完成和学习,需要的不是其它,而是【专注】。所谓的专注并不是要时时刻刻的去想,去学习,而是坚持长久的做这个事情。

类似的如常见的1万小时成专家说法。 中台搭建的目的之一,就是节省用时间,去掉重复无用的东西,在有限的时间里面,更好的专注在新的点上,不断的前进,不断的提升自我。

3、落地不是一个人的事情,是整个团队的事情,要学会带团队一起成长

一套中台,需要涵盖的内容很全面,每个模块,领域都需要有对应的人员,这个时候,不是一个人能完成,而是需要调用团队的力量去实现。 就像打球,即使说有一个人球技出神入化,但是他一样也需要传球的人,助攻的人。想要落地这个平台,就需要有团队参与,发挥团队优势,提升整个团队气氛,团队合作,合理分工等,这些都需要学习和实践。

最后获利的不是某一个人,也不是具体谁谁,而是团队的每一个成员,在这个过程中能发挥、创造、体现出他们自己的价值,团队成员的见识、协作、信心等的成长。不管这个过程是艰辛也好,埋怨也罢,你走你才知道,而不是听谁说你才知道,这就是你自己的经验,自己的价值。

带人的过程是要学会发挥自己的能力的同时,更要学会带团队一起成长。

4、需要一套完善的研发中台打磨,站在前面的基础上提升

在出来一套可见东西之后,可能比想像的还要“千疮百孔”,还要不堪,甚至连往回看的勇气都没有。但是正是这样的东西,摆出来,拿出来,虚心接受所有的问题和建议,然后在后期一步步消化,一步步打磨,而形成出来的,就是自己的产品,或者说,把自己打磨成一套精品。

技术总会在不断的发展,需要有一个产品,一个中台可以让你,或者我在更好的中台上面做预研,而出来的成果,也会比从零起个“Hello World”强得多,毕竟你已经在场景里面,已经在平台里面,安全,测试,规范,可用性,健壮性等等都有中台的验证和支撑。

开发接入研发中台的HelloWorld说明

没有实战基础的学生,是否能组成团队

1、为什么要选择学生团队,不找有工作经验或者社会经验的人

找学生,这也是B方案,前面的A方案,最初规划,团队组件的是找的是同学和有工作经验,还找了以前老师作为指导,沟通好,拉了10几个人成团,便开始。但是这个过程经过不到2个月就发现问题,异地沟通困难,团队鸡血也很快消磨,有转成观望态度,原因不免是 工作忙,时间精力不足,整体的技术预研也几乎停滞不前,原计划的分工,很快无法往下,研发任务开始体现出敷衍趋势,成立的微信群很快形成死群。开始信息发出的时候,还有几个人附和,到后面,可能连附和都没有。

很快,就有提出要退出研发计划,同时各种小群也开始建立,这些都意味着团队有危机的趋势,不管是信任和人心开始出现浮动,放置观察了1个多月,考虑同学,朋友,还有后面的各个因素,无奈放弃此方案,成员停止研发沟通联系,慢慢的转向分享文章,咨询经验等方式,进而消停。

由于之前在校时有一定的学生接触、组织经验,B方案实施也是很快落地,不到2个星期的时间,也成立了10几个人的群。学生没有实战经验,不管是沟通还有动手,都与实际工作人员有天跟地的区别,而能不能落地,却成为一个最担心的事情。不仅仅如此,学生成团的现象,抱团等情况,过于依赖于师生级别关系(比如较愿意听老师的话),这些都是问题,不过既然A方案放弃,就得全力保障B方案的实施,而且这步的操作过程,更需要严格,可控。

2、怎么进行团队的培养、磨合,最终成为可作战的兵团

学生团队开始份两个组别进行,互相互相隔离的分开,原考虑是分开培养,然后两边达到可控,可对比,以小组作为培养线。一开始活跃气氛远高过之前的团队,也是理解,毕竟学生很有学习的积极欲望。开始的时候,流程按 【培训_学习_考试_分级_练习_评审_重构】 这几个流程,按这几个流程下来,这个过程很快,几乎一个月内就可以完成。

当时整理的等级技能图

过于顺利的流程让我感觉,应该问题不大了,而且很快就可以进入提升学习阶段。考虑左右,虽然考虑可能有难度,由于之前的表现,还是比较有信心,毕竟流程,团队制度有建立雏形。决定开始接入新项目,进行实战练兵。

很显然,我的判断是错的,而且过于过早的接入实战,实战性的要求,沟通,压力等,让组长无法承受压力,而且之前做了一个最大的失误,考虑组长退了,副组长可以顶上,也就是常见的AB岗形式,结果却是组长退了,下面的学生人心异动,而且又是核心成员,很快引起其它成员信任危机,深度做安抚工作,而且减少对应的任务安排,但是最终还是造成内部沟通的不利,需要在任务上进行妥协,而这样的妥协却极度不利的中台的研发和后期的任务安排。这个近乎两个月的组团培养,组团受挫,这不得不让我思考之前的一些策略与方式。

明显,资源开始主要集中在第二组,这个时候,已经开始感觉到,组团的风险和管理上的缺失,不过幸运的是,前面两组留下了很多资料和资源,留下的这组人与上一组留下的成员,从素质上确实也比较高,很快完成了新的组团,而且意识较为统一,在沟通明显都成一气。

也发现,找人组团,不管是人员素质,意志力还有自控力等都有一定的要求,是否看个人有成长的追求等,能克服困难,能坚持。在进行多次任务安排和沟通之后,最终确定留下人员也就只有几个学生。 由原来的差不多30人, 差不多半年的时间里面,经历两轮的练兵和实战,后面一年的时间里面,也有进进出出的,但是最终来说,还是这几个人为核心。

3、怎么消掉学生气,形成接近社会的工作状态

学生团队与实战要是能对接得上,最大的问题是怎么样调整状态,即执行力,沟通能力,协助能力等,合理安排好自己的学习和工作时间,不影响学习,然后又能参与到项目建设中来,学会怎么样安排,怎么样协助,遇到困难的时候怎么面对,使达到任务目标。

而想到的,最好的练习方式,也是要接一个实战,所以,校内跑腿项目就建立了。

校园跑腿项目后台(测试界面)

校内跑腿是考虑到的一个比较接近于实际,涉及到各个方面的能力的项目。从开始的开始的项目立项,然后到团队执行,再到人员计划安排都走过一次,比如计划方案怎么写,中间沟通问题怎么考虑,遇到一些问题,怎么处理。如与社团合作的时候,达不到效果,然后就找会长一起沟通,然后面对问题,而不是说,逃避问题。开始常常是一个问题一遇到就想着可能会失败,“哎,可能就这样了”,这个时候就引导找到问题点,解决问题点。也有说以为安排就需要马上完成的,就告诉他们要有计划,然后哪天完成哪些,一步步执行,不要急于这一天等。

他们有思路,听取他们的意见,尊重他们的意见,有一些想法就多鼓励去做,在执行过程中,也配合他们一起处理,让他们有意识的知道,原来这个是错的,毕竟新人,带有一些学生气,有冲劲。如果执行过程有困难,就多鼓励,如果有错误,就引导并适当批评,有成果,就奖励等。

在两个多月的时间里面,跑腿人员大概有70多人,公众号关注人1000多人,然后订单2000多单,整理了从申请,接单,跑腿,扩展等流程。团队也开始慢慢会了讨论,沟通,使用一些常用的工具,体会互相理解,互相宽容,执行力和作事思维也慢慢了有了提升,了解到生产中实际项目,包括工程代码的研发过程过程,比如怎么对接微信,登陆,支付等(跑腿项目是自研的),至少达到这一步,也是多少有些欣慰的。

关于公众号,原本可以让他自运营的,毕竟流程制度都在,对跑腿人员也有利益,却因为公司的问题,暂时停止了项目,也是较为可惜。

平台研发过程中怎么安排学生团队,学生团队可以做什么

1、过程成员缺少很多东西,怎么安排任务

最主要的是怎么安排研发任务,然后又不能一下给太多任务,还要有一定的成就感,这个倒是为难到我。整体的研发平台涉及到的面太多,从文档,服务器,运行,执行集成,项目代码等都有一整套,这些都要落地,让他们实现任务的同时,能有自己的成果。

前面的整体架构,包括规划这层,在前面团队组建的时候,我这就把整个蓝图做了规划(组团的时间远超过之前的估计,原计划是3个月,最后想不到用了大半年),这也是特别麻烦的一点,无法让他们有参与感,考虑左右,就只能从最简单的开始。

规划的第一版本整体研发中台架构

开始从jenkins 的使用,然后到Git导入批量工程,怎么团队协助,合并代码,怎么帮别人运行中台,从最简单的操作开始,然后怎么本地部署,比如Zookeeper,redis使用场景,工程怎么打包,服务器怎么查看异常,怎么查看日志等,都从最简单的做起,一点点的完成带入感,慢慢体会到平台的过度。在有些了解之后,开始学会使用代码生成器,生成服务工程 ,生成一些组件,生成CURD,做一个学生管理系统。比如日志组件,通知组件,这些都可以让他们使用代码生成器一步完成初版,后期的我再在上面进行优化处理。

规划的第一版本整体学习计划

目标就是让有了解之后,有自己的想法,可以实现自己的想法,从而提升自己,增加自己的知识面,这也是引发出其它的问题,就是知识深入的问题。毕竟面的代价就是深度,而这个,当前做的最好的办法就是,鼓励认真学习大学老师的课程并说明重要性(我们大学都是以学习基础为主),然后计划的时间拉长,比如完成一个Git工程导入的任务可能要1周。

2、消极,缺乏自信,缺乏学习主动性,怎么办

平台研发过程中,最为难的事情就是接触新的事务,常常接触到的回应是 ”我不知道“ ,”我没接触过“ 等,或者说,一接触到新的东西,就莫名的害怕,还有一种比较常见的情况就是,任务往往都是最后一天才有去执行,其实这个问题倒不大,但是却有各种理由来表达 如 “学习任务太多” 或者说 “正在看” 。开始就发现问题,然后就往下问,却不是这么回事。主要还是缺少学习的主动性,然后在追问的时候,又知道这样不对,内心存在愧疚,然后又有点畏惧罢了,这也许是学生团队的可爱之处。

这种情况还是比较常见的,无可否认,即使在实际工作中,这种也是屡见不鲜的。没有接触过就先让他们百度,网上参考,找解决方案,多问人,不要怕问,也不要害怕说问多别人会生气,更不要怕百度拿别人的代码(这是与应试教育不同的地方之一了)。软件以实现功能为主,也鼓励创新,但是更多的是,解决问题为主,做事要有始有终,有成果。针对于另一种情况,却是批评为主,或者说有时候激动,就真要多说几句。并不是不允许最后一天执行,但是最主要的是不能敷衍,对就是对,错就是错,要敢于面对问题,敢于表达自己的问题,也不要怕被别人看见,怕被别人知道,学会面对,然这样才有发现问题,解决问题,避免自欺欺人。

过程以慢慢的培养主动性,自主学习能力,自我提升为主,同时,也要树立正确的三观,工作观,培养的做事的魄力。

3、团队过程最为合理的,感觉还是激起人善意和潜力

其实这个过程中,最害怕也是最难做的,就是怎么带团队的问题,结果不是怕不出成果,而是误导。带的过程,并不是说不敢给压力,更不是说不敢给努力,而是在有限的能力里面,让他们最大的发挥自己,然后创造他们自己的价值,发挥他们自己的价值。其实这个并不是自己的觉悟,而是在自己莫大的团队管理困扰之后,在读到一篇微信文件,介绍“彼得 德鲁克”的时候,一个自己的真实体会。

现实中,不仅仅是这几个学生,在公司内部也一样涉及到一些管理性的工作,带队工作,这个比起学生团队,更加残酷得多,也现实得多。团队成员并不是我们的上下级,而是大家的一种互助,一种共赢。自己在培养别人的同时,别人也在培养你,提高自己更高的标准,锤炼自己的人格,同时超过我们自己的局限,做出自己可能自己都没有想到的事情。提升他们,帮助他们,感恩他们,同时他们会感恩你,跟随你,展现自己的人格魅力,而其它的管理工具,还有书籍,更多的感觉是一种辅助。

带团队过程中,本身也要学会反省,检讨自己,必须要清楚自己在做什么。反之,正如一部电视剧里面说的,孝庄对康熙说的:“鳌拜可能不是自己要反的,而是你把它逼反的”(大意如此,原话不记得了)。而相反的,激起他内心的善意,学会感恩,这样,也许会更好的让他发展自己,即使不在这个团队,在另一个团队,公司也能有这样的心态,久而久之,也肯定会赢得别人的认可 ,创建自己应该有成就。

我们要做成怎么样的目标

1、要形成大平台作为后盾,小兵团进行作战的战略

平台建设从开始的团队组建、培养、到一起作战,项目从开始的架构设计,技术选型,第一行代码,到第一个访问链接,都包含着一层层的努力和坚持。这个过程大概过了1年多,从计划到出来第一版本,基本上能达到“大平台,小兵团“作战的目标。

中台的形象示例

当然,目前的版本还是千疮百孔,有些地方甚至可能不堪,或者不完善,这些都是开始,一个初型。需要不断的实践,团队不断的去上面去锤炼它,让他成长,然后添加自己的想法,表达自己,它就像一个土壤,为下一步的完善的过程提升了基础。

为团队的下一步,后来,甚至未来的蓝图规划, 带来了一种可能,而不再是纸面上理论,更不再是网上这里缺少一块,那里缺少一块,不可落地的东西,而是一个完善的架构,一个完整的研发中台,希望可以为项目管理,开发,管理带来战略上的共赢。

2、持续迭代,不断更快更好的升级和优化

在后续不断的学习中,会不断的去学习,实践自己的想法,整合更好的资源,技术,吸收更稳定的,可用的东西,不断的提升研发中台的能力。

这是一个很长的过程,可能是一年,两年,甚至是五年十年,学习不止,步伐不停,积跬步以至千里,积小流以成江河。打造研发中台的过程其实出来这个并不是中台的精品,而是这个精品是你自己,磨炼的不是所谓的中台,而是你自己。

最后

以上就是带学生团队1年多来走过的历程,从零实现,走过的路程。不算长,也不算短,只是一个过程。