Code Refactoring｜林鼎淵 Dean Lin

ChatGPT Code Review、Refactoring、Comments 的能力如何？

林鼎淵 — Wed, 25 Jan 2023 22:01:46 +0800

雖然之前讓 ChatGPT 寫 Side Project 時遇到一些狀況，不過這很可能是因為 ChatGPT 的資料截止於 2021 年所造成的。

所以今天想來試試看，如果是「已知」的 Code，ChatGPT 的 Code Review 能力如何？能幫我們解釋（Explain）、重構（Refactoring）、加註解（Comments）嗎？

這邊我們就使用上一篇 Side Project 完成的 Code，來看看 ChatGPT 的表現。

大綱

▋ 直接把程式碼丟進 ChatGPT 會發生什麼事？
▋ 讓 ChatGPT 用中文解釋程式（Review and explain）
▋ 用 ChatGPT 重構程式（Refactoring）
▋ 用 ChatGPT 幫程式碼加上註解（Comments）
▋ 結論：用對地方就是好幫手！

直接把程式碼丟進 ChatGPT 會發生什麼事？

這邊我把先前的「註解」都拿掉，直接丟到 ChatGPT 看看會發生什麼事。

require('dotenv').config();
const line = require('@line/bot-sdk');
const express = require('express');
const { Configuration, OpenAIApi } = require("openai");
const configuration = new Configuration({
  apiKey: process.env.OPENAI_API_KEY,
});
const openai = new OpenAIApi(configuration);

const config = {
  channelAccessToken: process.env.CHANNEL_ACCESS_TOKEN,
  channelSecret: process.env.CHANNEL_SECRET,
};

const client = new line.Client(config);

const app = express();

app.post('/webhook', line.middleware(config), (req, res) => {
  Promise
    .all(req.body.events.map(handleEvent))
    .then((result) => res.json(result))
    .catch((err) => {
      console.error(err);
      res.status(500).end();
    });
});

function handleEvent (event) {
  if (event.type !== 'message' || event.message.type !== 'text') {
    return Promise.resolve(null);
  }

  return openai.createCompletion({
    prompt: event.message.text,
    model: "text-davinci-003",
    max_tokens: 1000
  }).then((completions) => {
    const message = completions.data.choices[0].text.trim();
    return client.replyMessage(event.replyToken, {
      type: 'text',
      text: message
    });
  });
}

app.listen(3000);
console.log('Linebot is running on 3000 port');

從 ChatGPT 的回覆中，我認爲他對程式的理解非常正確；當你接手一份程式碼，而前人完全沒有寫註解時， ChatGPT 能幫你加快理解這份程式。

讓 ChatGPT 用中文解釋程式（Review and explain）

不過有時英文讀起來有點吃力，我們可以透過下面這段 prompt，讓他改成用「中文列點」來解釋。

Review code and explain in traditional Chinese [List of points]

ChatGPT 的解釋挺讓我驚豔的，清晰明瞭的說明每個「套件的職責」，以及程式的「功能」。

用 ChatGPT 重構程式（Refactoring）

這邊我們再用下面這段 prompt，來實驗他重構程式，以及解釋重構理念的能力如何。

Refactoring the code and explain in traditional Chinese

下面是 ChatGPT 重構後的程式：

require('dotenv').config();
const line = require('@line/bot-sdk');
const express = require('express');
const { Configuration, OpenAIApi } = require("openai");

const app = express();
const client = new line.Client({
  channelAccessToken: process.env.CHANNEL_ACCESS_TOKEN,
  channelSecret: process.env.CHANNEL_SECRET,
});
const openai = new OpenAIApi(new Configuration({
  apiKey: process.env.OPENAI_API_KEY,
}));

app.post('/webhook', line.middleware({
  channelAccessToken: process.env.CHANNEL_ACCESS_TOKEN,
  channelSecret: process.env.CHANNEL_SECRET,
}), async (req, res) => {
  try {
    const results = await Promise.all(req.body.events.map(handleEvent));
    res.json(results);
  } catch (err) {
    console.error(err);
    res.status(500).end();
  }
});

const handleEvent = async (event) => {
  if (event.type !== 'message' || event.message.type !== 'text') {
    return null;
  }

  const { data: { choices } } = await openai.createCompletion({
    prompt: event.message.text,
    model: "text-davinci-003",
    max_tokens: 1000 
  });

  const message = choices[0].text.trim();
  return client.replyMessage(event.replyToken, {
    type: 'text',
    text: message
  });
};

