编程实践选型通史:平坦无架构APP开发支持与充分batteryincluded的微实践设施-阿里云开发者社区

开发者社区> 开发与运维> 正文

编程实践选型通史:平坦无架构APP开发支持与充分batteryincluded的微实践设施

简介: 关键字:自带paas语言系统,自带组件,自带用户工具语言系统,一元下的多元,初学者第一门实践语言选型

关键字:自带paas语言系统,自带组件,自带用户工具语言系统,一元下的多元,初学者第一门实践语言选型

在编程实践选型上,往往涉及到来自语言,应用,工具,人(又分多种角色)多个方面的影响,需要处理多个现有生态异化矛盾和处理已有实现之间的差距,甚至出现需要重新发明语言等基础设施间的轮子的情况都时有发生,是一个格局需要放大到软件工程方方面面的过程。—–一言以概之:软件工程,——-其实,大凡考虑进所有事情并最终处理涉及到人端的那些方面的事情都能称为工程,可见其大和复杂,这也是为什么很多图省事的方案企图提出一个“one for all”终极方案的原由所在。这个“one”往往可能被实现为开发上来讲的一种/多种语言系统,一个包含语言修正/强化的framework(如qt),一个工具,一套问题域解法,一套敏捷方法,等等,当然更有可能是它们的综合 —- 公司或个人将他们做成自己的codebase用于持久复用以应付统一选型。。

在《1ddlang选型》一文中归纳的是以前1-4种旧的纯粹语言选型方向的“one for all”讨论—lddlang也就是某种1ddcodebase,在那里我们主要聚集语言内部特性。本文作为《1ddlang选型》,《语言选型简史:快速整合产生的断层》的系列之三,将继续着眼于大的工程方面的综合实践选型。

那么,有多少种oneforall?都有过哪些实现或案例呢?理想的oneforall呢,这样的终极方案始终存在吗?讨论它有意义么?

虽然被不断怀疑,然而终极编程和“one for all”真的存在,它并不需要是类似编程葵花宝典之类的东西,我们可以理解让编程体现为适可而止,有止境的境界,在工程上(编程上让事情变得越来越容易最后不需投入或极少投入再学习成本),通往其的方法可以有很多种,但一种无疑是那种—比如,某种直到脚本和可视编辑器级的工具级开发封装。
如果编程方法可以归结为一门最终的哲学,学者可以利用它举一反三,完成自举学习,那么这种元性质的哲学,就是终极。
图形界面的出现和DLL API机制,VB可视化,在这个意义上都是伟大的铺垫作品,面向对象也是一种终极编程,它在语言内在抽象接近平民,各种OO范式,PME,再后来,框架容器,都是使编程变得终极的方法和基础工作。

这些只是整合而已,严格来说其主旨只有二点:
1)着眼于大的面向人的工程和实践方面,首先要保证这个一体化方案必须是方案全包和self contained的(没有断层,不用跨越,,不用四处找方案)。必须是“一元下的多元”。比如统一后端语言系统要包含多种前端做到no binding。就可视作是此。
2)然后是平坦化(“多元下的一元化”)。能围绕一门语言良性地建立起实践的方方面面工程与选型,且所有其中的东西都是one style的no steeps,故这样的方案必须要包含一门语言,一种部署方案,然后使这一切形成平坦化的。可能最终归于一门语言系统级的封装实现中。

故最大整合,全包,又要求良性集成 – 尽量多用onestyle的抽象线索来整合并突出统一易用能用。才是其主要特点,而如上所讲,一元下的多元,多元下的一元onestyle其实并不矛盾

也许最好的例子,就是我们熟知的WEB和web开发界中.net这样的东西,WEB是一个涉及到运用云计算这些最新软件技术的领域,又运用了上述所有这些—-特别是语言上的开发技术,的地方如.net,js(当然还有更多…),是封装最完善最统一的领域,可以很好拿来作为例子。

《编程的最高境界是什么》:以web举例,onestyle WEB开发与调试设局的编程实践

WEB开发是现今最简单的开发,没有最简,因为它就是最简。

WEB前端开发门槛很低,因为在大量框架下,最前端的样式效果开发(实际上不叫开发,叫界面配置)已经变成纯粹的艺术行为了,因为它变成了debug and visual driven coding,或称programming,而js用来编程前端html dom 和style elements,也可用同样的调试和开发方式被调试。

而web app开发主要是处理一些服务性的api,云时代不同应用通过service api交互,服务性API,js+xml(json,etc..)让任何领域逻辑的开发编程,都变成都是界面编程下的逻辑(前端也是xml->html,css也有xml化的scss)。xml是数据化代码转领域逻辑的终极手段。

这二者是统一的技术一个可视一个XML语义化而已,使用相同的语言。这个层上的web开发就是一个充分经过了onestyle风格整合过程的多工程开发领域。这主要指问题域还有使用的语言,见下:

什么是终极编程及最好的实践语言,以js+.net举例

在前文《语言选型通史中》中我们谈到.net和JS,谈到前者的统一后端特性和后者的跨三界开发。

1) js为什么流行

a, 前端是一个对领域逻辑封装得最完善的领域,包括桌面GUI,HTML,网站模板技术,MVC范式等。html标识系统,JS作为前端语言内部的适用性,源于web前端,也能应用成为mobile,native的前端。

