In the previous series of " Cloud R&D: R&D is Code " articles, we introduced the coded closed loop of software engineering. At the same time, " Water: Cloud R&D Architecture Mode " introduced some of the patterns we need in designing such a development environment. Today, as a series of landing practices, we will introduce the design ideas of cloud R&D IDE and how to implement it. Of course, there is a bit of early code: https://github.com/inherd/uncode.
First statement: This is a conceptual IDE design and is not suitable for any production environment for the time being.
Before we start to read it, in order to make everyone understand better, we have to review the software engineering industry:
The DevOps concept has made considerable progress in the domestic software industry, and has been widely accepted by companies including traditional enterprises (banks, manufacturing) and has been widely promoted.
Cloud native technology has become a mainstream trend in the market. Cloud migration and the migration of legacy systems to the cloud are a hot topic in the market.
China and Taiwan’s methodology still lacks real success stories in practice.
Low-code/no-code platforms have gradually become a new construction goal.
Cloud development has more and more small and medium-sized application cases.
AI code generation is being verified on a small scale.
From the perspective of the industry as a whole, people's focus has always been how to improve technological productivity? Now the technology has reached a new stage, and the conversion of requirements greatly limits the speed of people's development. So no matter how well our DevOps and cloud development are implemented, we will fall into the bottleneck of isolation of demand and technology. This is why we need a cloud research and development theoretical system:), through the coding method, one-stop solution to the problem of demand, design, and then code.
For the cloud research and development theory, I have designed the theoretical foundation, software architecture, and development model, and verified a series of things, such as: document coding, requirement coding, code coding, etc.
We need a container to integrate these contents, patterns, and codes. This is Uncode, a conceptual cloud development IDE.
Uncode, a cloud development IDE
Uncode is a next-generation conceptual IDE designed for the era of cloud research and development. characteristic:
The process is transformed into a domain language . Process as code
Everything is DSL . Coding of Everything
The development environment is the process .
To put it simply, you can do it on this IDE: writing requirements, converting requirements to design, designing associated codes, programming in Zen mode, and going online after development.
In contrast, the traditional one-stop DevOps portal, although you can complete it by jumping, it cannot be interconnected and designed. It is similar to GitOps, which stores the declarative infrastructure and applications of the application system in the Git repository. But they are neither closed loop nor complete.
Cloud R&D IDE model: Process is the language of the domain
Back to software development, our software development needs start with a big feature or epic story, these stories will be transformed into one feature, such as Cucumber:
# author: Phodal HUANG
# status: doing
# language: zh-CN
功能: 第一个用户故事
场景打开 Uncode
假如我在 Terminal 工具里
当输入 uncode
那么则能在 Uncode IDE 里打开当前项目
Before this step, the requirement designer converts the requirement into a story, and the relationship between the story and the feature is recorded in this feature . Developers see the requirements from the IDE, mark the corresponding status status, and then enter the code design phase.
In the design phase, we designed the first design of three types: flow, , model, uicorresponding to the flow design, model design and UI design. The part we want to implement in Uncode is the binding of requirements with models, flows, and UI. Around the model, we have to construct a unified domain language to automate the associated interface and design. In terms of mode, this is similar to no-code/low-code development.
The only difference is the description. Only by using domain-specific language to describe the content can we reasonably reconstruct the system.
Cloud R&D IDE model: everything is a file
The core philosophy of Linux/Unix is "everything is a file".
In today's development environment, we select cards on the Kanban board, or generate them through a low-code editor, and the storage media used are all databases. The database does not exist in the development environment, but is placed on a remote server. This creates another pain point, such as the inability to simply reverse association, isolation of requirements and code, and so on.
Therefore, as the second mode of cloud development IDE, all content is saved in files and managed by version management tools (such as Git). If our requirements are stored in the database in a code-like situation, the following features can be achieved:
"Unforgeable"
"Leave a trace all the way"
"Traceable"
"Open and transparent"
"Collective Maintenance"
Yes, this is a blockchain system. Once the demand has changed, you can immediately perceive it. However, once your code does not conform to the model, your code cannot be submitted, or the model is automatically modified:(.
Cloud R&D IDE model: development environment is the process
As an integrated development environment, the existing one-stop DevOps software R&D management collaboration platform should only be used for management and display purposes. In terms of design itself, a Dashboard and an open source tool have their own division of labor.
We have requirements on the code base, then we can use the IDE:
Re-visualize the demand locally in the form of a Kanban.
Visualize the language of the design field locally and associate it with the code.
Highlight all code blocks that need to be modified. Such as Controller, View, etc.
Reversely correlate model modifications to the design to track the correctness of the design in real time.
We can also do things that are not so correct, such as locking down the scope of developers' modifications.
Cloud R&D IDE mode: fill-in-the-blank/selective programming
For software architects, people often have such pain points:
Faced with inexperienced developers, it is difficult to quickly promote the development of the system.
Developers lack understanding of the system and modify the wrong code in the wrong place.
Therefore, returning to the TypeFlow point of view, now that we have designed the model and designed the input and output, we must be able to generate the intermediate method and its return value, and design a mock object for it. Such as:
@RequestMapping("/")
String home() {
return "Hello, World!"
}
This model is very easy to implement for business application development-generating various functions in the binding process and so on.
Selective programming . Once all the codes in our organization are indexed, we have the ability to identify the input and output, as well as the corresponding method name, and then recommend the corresponding method in the IDE for you to choose.
Basic Elements of Cloud R&D IDE
Just look at it like this, we just need to do the IDE things well. However, this is not the case, there are still some things we need to do:
Development is deployment . That is, local dev is the dev server, which can be directly connected to the existing system.
Everything is DSL . Have a certain level of programming language design ability.
API API . That is, the existing internal and external APIs will be abstracted and designed to provide fast usable APIs.
Development is deployment-cloud development environment
From a development perspective, we have been wasting the local environment and online development environment back and forth, and at the same time there are corresponding test running time, build time, etc. We need a mechanism in the cloud development environment .
Speed up the process of joint debugging and testing . When our local environment is on the cloud, once we need to interface with other systems, all development and testing efficiency will be greatly improved. For example, our interface needs to provide one more parameter. After the traditional mode, we have to run it locally, and then build and deploy through the pipeline. Now, this process is no longer needed, just configure the Gateway, and develop easily.
Speed up environment construction . We no longer need to configure the development environment locally, just 1-click to debug directly in the local IDE.
There is already a bare-bones concept on the market: Nocalhost
Abstract abstraction: DSL
The abstraction of requirements, design, development, testing, etc. has always been the focus of my research last year. It includes:
Demand abstraction
Design as abstract
-
Architecture description language
Unified modeling language
Version management abstraction
Build tool abstraction
This series of steps is converted into a domain-specific language-only by abstracting processes, tools, and behaviors can we optimize the entire system.
Glue design: API API
Software development is a complex team activity. In a system, we have to associate with a large number of internal and external systems. In order to simplify the burden on developers, we need to provide a new API to encapsulate the existing API.
For example, in the existing mode, in order to record a log, we need to introduce the corresponding dependency in the dependency management tool, and then add the corresponding code. All APIs are being updated, and this series should be completed by the IDE itself. In this mode, we only need to input the corresponding to snippetscomplete this series of automated process operations.
technical details
Finally, we return to the code: https://github.com/inherd/uncode/
Architecture design
I decided to use the new architecture design routine I designed to show the architecture of Uncode IDE. Due to the large uncertainty, the existing system is designed in a way between monolithic and micro-architecture + modularization. I thought about it and called it fluid mode . A mode of unpredictably splitting architectural units in the process of continuous evolution.
In the driving mode, it consists of four modes:
Modularity.
Management and filters. Mainly for designing domain-specific languages
Partner mode (sidecar). Separate languages such as language analysis into processes, and implement cross-platform through process calls
Container bridge. Isolate the UI presentation from the logic, and make most of the components of the IDE have nothing to do with the UI.
At the same time, the physical design of the system intends to adopt a domain-driven approach.
Frame selection
Considering that this is low-level development + system programming, we:
Use Rust as the main development language
In UI display, temporarily use Tauri (WebView container) + React to display requirements (local Kanban) and design (modeling, etc.).
Use TypeScript as part of the UI development language
Use RPC as the communication protocol with multiple DSLs
……
Still, this project will continue to be developed on the Inherd team~~.
FAQ and others
Code: https://github.com/inherd/uncode/
vs Intellij IDEA or VSCode / Theia
It is not a completely competitive relationship, and the functions of this part of the coding are still more popular. Uncode will not create wheels in this area in the early stage, but will integrate them explicitly or be integrated.
Uncode prioritizes the localization of DevOps and integrates it into the development process.
other
One final statement: This is a conceptual IDE design and is not suitable for any production environment for the time being. Welcome to join the WeChat seminar group of Cloud Research and Development.