app.listen(3000);
console.log('Linebot is running on 3000 port');

於結尾 ChatGPT 有說明自己的重構理念：

使用 async/await 處理 promise 鏈，使程式碼更具可讀性。
把 client 和 openai 的實例化移到最上層，使程式碼更整潔。
使用解構賦值提取 openai 回應中的 choices，使程式碼更簡潔。
把 handleEvent 函式移到最上層，使其更易於測試。
使用箭頭函式語法使程式碼更一致。
使用縮寫屬性名稱使程式碼更簡潔。

這邊我得給他拍拍手，就算筆者認真重構都很難考慮的這麼完善。

這次 ChatGPT 重構完的程式是可以正常運行的，這點超重要！

因為實務上最怕重構後功能就壞掉，不過還是建議讀者將 ChatGPT 重構完的程式測試一遍，不要百分百相信。

如果你對他的說明不理解，也可以再進一步詢問他（像是我對第 6 點就看不太懂）。

看完 ChatGPT 的解釋後，我回頭看了一下程式碼還是覺得怪怪的，所以我再次詢問。

對… ChatGPT 的解釋有時不完全正確，如果發現問題可以跟進一步他討論。

另外我跟他討論後，又把 line 設定 config 的部分調整回來，因為 config 應該要集中設定，而不應該分散在多個位置。

