编程实践选型通史:平坦无架构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

相关文章
|
3天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
20 5
|
6天前
|
监控 Go API
Go语言在微服务架构中的应用实践
在微服务架构的浪潮中,Go语言以其简洁、高效和并发处理能力脱颖而出,成为构建微服务的理想选择。本文将探讨Go语言在微服务架构中的应用实践,包括Go语言的特性如何适应微服务架构的需求,以及在实际开发中如何利用Go语言的特性来提高服务的性能和可维护性。我们将通过一个具体的案例分析,展示Go语言在微服务开发中的优势,并讨论在实际应用中可能遇到的挑战和解决方案。
|
4天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
4天前
|
消息中间件 缓存 Cloud Native
云原生架构下的性能优化实践与挑战####
随着企业数字化转型的加速,云原生架构以其高度解耦、弹性伸缩和快速迭代的特性,成为现代软件开发的首选模式。本文深入探讨了云原生环境下性能优化的关键策略与面临的主要挑战,通过案例分析,揭示了如何有效利用容器化、微服务、动态调度等技术手段提升应用性能,同时指出了在复杂云环境中确保系统稳定性和高效性的难题,为开发者和架构师提供了实战指南。 ####
18 3
|
4天前
|
运维 Kubernetes Cloud Native
深入理解云原生架构:从理论到实践
【10月更文挑战第38天】本文将引导读者深入探索云原生技术的核心概念,以及如何将这些概念应用于实际的软件开发和运维中。我们将从云原生的基本定义出发,逐步展开其背后的设计哲学、关键技术组件,并以一个具体的代码示例来演示云原生应用的构建过程。无论你是云原生技术的初学者,还是希望深化理解的开发者,这篇文章都将为你提供有价值的见解和实操指南。
|
6天前
|
人工智能 自然语言处理 前端开发
用通义灵码,从 0 开始打造一个完整APP,无需编程经验就可以完成
通义灵码携手科技博主@玺哥超carry 打造全网第一个完整的、面向普通人的自然语言编程教程。完全使用 AI,再配合简单易懂的方法,只要你会打字,就能真正做出一个完整的应用。本教程完全免费,而且为大家准备了 100 个降噪蓝牙耳机,送给前 100 个完成的粉丝。获奖的方式非常简单,只要你跟着教程完成第一课的内容就能获得。
|
4天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
18 3
|
4天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####
|
7天前
|
监控 API 持续交付
后端开发中的微服务架构实践与挑战####
本文深入探讨了微服务架构在后端开发中的应用,分析了其优势、面临的挑战以及最佳实践策略。不同于传统的单体应用,微服务通过细粒度的服务划分促进了系统的可维护性、可扩展性和敏捷性。文章首先概述了微服务的核心概念及其与传统架构的区别,随后详细阐述了构建微服务时需考虑的关键技术要素,如服务发现、API网关、容器化部署及持续集成/持续部署(CI/CD)流程。此外,还讨论了微服务实施过程中常见的问题,如服务间通信复杂度增加、数据一致性保障等,并提供了相应的解决方案和优化建议。总之,本文旨在为开发者提供一份关于如何在现代后端系统中有效采用和优化微服务架构的实用指南。 ####
|
7天前
|
数据采集 网络协议 算法
移动端弱网优化专题(十四):携程APP移动网络优化实践(弱网识别篇)
本文从方案设计、代码开发到技术落地,详尽的分享了携程在移动端弱网识别方面的实践经验,如果你也有类似需求,这篇文章会是一个不错的实操指南。
20 1

热门文章

最新文章