自學程式語言前,你真正該注意的問題解決技巧

更新於 發佈於 閱讀時間約 12 分鐘
零基礎,也能學會的解決問題的四步驟
Photo by Jonathan Kemper on Unsplash
什麼,才是真正值得解決的問題?
在大學時期,我在寫程式時,總是習慣根據腦中的想法,直接開始寫程式。在一半的時間其實蠻順利能寫出結果;但另一半的時間會卡住,而當我卡住或專注力不佳時,解問題的效率就變得非常差。
而且常常寫到一半,就忘記自己在哪一個階段,資料處理到什麼程度,甚至在最後結果發生 bug 時,也不知該如何處理。直到最近,在解決問題和撰寫專案時,嘗試使用解決問題的流程,讓我意外發現這個流程節省了我超過 30% 以上的時間。
也和超過上百位的工程師聊過,我才發現在選擇程式語言,如 Python、Java、JavaScript、C 等之前,真正重要的關鍵–––建立解決問題的心態與方法。這也是我聊過這麼多人選,他們在找工作時,決定他們面試順利的關鍵。(延伸閱讀:如何以恰當的心態學習程式
今天,就在這一篇文章,和大家分享解決問題的四步驟,就讓我們從解決問題四步驟開始,架構的流程如下:
  1. 釐清問題
  2. 拆分問題
  3. 進行研究
  4. 寫偽代碼

解決技術問題的四步驟

解決技術問題的四步驟 我自己過往曾經學過設計思考(Design Thinking)、麥肯錫問題解決流程,甚至台大的 CTPS 等。每種解決問題的流程,都是針對不同的問題設計與應用。
因此,當我面對到技術問題時,也一樣會有相應的技術解決流程。今天,就和大家分享,結合過往學過的問題解決流程,可以如何應用在解決技術問題。
如果我有1小時拯救世界,我會花55分鐘去確認問題為何,只以5分鐘尋找解決方案 –––愛因斯坦 Albert Einstein。
無論哪一個問題解決的流程,釐清問題總是佔了流程的重要階段。甚至可以說,沒有釐清問題,就沒有解決問題。過往,我習慣在一收到需求後,就開始搜尋可能的問題解決方案;但有時會落入不停的試錯卻無果的狀態。
因此在後來,我習慣遇到問題時,就先停下來思考。
我究竟在解決什麼問題
為了讓讀者能夠一起深入瞭解,解決問題的流程該如何實際應用,就讓我們以大華的故事,來深入理解吧!

一、釐清問題(Clarify)

Photo by Emily Morter on Unsplash
大華是一位在電商公司的工程師。有一天,團隊的菜鳥 PM 跑來找大華,跟你說:「欸!我們最近新的商品推薦頁面要上線,你幫我寫一個邏輯,可以處理用戶丟進來的資訊,並到資料庫撈推薦的清單推薦回去」。

1. 確認效益與商業價值

大華收到這個問題後,就先停下來思考–––我現在面對的問題是什麼
接著,大華又問了自己下面兩個問題:
  • 該功能帶來什麼商業價值?
  • 該功能預期實現的效果是什麼?
於是他跑回去,詢問 PM 上面兩個問題。PM 跟他說:「這個功能,是因為我們有新的聯名產品頁面要上線,所以需要讓用戶在搜尋後,能夠收到聯名內容推薦的商品。」
「這一次找了很大牌的品牌商聯名,因此公司蠻看中這一次的上線。至於預期的呈現效果,是我們會提供給用戶,幾個商品內容常見的 hashtag 來點選。」
「因為目前的產品都是新合作的廠商,都沒有相關的購買記錄。我們請行銷先給了一份名單,並請 Data Scientist 根據過往的商品類別,跑了一份預設的推薦清單。」
大華接收到上述資訊後,釐清到了幾個重點:
  • 該專案為重點專案:後續的需求可能會增多,或要求較高。
  • 預計呈現效果固定:因為沒有過往銷售記錄,因此會根據 Data Scientist 提供的清單匯出。呈現的狀態如其他的商品頁相似,但需要加上品牌商的設計與官方網站連結(因應要求)。商品呈現的內容含括:商品名、圖片、合作品牌、價格、簡介。

2. 確認技術產出

大華確認了整個專案的目的,以及預計呈現的效果後,才開始著手規劃功能。接著,面對這個問題,大華列出了幾個問題:
  • 資料是怎麼產生的?
  • 預期的輸入是什麼?格式是什麼?
  • 如果輸入出現例外,如何處理?
  • 可以如何解決問題?
  • 會有歷史資料的影響嗎?
  • 輸入與輸出的單位是什麼?
  • 預期的輸出是什麼?格式是什麼?
  • 後續有什麼規劃?需要產生什麼資料?
隨著向 Data Scientist、後端確認資料,確定輸入的資料是以 JSON 輸出,串接的 API 是 XXX。傳入的資料都是 JSON 格式,用戶輸入的也僅有固定的標籤,不會有例外。若網路錯誤或資料錯誤,則說明搜尋有誤,直接跳回全部商品頁面。
屆時輸出的格式,產品名與價格需要有 i18n 處理多國語言與貨幣,呈現的格式會請 Designer 設計。每一次推薦的順序都一致,不需要根據使用者點擊後有差異。因為這次是和品牌商合作,需要有 GA 資料確認成效,後續才有數據可以分析。
接著在後面,會有其他相關的產品頁面,因此有可能會有其他類型的聯名品牌產品頁,要注意未來輸出的擴張性,不要直接將資料處理寫死。

二、拆分問題(Problem Destruction)

有了具體的輸入與輸出,接著就要將問題逐步拆分。大華重新審視 PM 提供的產品需求文件,大致區分為幾個步驟來處理:
  1. 輸入資料格式為 JSON,使用非同步 fetch 資料
  2. 確認 i18n 的設定,確認產品名、價格順利設定為當地資料
  3. 處理資料的判斷,透過 Tag 標籤屬性,確認該群產品類別
  4. 輸出為產品頁面,以 React 來進行開發
藉由拆分整個需求問題,將需求切分為四個部分,又各自根據資料處理,切分為數十個函式個別處理。到目前為止,大華才具體知道整個功能,可以如何被開發與各自處理。

三、進行研究(Technical Research)

到目前為止,大華都有比較具體的想法;但他是這幾個月才加入公司,因此過往沒有碰過 i18n 多國語系的設定,因此如何處理資料需要研究。另外因為頁面的版本較舊,但技術主管希望能以新版本 React hook 架構進行開發,並評估把原先的 Redux 拆掉變成 useReducer 和 useContent。
這些技術,剛好都是大華之前不熟悉的應用,因此他便把這些技術列下來:
  • 研究 i18n 架構
  • 研究 i18n 語言判別與更新
  • 研究 React hook 與 Class Component 共存的開發模式
  • 研究 useReducer 與 useContent 取代 Redux 的應用情境。
接著,大華就花了兩個小時研究,把基本需要知道的知識,以及相依的套件都先整理下來。接著,才準備來寫 Code。

適得其反的操作

這時大華的朋友–––小明,看到大華到目前為止,都還沒有開始寫 Code,就好奇問他說:「為什麼你不一邊寫一邊找資料呢?」這樣不是比較快嗎?
大華這時才跟小明說,之前也是看到問題後,就直接開始寫程式。例如看到 i18n,就先跳進去看怎麼寫;看到 useReducer 和 useContent,就跳進去看要怎麼用。
但麻煩的是,i18n 開發到一半,發現現有的邏輯,在部分元件的狀態管理很複雜,但因為已經導入到一半 useReducer,有一些資料流已經拆開。到後面一直來回修修改改,花的時間,反而比預期還要長了一倍,也因此被主管念了一頓。
因此,在實際開始寫程式碼之前,先確認怎麼開始寫、可能遇到的問題有哪些、預計如何處理,才能避免寫到一半出問題;但程式碼與時間成本已經花下去的窘境。

四、寫偽代碼(pseudocode)

Photo by Joshua Aragon on Unsplash
大華將前面的四個步驟,各自寫逐步寫了偽代碼(Pseudocode),來確認邏輯設計沒有問題。隨著時間漸漸接近,也順利把新的頁面成功上架,讓新的品牌聯名大獲成功。但相信到這個階段,還沒有實際展示,偽代碼如何撰寫?要寫到什麼程度?
因此接下來,就以一個題目示範,我們可以如何透過偽代碼來解決問題。筆者選了一題 Leetcode 上的 Array 題型––– 1512. Number of Good Pairs。題目如下:
Given an array of integers nums, return the number of good pairs.
A pair (i, j) is called good if nums[i] == nums[j] and i < j.
Example 1:
Input: nums = [1,2,3,1,1,3]
Output: 4
Explanation: There are 4 good pairs (0,3), (0,4), (3,4), (2,5) 0-indexed.
Example 2:
Input: nums = [1,1,1,1]
Output: 6
Explanation: Each pair in the array are good.
Example 3:
Input: nums = [1,2,3]
Output: 0

如何開始寫 pseudocode?

在開始寫之前,有幾個 pseudocode 的重點需要掌握:
  • pseudocode 的目的在於理解邏輯,程式碼則是讓電腦去跑
  • 盡量不要使用特定語言的寫法,將邏輯寫出來即可
  • 若有邏輯處理,則可使用語句敘述

開始撰寫

以下的寫法並不一定是最佳寫法,而是展現 pseudocode 的撰寫邏輯。
建立函式 goodPair (nums)
// 初始化 goodPair 的數量
// 實例化物件(Map)
// for 0 ~ n (n 是輸入陣列長度)
// if Map 沒有第 n 個元素 then Map key 設定為第 n 個元素,value 為 1
// else (Map 有第 n 個元素)
// goodPair 加上 Map 第 n 個元素的累積值
// 給 Map 第 n 個元素的累積值 + 1

實際成果如下:

var numIdenticalPairs = function (nums) {
let goodPairs = 0;
const hashMap = new Map();

for (let i = 0; i < nums.length; i++) {
if (!hashMap.has(nums[i])) {
hashMap.set(nums[i], 1);
} else {
goodPairs += hashMap.get(nums[i]);
hashMap.set(nums[i], hashMap.get(nums[i]) + 1);
}
}

return goodPairs;
};
另外一個寫偽代碼的優勢,是當我們的資料與預期不符時,更容易 Debug 與對照邏輯。也因此也避免了寫到後面邏輯混亂的狀況。

解決技術問題不在於技術,而在於解決問題

當我們在思考技術問題,總是先停下來,確認我們要解決的是什麼問題?甚至有可能,我們面對到的問題,其實不一定是技術問題。例如行銷後台蒐集的資料非常混亂,常常找不到需要的數據。
可以簡單把他們要的資料抓出來;但會不會其實是,行銷和工程團隊的溝通出現落差,所以每一次開發時,行銷的需求都沒能正確傳達,導致後續的需求都是以 Hot fix 上架,自然而然數據與規劃就會難以維護。
因此,釐清該問題的商業價值,確認真正要解決的問題,接著再以偽代碼確認撰寫邏輯。才能最大程度地避免,我們花了大量時間解決的,其實不是真正重要的問題。

延伸閱讀

為什麼會看到廣告
此處作為整理前端(Frontend)和相關的 HTML、CSS、JavaScript、React 等前端觀念與技巧,全部都會收錄在這個專題之中。同時也會將相關的技術與反思記錄在此,歡迎各位讀者互相交流。
留言0
查看全部
avatar-img
發表第一個留言支持創作者!
在學習寫程式或新技能時,過程一定非常痛苦,更別說能夠利用通勤時間來學習。我在四個月的在職學習期間,累積近 40 個小時的課程時間,超過 300 則的學習筆記。就來看看我是怎麼做到的吧!
在傳統開發的過程中,很容易會搞混一般的 this 和箭頭函式(arrow function)中的 lexcial "this" 兩者的差異。本文就以實際的例子來說明各自的差異,以及在未來使用時需要注意哪一些細節。
在學習寫程式或新技能時,過程一定非常痛苦,更別說能夠利用通勤時間來學習。我在四個月的在職學習期間,累積近 40 個小時的課程時間,超過 300 則的學習筆記。就來看看我是怎麼做到的吧!
在傳統開發的過程中,很容易會搞混一般的 this 和箭頭函式(arrow function)中的 lexcial "this" 兩者的差異。本文就以實際的例子來說明各自的差異,以及在未來使用時需要注意哪一些細節。
你可能也想看
Google News 追蹤
Thumbnail
大家好,我是woody,是一名料理創作者,非常努力地在嘗試將複雜的料理簡單化,讓大家也可以體驗到料理的樂趣而我也非常享受料理的過程,今天想跟大家聊聊,除了料理本身,料理創作背後的成本。
Thumbnail
哈囉~很久沒跟各位自我介紹一下了~ 大家好~我是爺恩 我是一名圖文插畫家,有追蹤我一段時間的應該有發現爺恩這個品牌經營了好像.....快五年了(汗)時間過得真快!隨著時間過去,創作這件事好像變得更忙碌了,也很開心跟很多厲害的創作者以及廠商互相合作幫忙,還有最重要的是大家的支持與陪伴🥹。  
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
許多人都會在遇到需要執行的事情,例如規劃任務、決定行程的時候直接動手進行,直接動手不能說錯,但是會容易失去方向,只知道要做這件事,但是如果不知道為何而做,或如何才能做到面面俱到。而這就有賴於不停地提問,先把問題列出來,用問題導向的方式完成任務,不論是問自己或問屬下,把所提的問題都能回答出來,才能在一
Thumbnail
這本書主要在分享高效率解決問題的方法,在確定問題、分析問題,解決問題的階段,有7個關鍵步驟:找出問題之王、找出關係人、分析問題的現況、明確目標、明確差距與代價、制定方案和行動計劃。
Thumbnail
「大家意見好多...要怎麼找到最佳解法?」 「叫我解決?根本沒想法啊!靈感枯竭啦!」 「難道沒有更好的解決方法嗎?」 「問題到底出在哪!?」 你是不是想找一套方法來解決問題或是構想創新方法呢? 「設計思考」也許就是你積極追求的解答,往下閱讀來初步認識這個新思維!
Thumbnail
一步步每天堅持執行,習慣煉化肌肉記憶,把目標刻在思維裡、通勤中、讀書時、睡夢裡。
Thumbnail
今天和朋友們分享的好書是《你問對問題了嗎?:重組問題框架、精準決策的創新解決工具》作者:湯馬斯‧維戴爾-維德斯柏。作者研究發現,85%的企業表示,經常忙於解決問題,卻不一定是對的問題,因而浪費許多人力物力與金錢。找對問題,才能真正解決問題,問對問題,比答對答案更重要!
Thumbnail
《解決問題的人》這本書是丹尼·沃謝教授所寫,通過豐富的經營案例和不同背景、不同年齡的創業故事,展示了創業的多種可能性和實踐經驗。這本書強調,解決問題不是什麼神秘天賦,而是一種學得會的技巧,這樣的創業思維,也可以應用到日常生活裡,就能在創業和生活中做得更好,甚至實現夢想。
Thumbnail
在《為什麼這樣工作會快、準、好》一書中,作者Charles Duhigg介紹了「工程設計流程(engineering design process)」決策法,這是一套要求人們在解決問題的過程中,需要根據以下幾個步驟:明確界定問題、蒐集資料、提出解決方案、討論選擇並透過持續的實驗找到最好答案。其實這個
Thumbnail
解決問題的藝術:從問題的多面向到解決的巧妙之道 最重要的一點就是深入問題的本質。"一個問題研究到精深,就能出師"。 當我們面對一個問題時,往往會急於尋找解決之道,但這並非有效的方式。問題是多面向的,它們存在著無數的可能性,而我們只是看到了其中的一部分。就像是看到了冰山的一角,而忽略了浸沒在水中的巨大
Thumbnail
如何解決問題 有朋友問我,我輔導了那麼多廠商,是如何解決他們的問題,讓我的文創會員覺得我很有方法解答他們的疑惑?其實,我並沒有太多太好的方法,而是因為同樣的問題碰到許多次,你就會去思考這個問題是如何產生的,那要怎麼解決?有沒有其他的方案?正反兩面去看問題,漸漸地就會有答案出來。 通常,我反而是回
Thumbnail
「問題分析與解決」是經典不敗的職場暢銷課程 但仔細想想有時候「別去解決別人的問題」說不定比解決問題 還要難!
Thumbnail
大家好,我是woody,是一名料理創作者,非常努力地在嘗試將複雜的料理簡單化,讓大家也可以體驗到料理的樂趣而我也非常享受料理的過程,今天想跟大家聊聊,除了料理本身,料理創作背後的成本。
Thumbnail
哈囉~很久沒跟各位自我介紹一下了~ 大家好~我是爺恩 我是一名圖文插畫家,有追蹤我一段時間的應該有發現爺恩這個品牌經營了好像.....快五年了(汗)時間過得真快!隨著時間過去,創作這件事好像變得更忙碌了,也很開心跟很多厲害的創作者以及廠商互相合作幫忙,還有最重要的是大家的支持與陪伴🥹。  
Thumbnail
嘿,大家新年快樂~ 新年大家都在做什麼呢? 跨年夜的我趕工製作某個外包設計案,在工作告一段落時趕上倒數。 然後和兩個小孩過了一個忙亂的元旦。在深夜時刻,看到朋友傳來的解籤網站,興致勃勃熬夜體驗了一下,覺得非常好玩,或許有人玩過了,但還是想寫上來分享紀錄一下~
Thumbnail
許多人都會在遇到需要執行的事情,例如規劃任務、決定行程的時候直接動手進行,直接動手不能說錯,但是會容易失去方向,只知道要做這件事,但是如果不知道為何而做,或如何才能做到面面俱到。而這就有賴於不停地提問,先把問題列出來,用問題導向的方式完成任務,不論是問自己或問屬下,把所提的問題都能回答出來,才能在一
Thumbnail
這本書主要在分享高效率解決問題的方法,在確定問題、分析問題,解決問題的階段,有7個關鍵步驟:找出問題之王、找出關係人、分析問題的現況、明確目標、明確差距與代價、制定方案和行動計劃。
Thumbnail
「大家意見好多...要怎麼找到最佳解法?」 「叫我解決?根本沒想法啊!靈感枯竭啦!」 「難道沒有更好的解決方法嗎?」 「問題到底出在哪!?」 你是不是想找一套方法來解決問題或是構想創新方法呢? 「設計思考」也許就是你積極追求的解答,往下閱讀來初步認識這個新思維!
Thumbnail
一步步每天堅持執行,習慣煉化肌肉記憶,把目標刻在思維裡、通勤中、讀書時、睡夢裡。
Thumbnail
今天和朋友們分享的好書是《你問對問題了嗎?:重組問題框架、精準決策的創新解決工具》作者:湯馬斯‧維戴爾-維德斯柏。作者研究發現,85%的企業表示,經常忙於解決問題,卻不一定是對的問題,因而浪費許多人力物力與金錢。找對問題,才能真正解決問題,問對問題,比答對答案更重要!
Thumbnail
《解決問題的人》這本書是丹尼·沃謝教授所寫,通過豐富的經營案例和不同背景、不同年齡的創業故事,展示了創業的多種可能性和實踐經驗。這本書強調,解決問題不是什麼神秘天賦,而是一種學得會的技巧,這樣的創業思維,也可以應用到日常生活裡,就能在創業和生活中做得更好,甚至實現夢想。
Thumbnail
在《為什麼這樣工作會快、準、好》一書中,作者Charles Duhigg介紹了「工程設計流程(engineering design process)」決策法,這是一套要求人們在解決問題的過程中,需要根據以下幾個步驟:明確界定問題、蒐集資料、提出解決方案、討論選擇並透過持續的實驗找到最好答案。其實這個
Thumbnail
解決問題的藝術:從問題的多面向到解決的巧妙之道 最重要的一點就是深入問題的本質。"一個問題研究到精深,就能出師"。 當我們面對一個問題時,往往會急於尋找解決之道,但這並非有效的方式。問題是多面向的,它們存在著無數的可能性,而我們只是看到了其中的一部分。就像是看到了冰山的一角,而忽略了浸沒在水中的巨大
Thumbnail
如何解決問題 有朋友問我,我輔導了那麼多廠商,是如何解決他們的問題,讓我的文創會員覺得我很有方法解答他們的疑惑?其實,我並沒有太多太好的方法,而是因為同樣的問題碰到許多次,你就會去思考這個問題是如何產生的,那要怎麼解決?有沒有其他的方案?正反兩面去看問題,漸漸地就會有答案出來。 通常,我反而是回
Thumbnail
「問題分析與解決」是經典不敗的職場暢銷課程 但仔細想想有時候「別去解決別人的問題」說不定比解決問題 還要難!