如何顯著提升軟體開發效率?
提升開發效率 (Development Efficiency) 是一項結合工具應用、程式碼品質與決策智慧的綜合指標。其加速目標可拆解為三:1. 減少打字時間:透過 AI 工具 (如 GitHub Copilot) 輔助生成程式碼、使用 Snippets 並落實 DRY 原則 提升重用率;2. 縮短除錯與測試時間:導入 CI/CD 自動化流程、TypeScript 強型別檢查與 Linter 以攔截低階錯誤;3. 優化閱讀時間:透過 React 重構 將業務邏輯(Hooks)與 UI 渲染分離,消除程式碼中的「暗號」與冗餘狀態。效率的本質不在於沒日沒夜的加班,而是在於透過明智的技術選型與架構優化,讓開發過程變得可預測且易於維護。
小編在前陣子參加了 AWS 社群日,體驗了怎麼用機器學習模型來為遊戲結果提供預測。在這樣短暫的體驗下,AI 工具 在過程中給了不少協助。這讓我深思:在軟體工程領域,正確的選擇與工具應用,究竟能如何 提升開發效率?
在這樣短暫的體驗下 AI 在過程中給了不少協助,舉個正在頻繁發生的例子來說,在 GPT 在跟 Chat 一起出現之後
- Copilot 的出現也讓小編的同事在撰寫單元測試省下很多時間
- 給圖片能夠產生出程式碼的 Figma
- 聊天機器人帶來的新零售和電子商務
- 生成式藝術
接下來的下個時代,快速跟著世代變化做選擇似乎變得越來越需要。在 軟體工程 領域,我們經常需要決定學習哪些新技術。這些 技術選型 將直接影響我們的開發速度與軟體品質。
這幾年的生活和工作發展下來,體驗到的是
工作和生活就是我們過去所做過的選擇的總和
當你重回當初的模樣,回頭過來看看曾經瘋狂、荒謬、驚奇、平靜、難忘的生活,最難遺忘的會是什麼。
工作的選擇
想來談談工作的選擇,資本主義社會給了我們穩定的金錢和標籤,而透過金錢和標籤請我們進行角色扮演。
在角色扮演的過程中,各種決定和取捨總會需要評估,其中只存在一個問題,那就是工作對你而言是什麼?選擇工作對人生價值有何意義?
在工作的選擇上可以粗分成三大類
- 核心工作: 最重要、最有價值的任務和職責
- 開發核心產品功能
- 解決關鍵技術問題
- 提供高品質程式碼
- 協作和溝通
- 專案工作
- 發展性工作
這三類大致構成了工作的樣貌,而金錢本身讓你為了這些犧牲了什麼?交換了什麼?舉個例子來說,最害人不淺的一句話大概就是你的工作很穩,快去買棟房子吧!這句話背後的交換隱含了些什麼?
買了房子之後,公司和老闆給了足夠的金錢,兌換未來 30 年不間斷的專案工作,這會是你想要的人生嗎?生活選擇該是一道道單選題,或是該持續反思後才選擇往前進?
環境的選擇
人際關係和工作環境也可能會是有毒的,生活中其實最該選擇和斷捨離的會是人際關係,小時候常常聽到人脈,但其實多認識一個人其實不會真的多什麼資產。
- 融入群體有必要嗎? 如果那個群體有毒,那不就會慢性中毒?
- 為什麼無法過著自己想要的生活,跟大家一樣到底有什麼好?
- 團隊對我的工作必要嗎? 團隊能幫助我接近理想生活嗎?
充滿著追求更多,最終會不會就過著被被垃圾資訊、物質淹沒的生活。
底下是小編請 Chat GPT 列出的一些警訊
- 不正常的壓力和負面情感
- 控制和操控
- 不健康的競爭
- 缺乏支持和合作
- 缺乏職涯發展
- 不透明和不公平
- 虛偽和欺騙
- 工作生活無法平衡
工具的選擇:程式碼品質檢查與 CI/CD 自動化
工具的選擇是 提升開發效率 最直接有感的方式。我們可以將其分為兩大類:
- 自動化和程式碼品質檢查工具
- ESlint、SonarLint: 自動檢查程式碼,並且建議最佳實踐
- commit lint: 自動檢查 commit 的 message
- Prettier: 確保一致的風格
- 持續整合和持續交付(CI/CD)工具,以實現自動化的測試、部署和整合,這些工具可幫助減少人工造成的風險並把開發流程自動化
- Jenkins: 老牌好用的 GUI 工具但其實也支援用程式碼進行設定
- Travis CI、Circle CI: 第三方的老牌服務,透過 YAML 來設定
- GitLab CI、GitHub Actions、Azure DevOps: 版控工具原生內建的工具,算是近期推出的全家餐解決方案
程式撰寫的優化:React 開發的三大加速目標
以程式碼撰寫來說,想要 提升開發效率 主要有三種加速目標:
- 更少的打字時間
- 更少的除錯與測試時間
- 更少的閱讀時間
接下來的內容主要來翻譯 Double your react coding speed with this simple trick 這篇文章,會從剛剛提到的三個角度來切入 React 開發效率。
更少的打字時間
要讓打字時間縮短,大致上分為兩個方向:
DRY 增加共用的程式碼: 大元件拆分成小且可重用的 hooks 或元件
- 資料處理邏輯獨立
- 元件只處理顯示
- 簡化輸入參數 (props)
善用工具
- Snippets: 編輯器外掛協助自動完成
- Auto Import: 編輯器外掛協助路徑輸入
- prettier: 編輯器自動格式化
更少的除錯與測試時間
通常找到錯誤的流程要先把 App 用開發模式跑起來後,操作元件重現錯誤並查看相關錯誤訊息,修復後重試。在開發階段如果要避免低階錯誤,可分成兩個方向
- 撰寫測試並導入 CI/CD,在流程中就靠機器提早幫我們發現問題
- 善用工具,在開發階段透過 eslint、props type check、TypeScript 來避免低階問題
更少的閱讀時間
開發者最常花時間在看懂程式碼而非撰寫,通常好的程式都有容易被修改、容易發現問題的優點,那在撰寫上列出幾個我覺得需要改掉的壞習慣:
- 程式碼太多暗號
- 類似功能卻散在各處
- 太長的函式,需要花時間才能了解
- 使用上需要滿滿的參數卻又未分類
- 太多布林值狀態
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
| value[0][index] = sum;
<Grid data={gridData} pagination={false} autoSize={true} enableSort={true} sortOrder="desc" disableSelection={true} infiniteScroll={true} ... />
const options = { pagination: false, autoSize: true, enableSort: true, sortOrder: 'desc', disableSelection: true, infiniteScroll: true, ... }
<Grid data={gridData} options={options} />
const [isLoading, setIsLoading] = useState(false) const [isFinished, setIsFinished] = useState(false) const [hasError, setHasError] = useState(false)
const fetchSomething = () => { setIsLoading(true)
fetch(url) .then(() => { setIsLoading(false) setIsFinished(true) }) .catch(() => { setHasError(true) }) }
const [state, setState] = useState('idle')
const fetchSomething = () => { setState('loading')
fetch(url) .then(() => { setState('finished') }) .catch(() => { setState('error') }) }
|
React 重構實踐:從資料邏輯切割到元件化優化
元件優化的方向與過程,最主要還是拆解成可重複使用的小單位,像是運用 render props 或是 HOC 甚至是寫成 Custom hook,對岸維護的 ahook 功能就非常多樣。透過 React 重構,我們可以將常見的優化分為以下三個部分:
- 打 API 的寫法
- 初階: 在元件裡面抓資料
- 進階: 透過 redux 這類工具統一資料處理邏輯
- 進階: 寫一個 hook 或是使用 react-query
- 錯誤處理
- 初階: 直接在打 API 的 function 中寫判斷
- 進階: ErrorBoundary 處理或是 axios interceptor
- 樣式檔的優化
- 初階: CSS
- 進階: Sass or SCSS
- 進階: CSS-in-JS
- 進階: Atomic-css
最開始的元件撰寫通常會長成下面這樣,在同樣一個元件裡面放了狀態,打 API 抓資料的相關程式,還有顯示的部分,好處當然就是直觀也不會說不好維護,但當這樣的元件有 50 個的時候,打 API 的方式要修改時,也許就會懷疑人生?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
| import React, { useEffect, useState } from "react";
import AddModal from "../components/AddModal"; import LoadingIndicator from "../components/LoadingIndicator"; import BrowserItem from "../components/BrowserItem";
import colors from "../config/colors";
function Browsers() { const URL = "https://google.com/myData.json";
const [loading, setLoading] = useState(true); const [browsers, setBrowsers] = useState([]);
const [modalVisible, setModalVisible] = useState(false); const [description, setDescription] = useState("");
const changeDescription = (description) => { setDescription(description); setModalVisible(!modalVisible); };
const changeOpacity = () => { setModalVisible(!modalVisible); };
useEffect(() => { fetch(URL) .then((response) => response.json()) .then((responseJson) => { return responseJson.Browsers; }) .then((browsers) => { setBrowsers(browsers); setLoading(false); }) .catch((error) => { console.log(error); }) .finally(() => setLoading(false)); }, []);
return ( <> {loading ? ( <LoadingIndicator /> ) : ( <> <AddModal modalVisible={modalVisible} changeOpacity={() => changeOpacity()} description={description} /> <List data={browsers} keyExtractor={(browser) => browser.fullname} renderItem={({ item }) => ( <BrowserItem {...item} changeDescription={() => changeDescription(item.description)} /> )} /> </> )} </> ); }
export default Browsers;
|
將資料邏輯切割成更小可以重複使用的 hooks,當這些資料存取寫法被共用時就達到
- 加速開發: 因為重複使用
- 更快速找到問題: 遇到問題可以減少閱讀和測試這些部分
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
| import { useEffect, useState } from "react";
function useFetch(url) { const [loading, setLoading] = useState(false); const [data, setData] = useState(undefined);
useEffect(() => { setLoading(true); fetch(url) .then((response) => response.json()) .then(setData) .finally(() => setLoading(false)) .catch((error) => Alert.alert("Fetch error", error)); }, [url]);
return { loading, data, }; }
function useBrowsers(url) { const { loading, data } = useFetch(url); const [selectedBrowser, setSelectedBrowser] = useState(undefined);
return { loading, browsers: data?.Browsers, selectedBrowser, setSelectedBrowser, }; }
|
切割成更小可重用的元件且拿掉大部分的資料邏輯,僅留下 conditional render 的相關實作,元件行數下降找問題的速度肯定又更上層樓。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
| function UIFriendlyList(props) { if (props.loading) { return <LoadingIndicator />; }
if (props?.data && props.data.length === 0) { return <Text>This list is empty (</Text>; }
return <List {...props} />; }
function BrowsersList(props) { const { loading, selectedBrowser, setSelectedBrowser, browsers } = props; return ( <View style={styles.container}> <AddModal modalVisible={Boolean(selectedBrowser)} onClose={() => setSelectedBrowser(undefined)} description={selectedBrowser?.description} /> <UIFriendlyList loading={loading} data={browsers} renderItem={({ item }) => ( <BrowserItem key={item.fullname} browser={item} onPress={() => setSelectedBrowser(item)} /> )} /> </View> ); }
function Browsers() { return <BrowsersList {...useBrowsers("https://google.com/myData.json")} />; }
|
FAQ:開發效率優化常見問題
Q1:過度依賴 AI 工具 (如 Copilot) 會不會退化開發能力?
A:將 AI 視為「資深結對程式設計夥伴」。AI 擅長處理樣板程式碼與單元測試框架,但您仍需負責架構設計、安全性與效能的決策。正確的使用方式是讓 AI 處理瑣事,讓您有更多時間思考業務邏輯。
Q2:何時應該進行 React 元件重構?
A:遵循「三次原則 (Rule of Three)」。當某段邏輯在專案中重複出現三次,或者一個元件的行數超過 200 行且包含複雜的 useEffect 時,就是重構的最佳時機。過早重構(抽象)有時會帶來不必要的複雜度。
Q3:自動化工具會不會反而拖慢開發速度?
A:短期設定可能需要時間,但長期而言是「加速」的。例如,ESLint 能在您存檔時就修復潛在 Bug,比執行完整個 App 再去看 Console 報錯快得多。自動化是將「重複的人力成本」轉化為「一次性的系統投資」。
更多相關文章
想建構具備高擴充性的軟體系統嗎?本篇指南深入探討 Domain-Driven Design (DDD) 與 API-First 開發策略。我們將解析如何建立領域模型、運用通用語言並落實開放封閉原則 (OCP)。前 150 字直接回答 DDD 與 API-First 的核心定義,助您以業務邏輯為中心,打造穩定且靈活的現代化架構。
大家都說需要,就真的需要嗎?本篇指南從需求管理出發,以 React 的 Redux 架構為例,深入解析技術選型的權衡。我們將分析全域狀態管理的開發負擔,並對比傳統 Redux、Redux Toolkit 與原生 Hooks 的適用場景。前 150 字直接回答選型核心,助您做出更明智的系統設計決策。
有重複程式碼就是壞味道嗎?本篇指南從主觀價值出發,探討程式架構中的「好與壞」。我們將解析 Shotgun Surgery (散彈槍式修改)、Divergent Change (發散式修改) 以及內聚與耦合的核心定義。前 150 字直接回答程式碼異味的本質,助您在靈活擴展與集中管理之間找到最佳平衡點。
您是否正深受「隕石需求」與交付期限的壓力?本篇指南探討時間限制對開發效率的影響。我們將從《人月神話》出發,分析「隕石式開發」與「敏捷開發」的應對之道。前 150 字直接回答時間管理的生存核心,助您在資源有限的情況下透過優先順序與自動化測試,達成高品質交付。
擁有過多物品不一定快樂,軟體開發也是如此。本篇指南探討軟體開發中的六大核心成本:流程、理解、修改、執行、測試與技術成本。前 150 字直接回答開發成本的本質,助您在有限資源下做出智慧抉擇,透過斷捨離與自動化,打造高效且易維護的系統架構。
喜歡這篇文章,請幫忙拍拍手喔 🤣