b, 而js也可用于后端服务器甚至传统native开发—当然这是非c runtime的而是jsruntime backend的(这属web的“系统编程”了,实现编程,区别前面谈到的service api应用),js+web有鲜明的one lang,one problemdomain solution的特点(这里js是nodejs实现或emcs规范,它被广泛用于服务端编程),虽然它只是在目前慢慢成为事实…。

你的第一门实践语言,应该是类JS的,松语法描述,调试资源丰富,从界面到逻辑,一条龙,可渐进,先前端再后端再全栈,是实践的最佳路径和起点。这或许就是为什么JS是越来越多地成为最佳实践语言的原因根本

2) 再来看.net和web的后端,系统编程和实现方面:面向多种定制化的平台,包括工具在内的全生态self contained

因为clr平台提供了最基础的后端和组件环境,包括语言服务,平台后端,工具在内的东西都可以定制成self contained的,可以说,统一后端,将原来native开发上可用的东西全弄到可托管后端支持下:

a, 统一后端,也是统一了平台,跨mobile,web,native desktop,是第四代语言最鲜明的特征。

(与traditional c runtime backend nativedev分开,在这里,桌面开发分native上的桌面开发,和托管到.net clr上的桌面开发,.net上有自己的封装版本,所以这是另外一种全功能的跨desktop,web,mobile托管平台。不对native开发断层。)

b, .net 可以直接调用语言服务,甚至新的语言完全可以通过dropin语言前端的方式放置的方式安装。因为在.net统一后端下服务即组件所以接入了后端的语言前端只是普通组件可按普通API方式调用。

c, .net这样的框架为IDE提供了一个统一。使得sharp,mono,vs这样的东西不致于存在像本地编译器那样的鸿沟,比如不必安装巨大的本地sdk,大家可以共用一套runtime(由于.net runtime即组件,组件即源码标准库,不必发布巨大的sdk),sharp,mono可以仅面向托管码,调试,智能提示可以轻易做得跟vs一样强大。

这点使得用户维护一个属于他们自己的,且跨三平台统一的codebase,runtime,ide,甚至一切成为可能并可打包带走。

它是一种根本上的迁移。只要是在迁移之上的东西,都是self contained.taken alway的。

架构已定,用户入阶和工具支持方面:

如果说选型已定(包括OS支持,语言,语言强化,服务端引擎,具体应用体系 — 这些往往被做在了一体化的语言或统一后端中,或PAAS环境中),那么这里就是尾端APP开发。由于问题域实在太复杂太多变太广泛,很难有大全的编程套件能兼顾覆盖全部领域,而.net这样的统一后端能容易裂变成子集又有社区包管理,能最大程度地向无架构APP开发靠拢。

充分的复用支持和应用域实现及工具级支持 —- 但这也是在当今时代,复用二字,是用户需要学会用他们解决问题的最基础方法和唯一手段,也是使用任何语言最基本的素养要求:.net开发只是设想你会任何一门它支持的语言,即使是vb.net或是某brainstorm。

1) engitor无架构APP开发:

全生态+无架构是微实践的基础。因为只有做到了无架构,才能避免在用户开发APP层级还进行复杂设计的必要,才能到达微实践的地步。架构和设计已在前面的语言整合中被解决了。

用户开发应该是二次开发,无架构,平坦式复用,,,而大部分时候我们都是在进行二次开发。以软件为体系进行该软件之下的扩展开发,形成的应用叫APP。那种带设计的大型开发,要么是重造轮子,要么是更复杂一点的二次开发而已。

比如,OO就是语法代码级的扩展。和二次开发。是语言级对开发是一层层堆栈或剥栈的事实反映,迭代是最安全的类OO之于demo继续演化的工程行为行为,也强调继承了以一点点叠加慢慢发展的思路。因为从抽象上说,软件本质就是栈的添加修正行为。所以,结合《编程实践养成过程反推式》:demo演化,也是编程。只不过它处在工程明显的地方,即尾端。

所以,用户设计中,应该尽可能地避免复杂设计和规模过大的问题封装。(导致的语言应用过于复杂和问题封装问题)那种为了特定问题提出一套语言特性的做法更是不可取。语言核心应该稳定,不应该从下而上地变,虽然从上而下地变是可以的。更不应该透给用户编程层。

2) 微实践:

在以上架构下,实践者仅要求有的基本素养,1你不需要懂太多,在你能控制的复杂度内干正确的事;2假设在新API面前,每个人都是脚本工具小子,这样就够;3,懂得适当的逻辑归类,甚至免OO,比如,你不习惯用OO,完全可以用编辑器或者用统一后端支持下的仅支持过程函数在源码文件中摆放编程的免OO DESIGN语言来编程。

一个能打包打包,在一个小时,一篇文章中讲完教完的编程实践才是好的自包含的微实践课程。这对最初级的学习者也适用。

.net和js,它们都是onestyle的code and demobase(说demo是因为有组件,这个demobase是comopentbase),js npm社区有几行代码组成一个库的micro service存在。开发只是组合服务。

demo as engine+microservice开发兴起了,所以1dddemobase > 1ddcodebase了,找类qt的那种开发库组织1ddcodebase过时了。恩直接找大量第三方小件,杂乱的也行,只要搭出的demo具备好的facades就行了。

可复用件选型+小微开发,这一切得盖于最良性的基建结构—语言选型部分。


(此处不设回复,扫码到微信参与留言,或直接点击到原文)

qrcode.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章