程序员修炼与低代码平台AppCube
编者按:这是本人在《云享读书会——程序员修炼之道:通向务实的最高境界》的读书笔记,首次发表于 https://bbs.huaweicloud.com/forum/thread-63227-1-1.html 第117楼。全文如下:
在我观看《程序员修炼之道:通向务实的最高境界》的前四天,一直没有猜到华为官方会以AppCube作为实践作业为此次读书笔记的实践。毕竟一本由敏捷宣言的17个签署者中的2名重量级人物David Thomas(大卫托马斯)和Andrew Hunt(安德鲁亨特) 写的经典作品,难免不带点“敏捷”的基因。
而华为云中,最跟敏捷适配的产品,应属Devcloud了
(上图为 辉哥的巴赫猜想)
华为云Devcloud是将敏捷的理念和实践融合在一起,集Scrum,看板方法思想,Devops,持续集成为一体的一站式开发平台。其功能包含需求规划,代码仓库,代码扫描,编译构建,部署,测试等敏捷开发的各个流程。使用华为云DevCloud,基本上可以实现提交代码到部署上线的一键部署。即您仅需在编辑器中使用Git工具提交您的代码修改,后续的流水线作业(如代码扫描、编译构建、部署等)全部由华为云自动完成。您仅静静地用下面这个可爱的杯子泡杯茶,然后就什么事情都是华为云的了。
然而,我想错了!实践作业跟Devcloud并无半毛钱的关系。
当然,我又在揣摩自己,是不是因为官方听了我的话,接收了我的建议,毕竟我在云享读书会曾经提出这样的想法:(参见 https://bbs.huaweicloud.com/blogs/169268)
即:学员已经对读书会使用devcloud作为实践作业产生了审美疲劳。。。能不能换一个。然后读书会的组织者终于被逼的要有所创意,所以才换成AppCube?
我又仔细想了一下,好像我没那么厉害。应该是我并没有领悟到《程序员修炼之道》的精髓。直到2020年8月8日5:5这个对称的时间,我突然想到了一个哲学问题——
程序员,活着是为了干嘛?改变世界?那是乔布斯的使命。我只能做个普普通通的程序员,希望自己能用这双弹不了钢琴的柔弱双手,来维持自己微薄的生活。
那么,当我进入职场之后,多少会对自己的职业规划产生迷惑。因为一般情况下,程序员的野蛮生长,无非最终归结到两条路:
成为技术专家,这个一般是以P开头的职位,如阿里P6.
成为管理者,这个一般是以M开头的职位,如阿里M2
对了,几乎每个程序员的道路都离不开这两条路中的一条, 除非他选择了第三条路:放弃做程序员,改行去养猪。——请注意,我讲的这个改行去养猪,其实就是低代码平台中所说的——业务人员。
请读者不要小看这个养猪的,要是不懂得饲料,不懂得养猪技巧,不懂得猪瘟如何预防,是养不好猪的。而且,从道理上说,业务人员也并非低于软件工程师(即程序员)一等。(在前两天的泥石流群里的讨论中,我还第一次听到有项目在应用 业务敏捷。可见敏捷从来也不是IT行业的专有名词,甚至它的来源之一的精益,也是出自于生产系统。)
那么,回到主题,作为一个程序员,我们到底应该如何成长呢?在现在这个专业分工越来越细的今天,就连以前简单的JSP都变成了前端工程化,Java,C++,Python,PHP,Go,Ruby,JS等语言层出不穷,微服务、Serviceless、ServiceMesh、DDD、AI(机器学习、强化学习)、IoT、SLAM等技术也不断出现。面对IT领域这一知识谱系。程序员如果一天不学习,大概就觉得自己要落伍了(这可能也是我为啥不敢落下每期云享读书会的终极原因)
其实,低代码平台给大家的路线其实已经很清晰了。Low Code或者是No Code,就是有这样一个平台,你只需要进行拖拉拽,就可以靠各种组件来实现你自己的业务。你可能都不需要懂代码。当然,如果你懂一点代码也没事,你可以对组件本身做扩展,或者对组件的实现做一些扩展。平台预留给你扩展组件或者扩展组件特性的能力。这就是低代码平台的目的:让业务人员和软件工程师都能成功地使用低代码平台(请注意这里有泄露自测题的答案。。。)那么,作为低代码平台的初级使用者,这也许是你当程序员头几年可以快速入门的道路。
然而,你一定会想?这就是那个在学校里面学了(大于等于)四年计算机的我吗?当然不是。要知道,有些人很看不惯这种关于使用产品的问题,但是,一个好的程序员,绝对不会因为一开始老板让你去学习使用产品而觉得老板轻视你,而是会觉得,这正是一个机会。如果自己的目标是做一个比较“伟大”的产品,那么,总得知道心目中的产品是怎么样的吧?比如乔布斯的IOS、雷布斯的MIUI、还有华为的AppCube,正好是你作出一个好产品的参照物。你也许会这样想:我以后也要做成一个像AppCube这样一个伟大的产品(。。。看来已经摆脱不了软文的嫌疑了。。。)然后,你就会立足于,给AppCube多提BUG,多写云声建议。。。
是的,当你通过试用对AppCube等产品有了实际体验后的了解之后,你一定会想:这样的产品是怎么做出来的?需要怎样的技术?我们还是可以初看上面那张图:
对于AppCube的页面工具(UI Builder)而言,支持拖拉式的UI页面,使用VUE技术,融合了各种典型布局,由此来简化页面设计人员的操作,甚至使用UI Builder来制作页面的人,都不需要懂JavaScript,ES6,CSS、HTML或者Vue.js。当然,作为想修炼的程序员的你而言,你需要懂。而且,你甚至可以通过了解UI Builder融合了哪些页面模板,去思考这些页面框架到底是使用什么技巧设计出来的。此时,你会发现,自己的目标已经变成了,如何掌握高深的前端开发技巧,做出一个类似UI Builder的低代码页面来了——你看,你已经为你自己找到了一条修炼之道——成为一名出色的能制作低代码平台前端模块的高级程序员。
不仅仅是页面,要知道,AppCube的业务流程,也是通过托拉拽的方式制作的。如下图所示:
这个定义一个绩效考评业务流程的方式,完全也是所见即所得的方式。对于利用图形化的工具制作页面本身,对业务人员而言,其实已经没啥难度了。当然,对于每个节点具体的属性定义,业务人员也许会感到有些吃力。
毕竟像上面的 {! performanceRevice.employeeName} 这样的配置内容,业务人员还是需要有点理解才能会用。但是(初级)程序员在这块,应该已经是游刃有余了。
那么,高级程序员在这里会想什么?——对了,高级程序员最会的就是合并同类项的操作(找出事物的一般规律)。我们该思考那些类型的节点(如活动由哪些,事件有哪些,网关有哪些),每个节点应该有哪些属性和方法?这些属性和操作该用怎样的图形化界面来展现,才能让使用平台的人用起来顺手,也不觉得难?如何把看起来难度很大的东西做成一个类似LEGO搭积木就能完成的东西。体现高级程序员高级智慧的内容大概也就在此吧!
那么,我该如何抽取这些规律?这可能涉及到领域建模、业务建模、产品需求规划、业务调研、技术调研、系统分析,架构设计等一系列环节。咦,系统分析员和系统架构师是不是就是搞这个的?有可能。初级程序员和高级程序员之间的分野大概也在于此。你看,我已经给大家找到了一条通过AppCube进行程序员野蛮成长的道路。
让我们来回顾下《程序员修炼之道2》这本未拿到的书里面提到的一些关于程序员修炼的精华之语吧:(右边是笔者的注解,正如我注六经~六经注我。。)
1 | 人生是你的 |
作为入门程序员,你选择技术路线,还是管理路线,还是专家路线? |
2 | 我的源码被猫吃了 |
制造并解决BUG——程序员一生的使命(必达) |
3 | 软件的熵 |
熵只能增加。软件的BUG却可以减小。只要使用低代码平台。所有的BUG都不是使用低代码平台的人的,而是开发低代码平台的人的。 |
4 | 石头做的汤和煮熟的青蛙 |
作为程序员,要会了解技术前沿,不要闷头做事,要抬头睁眼看世界(多上云享读书会了解这个软件世界) |
5 | 够好即可的软件 |
程序员应该是天生完美主义者,但对自己做出来的软件总不会很满意。不过,每次够用就行。每次追求完美,不应该是程序员每个产品的目标,经过无数迭代后的终极完美才是目标。 |
6 |
知识组合 | 程序员规划好自己的职业生涯发展规划,并按照规划去学习自己的各类技能,甚至包含心理学和情商、财商。 |
7 |
交流 |
养成写好文档,学好英语的习惯,这会使程序员受用终身 |
8 |
优秀设计的精髓ETC | 拥抱敏捷,适应变化 |
9 | Dry**的重复 |
坚持软件复用原则。组件化设计。减少代码重复率。 |
10 |
正交性 |
组件化设计。解耦。减少不同模块中的设计关联 |
11 |
可逆性 |
让自己的软件更容易重构。不囿于当前的技术。不拘泥于固定的数据库、中间件、操作系统,做到跨平台、跨产品的支持。满足用户实际不同环境的需要。 |
12 |
曳光弹 | 通过不断尝试去寻找目标,而不是拘泥于一开始的设定目标。软件需求也是一个不断地跟客户沟通反馈的过程。也许我们在跟着亮光追寻目标的过程中,会发现闪光点(亲爱的金子) |
13 |
原型和便签 | 使用原型工具(比如Axure)快速实现你的原型,在不开发代码的情况下,拿原型跟客户交流(采用12的思路进行反馈) |
14 |
领域语(靠近问题域编程) | 程序员都该学习下DDD |
15 |
估算 | 别忘记量化自己的工作。这使得程序员要会做好自己的时间管理(有时间学习,有时间工作,还有时间能打游戏、刷抖音。。。) |
16 | 纯文本的威力 | 程序员要多会使用文本编辑器。比如黑客常常用终端,也没那么多图形化的东西。 |
17 |
Shell游戏 | 基本上同上一条。终端操作通过SHELL进行 |
18 |
加强编辑能力 |
感觉还是同上面两条。纯文本编辑。文本对比,文本检查。 |
19 |
版本控制 |
一种不让你今天的活白干的方法,如果不能(假如你今天忘记git commit),至少可以不让你昨天的活白干。 |
20 |
调试 |
调试可以写一本书。但自动测试是个趋势。正如初级程序员和高级程序员的区别那样,编写自动测试的代码,那是初级程序员的事情,编写自动测试和压力测试的工具(如LoadRunning和JMeter等),那是高级程序员的事情。“程序员的修炼之道”之典型案例。 |
21 |
文本处理 |
同16-18。使用awk,sed工具可能是基本技能。唉,感觉这本书这几点怎么有注水的嫌疑? |
22 |
工程日记 |
记下自己的思考,记下自己的BUG,写下明日的计划。所有的记录,将是你一生的财富。 |
23 |
契约式设计 |
契约驱动编程,消费者契约模式。敏捷开发的重要观点之一。2/17的敏捷干(私)货 |
24 |
死掉的程序不会说谎 |
如果程序死了,一定是哪里有问题。不要只怪用户的环境不好,要想想自己是不是兼容性做的不够——这是笔者夹带的私活,希望华为云的工单管理员能懂。。。。 |
25 |
断言式编程 |
assert仅在DEBUG时起作用,其目的是说明这是一个不该发生的情况,提前检查错误的输入,避免程序因这种问题陷入混乱的情况。 |
26 |
如何保持资源的平衡 |
说小了是要规划好内存,CPU,硬盘的搭配,说大了只要做负载均衡,流量控制,微服务的横向扩展,数据库的横向扩展,几乎每一个领域都是一个非常大的话题。 |
27 |
不要冲出前灯范围 |
好像是12曳光弹的引申。循序渐进的做反馈和调整,不要做目前规划以外的事情。不要好高骛远,要脚踏实地。 |
28 |
解耦 |
跟9**重复,10正交性也有关系。主要是解耦的基本原则。一个代码不依赖于外界对它做改变,而是自己做改变 |
29 |
在现实中抛球杂耍 |
通过状态机的设计去解决流程编排问题(这是一种从业务视角去分析的方法) |
30 |
变换式编程 |
程序的基本思想就是 输入-处理-输出,俗称IPO。对,股票那个IPO就是跟这个学的。(玩笑ing~~) |
31 |
继承税 | 继承是对象的基本思想,但是继承却不是一个特别好的东西。我们得想用别的方式代替它。比如接口和委托的方式。 |
32 | 配置 | 把配置信息放在代码外面,比如applicaiton_dev.yml和application_prod.yml. |
33 |
打破时域耦合 | 一种分析并发业务的方法。 |
34 |
共享状态是不正确的状态 | 通过信号量,互斥锁来解决并发过程中的资源互斥问题 |
35 |
角色和进程 | 采用角色的思路做并发处理也许可以避免问题 |
36 |
黑板 | 在黑板上进行表达,协调。(为啥不是看板。。。怕是夹带吗?。。。) |
37 |
听从蜥蜴脑 | 如果解决不了问题的时候,就去听首歌吧。。。比如《肖申克的救赎》里面放的那首曲子。。。 |
38 |
巧合式编程 | 不要以为自己很巧合地解决了问题,多想想解决问题的原因。具体案例可参见我的博客 :《前端小白历险记(一)链接的斜杠怎么没有了?》(https://bbs.huaweicloud.com/blogs/181124)和《前端小白历险记(二)原来是你腾讯搞的鬼!》(https://bbs.huaweicloud.com/blogs/191671) |
39 |
算法速度 |
去LeeCode刷题吧。程序员如果不懂算法和数据结构,哪敢称程序员? |
40 |
重构 |
程序员总是喜欢重构别人的代码,因为只有自己的代码才能看懂。程序员也经常被别人重构代码,道理同左。当然,我们希望的重构,是因为有新的技术,比如用Spring cloud去重构SpringMVC代码。 |
41 |
为代码测试 |
跟20差不多。。。 |
42 |
基于特性测试 |
还是测试,只不过基于特性来分析。 |
43 |
出门在外注意安全 |
安全第一。代码安全尤为重要。特别是大环境下的代码安全。 |
44 |
事物取名 |
这其实是一个代码编写规范中的命名规则。好的名字容易当明星。像笔者这种大众化的名字适合于隐于世。 |
45 |
需求之坑 |
做过需求的人,都知道需求一定有坑。客户不知道做成啥样,需求分析师和产品经理也一样不知道做成啥样——如果不掌握一定的需求分析方法,需求就会变成我们意想不到的样子。当然,如果掌握了方法,需求也会变成我们意想不到的样子,但是那是一种可控的样子(正如整容脸,我可以控制自己被整容成罗晋,或者王一博,那是我的需求,你能做到吗?嘿嘿。。。) |
46 | 解决无法处理的难题 |
同37。说的都是跳出五行外,不在三界中的意思。当局者迷,有时候就不能把自己当做当事人。要把自己当外人。。。 |
47 |
携手共建 |
敏捷干货。敏捷思想的精髓之一是信任。建立学习型组织。 |
48 |
敏捷的本质 |
敏捷宣言。这次完全表明了态度。这本书就是一本让程序员走向敏捷的指导书。。。。 |
49 |
务实的团队 |
同47。Scrum团队2个披萨原则。T型团队成员挑选和成员成长原则。 |
50 |
椰子派不上用场 | 找寻适合自己产品的技术,不要硬塞不合适的。 |
51 |
务实的入门套件 |
还是版本控制和测试的内容。跟19,20,41,42有关联。 |
52 |
取悦用户 |
这里提到的还是产品的价值的目的是满足客户需求。让客户找到产品的价值,这才是你做产品的根本动力(难道不是卖掉产品吗?) |
53 |
傲慢与偏见 | 程序员不低下自己高贵的头颅,这是程序员的傲慢,程序员签下自己的大名(Created by zhanghui 2020/8/8),这是程序员对自己产品的负责态度(有问题别找我~~) |
通过老师对《程序员的修炼之道2》的领读,感到自己作为一名伪程序员,还任重道远。很希望自己能通过更多的读书会,赢得白(拿奖品)富(态的啤酒肚)美(得像罗晋),走向人生巅峰。
(全文完,谢谢阅读)
- 点赞
- 收藏
- 关注作者
评论(0)