const config = {
  channelAccessToken: process.env.CHANNEL_ACCESS_TOKEN,
  channelSecret: process.env.CHANNEL_SECRET,
};
const client = new line.Client(config);
app.post('/webhook', line.middleware(config), async (req, res) => {
// code..
}

用 ChatGPT 幫程式碼加上註解（Comments）

寫程式總是懶得寫註解？用下面這段 prompt 就能讓 ChatGPT 幫你完成這些瑣事！

add code comments

下面是 ChatGPT 加上註解後的程式。

require('dotenv').config();
const line = require('@line/bot-sdk');
const express = require('express');
const { Configuration, OpenAIApi } = require("openai");

// Initialize express app
const app = express();

// Get config values from environment variables
const config = {
  channelAccessToken: process.env.CHANNEL_ACCESS_TOKEN,
  channelSecret: process.env.CHANNEL_SECRET,
};

// Initialize line client
const client = new line.Client(config);

// Initialize openai api
const openai = new OpenAIApi(new Configuration({
  apiKey: process.env.OPENAI_API_KEY,
}));

// Handle post requests to /webhook
app.post('/webhook', line.middleware(config), async (req, res) => {
  try {
    // Map handleEvent function over all events and wait for all promises to resolve
    const results = await Promise.all(req.body.events.map(handleEvent));
    res.json(results);
  } catch (err) {
    console.error(err);
    res.status(500).end();
  }
});

// Handle a single event
const handleEvent = async (event) => {
  // Only handle message events of type text
  if (event.type !== 'message' || event.message.type !== 'text') {
    return null;
  }

  // Get choices from openai response
  const { data: { choices } } = await openai.createCompletion({
    prompt: event.message.text,
    model: "text-davinci-003",
    max_tokens: 1000
  });

  // Send the first choice as a message reply
  const message = choices[0].text.trim;
  return client.replyMessage(event.replyToken, { type: 'text', text: message });
};

// Start listening on port 3000 
app.listen(3000);
console.log('Linebot is running on 3000 port');

以筆者的角度來看，有些註解顯得多餘，但我覺得這些註解對新手理解程式很有幫助；實務上要保留、調整、移除，就看讀者的個人需求了。

如果想要移除所有註解，輸入 remove code comments 即可。

結論：用對地方就是好幫手！

由於過去請 ChatGPT 寫 Side Project 時遇到各種挫折，讓我一度懷疑 ChatGPT 的戰力，但這篇文章總算是幫他板回一城。

因為目前 ChatGPT 的資料截止於 2021 年，所以面對較新的技術、工具時，他的表現有點差強人意；但在面對「已知」的事物時，他所展現的功力並不輸一名訓練有素的資深工程師，確實能增加工作效率。

其實我還有請他幫我將 JavaScript 重構成 TypeScript，但他最終只轉出一份很像可以跑的程式；but…實際上跑不動，還需要自己去微調許多細節，這邊我就不放上來了，期待日後會推出更完善的版本。

未來筆者會出一系列使用 ChatGPT、openAI 的文章，如果你對這個議題感興趣，可以持續關注我的文章！

AI 實戰實測生成式 AI 工具、Vibe Coding 與自動化流程的第一手心得，把 AI 變成每天都用得上的即戰力。林鼎淵 Dean Lin

想將 AI 導入自己的職場與生活嗎？歡迎購買筆者出版的新書，幫助您在 AI 的浪潮中站穩腳步，並在未來的職場競爭中佔據優勢！

https://www.books.com.tw/products/0011004216

參考資料：

ChatGPT Refactor 後的程式：Github
ChatGPT Refactor 並加上註解的程式：Github

[前端]新手工程師容易卡住的問題 — 下班有約系列文

林鼎淵 — Wed, 23 Feb 2022 10:03:38 +0800

筆者跟擔任 Tech Lead 的朋友聊天時，發現我們在幫新人 Code Review、Code Refactoring、Bug Fixing 時遇到了許多類似的問題，針對這個部分我安排了 3 篇文章做講解，而今天這篇文章會針對新手工程師容易卡住的問題來做分享。

大綱
➤ 對網頁的元件(tag)、屬性(attr)不熟悉
➤ 對 Object、Array 以及 null、undefine、"" 的特性並不熟
➤ 不了解「==」跟「===」的差異
➤ API 傳參數時遇到各種遇到困難
➤ 非同步(Asynchronous)/同步(Synchronous)概念混亂
➤ 不了解程式的運作流程
➤ 演算法能力需要加強
➤ 看不懂 Console 吐出的錯誤

對網頁的元件(tag)、屬性(attr)不熟悉

通常我們對「按鈕」的認知是「button」這個元件，相關的「click」事件也是由它來觸發；但我曾經遇過下面這個案例：

<v-btn color="grey" class="ml-4 mt-7">
  <h6 @click="search()">搜尋h6>
v-btn>

原始碼：err_button.html（GitHub Gist）

他將「click」的事件包到「h6」這個元件中，這造成有時候點擊按鈕是沒有反應的，因為 click 事件觸發的有效範圍只在「h6」裡面，而不是整個 button 的範圍。

後來發現這類因為對網頁元件不熟悉而導致的 Bug 還蠻常見的，如果 Debug 遇到類似問題時，可以先到網路上查詢大家通常會用這個元件來做什麼事，可以減少烏龍事件的發生。

筆者曾看過用「table」來做切版的，在電腦螢幕 Demo 時看起來一切正常，但切換到手機的瞬間就崩潰了…

對 Object、Array 以及 null、undefine、”” 的特性並不熟

前端串接 API 時，通常都會接收到以 json 格式回傳的物件，但假設我們要取得的是 Array 裡面的資料，如果沒有經過驗證就直接使用很容易會產生 Bug。

像下面這個範例，如果回傳的是空陣列，如果沒有先驗證「陣列長度」就直接取用就會噴錯誤。

let response = [];
console.log(response[0].status);

原始碼：array_err.js（GitHub Gist）

有時我們會用物件參數的值來判斷要執行哪個程式，但如果用 undefined、空字串、null 來比對，就可能造成程式沒有依照我們想的邏輯去執行。

let user = {
  id: 1,
  name: "baobao",
  email: "baobao@gmail.com",
  status: "",
};
if (status === null) {
  console.log("執行A");
} else {
  console.log("執行B");
}

原始碼：null_logic.js（GitHub Gist）

下面再舉例一個極端物件，大家可以不要急著往下滑看答案，先思考看看印出來會是什麼結果？

let object = {
  a: "",
  b: undefined,
  c: null,
  d: [],
  e: {},
};
if (object.a) console.log(object.a);
if (object.b) console.log(object.b);
if (object.c) console.log(object.c);
if (object.d) console.log(object.d);
if (object.e) console.log(object.e);

原始碼：object_example.js（GitHub Gist）

從下圖你可以看到除了「陣列、物件」外，其他都不會通過喔～

又或者有時我們在處理字串時會用「include」這個函式來比對，但如果你丟進去的參數是「null、undefine」這類的也會出事喔！

let object = {
  string: null,
};
object.string.include("something..");

原始碼：include_err.js（GitHub Gist）

不了解「==」跟「===」的差異

不知道大家有沒有想過上面提到的「undefined、null、空字串」如果用「==」跟「===」來比較會有怎麼樣的結果。

console.log("undefined==null", undefined == null);
console.log("undefined===null", undefined === null);
console.log("null==''", null == "");
console.log("null===''", null === "");
console.log("''==undefined", "" == undefined);
console.log("''===undefined", "" === undefined);

原始碼：null_undefined_empty.js（GitHub Gist）

或者像是數字、字串、布林值這類的比較，有時這類型的的錯誤也常常讓人 Bug 找半天。

console.log("'true'==true", "true" == true);
console.log("'true'===true", "true" === true);
console.log("1=='1'", 1 == "1");
console.log("1==='1'", 1 === "1");

原始碼：number_boolean.js（GitHub Gist）

API 傳參數時遇到各種困難

許多新手前端儘管可以完成切版，但是在串接 API 時卻遇到非常多的困難，就算看著 API 文件，在操作 GET、POST、PUT 傳遞參數時有很高的機率傳錯格式，像是：

POST 的參數用 Params 傳，直接變成明碼。
不知道 Body 的 form-data 怎麼組成、raw 如何組成 json 格式。
常常有缺少或是格式錯誤參數。

這部分我覺得如果後端工程師願意將 Postman 的 Collection 匯出，並在 Description 寫好邏輯直接讓前端工程師來確認，就會稍微減少以上的問題。

非同步(Asynchronous)/同步(Synchronous)概念混亂

以非同步(Asynchronous)來說，最常見的錯誤就是前端在呼叫 API 時，並沒有等待資料回傳就直接使用它，導致畫面渲染的時候出現各種 Bug。

以同步(Synchronous)來說，有時會設計了太多不必要的等待機制，導致在某個環節卡死無法進行下一步。

不了解程式的運作流程

新進工程師通常都要維護 Legacy code，但通常他們並不具備掌握程式運作流程的能力。

這塊除了註解以及技術文件可以加快新手的熟練度外，資深工程師願意一起 Pair Programing 也是一個讓新進工程師能力大增的方式。

我在實戰經驗中發現手把手教學（pair programing）的效率比給 hint 的效率高很多，如果只給新手 hint，除發他天賦異稟，不然有大機率是有聽沒有懂。

在幫忙 Debug 時，筆者也發現很多新手工程師並不瞭解自己的程式到底會怎麼跑，這個時候我們可以透過下中斷點（Breakpoint），讓程式執行的每一步慢慢地在我們眼前呈現。

演算法能力需要加強

很多時候一個結果是需要經過多次運算才會得到，其中可能含有複雜的 and(&&)、or(ll)、not(!)、大於(>)、小於(<)..邏輯。

假設你今天要設計一個打卡系統，如果要判斷一個職員今日出勤是否有異常，在程式設計上就需要考慮到幾個基礎邏輯：

公司是否有彈性上、下班時間
該名職員上、下班打卡時間是否在彈性上、下班的區間中
該名職員上班總時數是否符合公司規定
在判斷上下班打卡異常時，是否有考慮到假勤

如果上面的邏輯複雜度已經超過你的腦容量，我強列建議回歸紙筆。

複雜的邏輯用紙筆寫下來會比較容易理解，這是因為大腦在面對電腦時，邏輯容易憑空想像；而用紙筆寫的時候則可以將邏輯具象化，讓大腦放慢一點腳步反而能找到解法。

想提升演算法能力，推薦挑戰 LeeCode easy 等級的題目。

看不懂 Console 吐出的錯誤

遇到問題卡關時，我們往往會先上網找答案，不管正不正確，先貼回來看看能不能動。

有時候可能真的找到正確解答了，但因為兩者程式執行的環境不同而有報錯，此時很多新人會因為看不懂這個錯誤，轉而找其他的解答複製貼上。

其實如果你將上面的錯誤訊息貼到 Google，就有很大的機率可以得到解答；一直尋找只靠一步就能完成的解答，有時反而是在走遠路。

StackOverflow 上面聚集各種大神，只要善用關鍵字，基本上你遇到的問題以前已經有數不清的人踩過坑了。

只使用自己會的技能

面對新的問題時，我們會習慣從大腦搜尋已經純熟技能，但有些問題是現有技能無法處理的，或者要花大量時間才能解決。

以前端的 UI Component 舉例，有些人花大量的時間去創造，但往往最後產出的結果遠遠不如現成的框架、套件，甚至還會有各式各樣的 Bug。

下次遇到現有技能很難解決的問題時，不妨先搜尋網路，看看是否有前輩已經提供很好的解決方案；學習新技能所花的時間，有時會比硬要用過去技能解決更省時喔～

這篇文章只是舉出最常見的幾個問題，筆者相信還有很多點沒有提到，如果讀者有想到的話歡迎補充～

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

https://www.tenlong.com.tw/products/9786264142083

下班有約系列文
▋ [前端]新手工程師容易卡住的問題(本篇)
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！