提升開發效率與 AI 工具應用高品質攻略 實踐打字與閱讀除錯加速技巧打造高效工作流

me
林彥成
2023-10-13 | 7 min.
文章目錄
  1. 1. 如何顯著提升軟體開發效率?
  2. 2. 工作的選擇
  3. 3. 環境的選擇
  4. 4. 工具的選擇:程式碼品質檢查與 CI/CD 自動化
  5. 5. 程式撰寫的優化:React 開發的三大加速目標
    1. 5.1. 更少的打字時間
    2. 5.2. 更少的除錯與測試時間
    3. 5.3. 更少的閱讀時間
    4. 5.4. React 重構實踐:從資料邏輯切割到元件化優化
  6. 6. FAQ:開發效率優化常見問題
    1. 6.1. Q1:過度依賴 AI 工具 (如 Copilot) 會不會退化開發能力?
    2. 6.2. Q2:何時應該進行 React 元件重構?
    3. 6.3. Q3:自動化工具會不會反而拖慢開發速度?

如何顯著提升軟體開發效率?

提升開發效率 (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 開發的三大加速目標

以程式碼撰寫來說,想要 提升開發效率 主要有三種加速目標:

  1. 更少的打字時間
  2. 更少的除錯與測試時間
  3. 更少的閱讀時間

接下來的內容主要來翻譯 Double your react coding speed with this simple trick 這篇文章,會從剛剛提到的三個角度來切入 React 開發效率。

更少的打字時間

要讓打字時間縮短,大致上分為兩個方向:

  1. DRY 增加共用的程式碼: 大元件拆分成小且可重用的 hooks 或元件

    • 資料處理邏輯獨立
    • 元件只處理顯示
    • 簡化輸入參數 (props)
  2. 善用工具

    • Snippets: 編輯器外掛協助自動完成
    • Auto Import: 編輯器外掛協助路徑輸入
    • prettier: 編輯器自動格式化

更少的除錯與測試時間

通常找到錯誤的流程要先把 App 用開發模式跑起來後,操作元件重現錯誤並查看相關錯誤訊息,修復後重試。在開發階段如果要避免低階錯誤,可分成兩個方向

  1. 撰寫測試並導入 CI/CD,在流程中就靠機器提早幫我們發現問題
  2. 善用工具,在開發階段透過 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 重構,我們可以將常見的優化分為以下三個部分:

  1. 打 API 的寫法
    • 初階: 在元件裡面抓資料
    • 進階: 透過 redux 這類工具統一資料處理邏輯
    • 進階: 寫一個 hook 或是使用 react-query
  2. 錯誤處理
    • 初階: 直接在打 API 的 function 中寫判斷
    • 進階: ErrorBoundary 處理或是 axios interceptor
  3. 樣式檔的優化
    • 初階: 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);
// console.log(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} />;
}

// BrowsersList.tsx
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 報錯快得多。自動化是將「重複的人力成本」轉化為「一次性的系統投資」。


喜歡這篇文章,請幫忙拍拍手喔 🤣