[網文觀點] 李家同先生：不會畫流程圖，就表示他沒有邏輯思考的能力，不可能會寫程式

原文出處： https://goo.gl/UxxUeM

----------（本文開始）----------

前不久拜讀李家同先生的「怪不得很多資訊相關科系的學生不會寫程式」，對於其中他觀察到的現象「某些資訊系畢業生不會寫程式」，肇因於「沒有邏輯思考能力」，最後得出「會畫流程圖才有邏輯能力，才會寫程式」，我一半同意，一半不同意。所以撰文抒發一下我個人的淺見。

根據我自己在電腦補習班教書 30 年的經驗（我從 1989 年開始在電腦補習班執教），我同意「要會寫程式 --> 需要有邏輯能力」這條推論。但「要有邏輯能力 --> 要會畫流程圖」這一條我就不太敢苟同了。

先定義一下「邏輯能力」。我認為的邏輯能力是，遇到一個問題，腦袋能把「先做哪一件事，再做哪一件事」這個順序安排得好。邏輯能力與數學無關。就我看來，我家附近最有邏輯能力的人，是巷口早餐店的掌廚阿姨。大家絡繹不絕的點餐，她還是有辦法指揮廚房內的三名助手：「小A，你先下兩杯冰咖啡...小B，準備好一份切邊土司，兩份漢堡麵包...小C，XX 桌去收一下，然後幫李大哥結帳...」一切有條不紊！這也是程式設計最重要的能力：「把解題步驟有條不紊地依序寫成程式碼」。我覺得她來學程式，一定是會學得很好！

養成「邏輯能力」的方法很多，「畫流程圖」只是其中一種方法。所以「能畫流程圖 --> 有邏輯能力」這條我贊成。但李先生說的「要有邏輯能力 --> 必須要會畫流程圖」這條反過來的推論，我就不贊成了！「能畫流程圖 --> 有邏輯能力」這條，並非「反之亦然」的條件。「有邏輯能力」對應出去的，是個「一對多」的關係。能畫流程圖的人，邏輯能力一定不差，但邏輯能力好的人，不一定會畫流程圖。否則巷口早餐店掌廚阿姨不會畫流程圖，不就成了最沒有邏輯能力的人？（不知道我這樣解釋，大家覺得我的邏輯能力還可以嗎？ XD ）

另一點我不太贊成讓程式初學者去靠「畫流程圖」學會程式邏輯的原因是，業界已經不太要求程式設計師繪製流程圖了。用流程圖來表示程式邏輯，已經是 1980 年代「結構化程式導向」工法那個時期的事情了。進入 1990 年代，程式已經全面改用「物件導向程式設計」工法，「流程圖」裡的那些方塊、菱形，沒有辦法表示出「物件」、「類別」...等這類概念。所以 1990 年代業界提出另一套符號，叫做「UML（Unified Model Language）」圖。用「Use Case」、「Class Diagram」、「Sequence Diagram」...等這幾套符號，全面取代以前的流程圖符號了。想簡單了解 UML 的朋友可以參考這篇文章： https://goo.gl/LTv4fS

時序進入 2000 年代，大家發現「寫程式前先畫流程圖 / UML 圖」這件事是不切實際的。因為 2000 年代的軟體生命週期更短！汰換率比以前更快！已經沒有時間讓程式師慢慢畫流程圖後，才開始寫程式。況且，辛苦畫好的流程圖，會因為修改程式碼但忘了順便修改流程圖，導致流程圖漸漸無法反應現時這套程式的邏輯，而成了廢物。另外，流程圖並非每位新進員工都會，新人訓練還要加上教會他流程圖的各種符號，以便看懂公司內各種文件，C/P 值太低了！所以 2000 年後，資訊業界就不太要求程式師用流程圖或 UML 圖，來表示程式邏輯了。

那現在資訊業界用什麼方法表示程式邏輯呢？最簡單的方法：用文字條列。把一小段的程式該做哪些事情，一條條列出來，簡單描述即可。把該做的事情用文字條列，人人都不用特別學習另一套符號，成本超低！也能表現出程式邏輯（其實流程圖要表示的，不就是程式邏輯嗎？用文字表示效果一樣）。甚至於還能把這些條列文字，用「註解」的方式，寫入原始碼中。這樣修改原始碼，就會順便修改註解，保持「邏輯」與「原始碼」同步。如果你想把程式邏輯從註解抽出來變成文件，用特殊軟體抽出註解、拋棄原始碼就行了。業界最出名的這類抽取註解變文件的工具，有 JavaDoc（這部影片有示範 JavaDoc 抽出來的註解可以變成多精美的文件： https://youtu.be/Ls-NHebXY20 ）。正因為用的是最簡單的「文字」，才能輕易地把程式邏輯內嵌在原始碼中。如果是圖形，那就辦不到了。

如果你真的要用圖形表示程式邏輯，業界現在流行「直接把操作介面畫出來」。不用畫得很精緻，用一些方框代表「這裡是文字框、這裡是確定鈕」即可。這類手法，稱為「Wireframe」。這邊有一篇 Wireframe 的中文說明： https://goo.gl/KIrq0Y 。用 Wireframe，不僅好學（基本上沒有特定規則，看得懂就好），畫出來也可以分享給客戶，示範我們會怎麼幫他設計他想要的程式，而不用擔心客戶看不懂流程圖。更適合用來表達 1990 年代後期興起的「圖形使用者介面（GUI, Graphical User Interface）」。流程圖某種情況下，只適合表示 1980 年代那種「文字式介面」的需求了。

那為什麼現今資訊系畢業的學生，不會寫程式的比例變多了呢？事實上，是現在資訊系學生要學的東西變多了。所以分配到每一樣的「練習」變少，就變成「樣樣通、樣樣鬆」了。光學完理論，還來不及實作，就被逼著去學下一項。就像剛考上普通駕照，沒時間給他道路駕駛，然後逼著他又去考職業駕照、大客車駕照、連結車駕照，再來感嘆：「現在年輕人道路駕駛變差了」。我開始學程式設計的時間，應該只比李家同先生晚一點，大概都是 1980 年代前後。那時候，只要學會 C 語言，加上資料結構、演算法，人家就虎視眈眈地問你什麼時候畢業、能去他們公司工作了。沒有 GUI、沒有網頁程式設計、沒有手機程式設計、沒有大數據...通．通．都．沒．有！所以，不太會寫程式的原因，是「練習不夠」，而「邏輯能力」就是靠大量實作練出來的。因此，真正的因果關係，我認為是「學習項目太多 --> 實作練習不足 --> 邏輯能力無法提昇 --> 寫程式時腦袋一片空白 --> 被人家說不會寫程式」。真正解藥是：「專注一項，多多實作練習」。你至少要把一種語言練到精通，養出基本的程式撰寫邏輯後，再去跳其他語言。這樣就不會「樣樣通、樣樣鬆」了（我個人的基本功底，是 C 與 Java。兩種語言我都練到真的很強！學新語言，我都會去找對照關係：這個語法對應到 C/Java 的哪一種，來加速學習）。

最後讓我重述一下我的觀點：我不反對用繪製流程圖來訓練邏輯能力，但說訓練邏輯能力，一定要會流程圖，這件事情我不贊同。天底下還有比流程圖更簡單、也能訓練邏輯能力的方法。千萬不要認為「流程圖」是訓練邏輯能力的唯一方法就行了。

啊！對了！麻煩不要拿著我這篇文章貼到李家同先生的網誌去戰人家。您可以兩篇文章都看，甚至選擇不同意我說的論點。李先生是我們這行的大前輩，我個人還是蠻尊敬他的。

[網文觀點] 李家同先生：不會畫流程圖，就表示他沒有邏輯思考的能力，不可能會寫程式

原文出處： https://goo.gl/UxxUeM

-\-\-\-\-\-\-\-\-\-\（本文開始）-\-\-\-\-\-\-\-\-\-\

前不久拜讀李家同先生的「怪不得很多資訊相關科系的學生不會寫程式」，對於其中他觀察到的現象「某些資訊系畢業生不會寫程式」，肇因於「沒有邏輯思考能力」，最後得出「會畫流程圖才有邏輯能力，才會寫程式」，我一半同意，一半不同意。所以撰文抒發一下我個人的淺見。

根據我自己在電腦補習班教書 30 年的經驗（我從 1989 年開始在電腦補習班執教），我同意「要會寫程式 -\-\> 需要有邏輯能力」這條推論。但「要有邏輯能力 -\-\> 要會畫流程圖」這一條我就不太敢苟同了。

先定義一下「邏輯能力」。我認為的邏輯能力是，遇到一個問題，腦袋能把「先做哪一件事，再做哪一件事」這個順序安排得好。邏輯能力與數學無關。就我看來，我家附近最有邏輯能力的人，是巷口早餐店的掌廚阿姨。大家絡繹不絕的點餐，她還是有辦法指揮廚房內的三名助手：「小A，你先下兩杯冰咖啡...小B，準備好一份切邊土司，兩份漢堡麵包...小C，XX 桌去收一下，然後幫李大哥結帳...」一切有條不紊！這也是程式設計最重要的能力：「把解題步驟有條不紊地依序寫成程式碼」。我覺得她來學程式，一定是會學得很好！

養成「邏輯能力」的方法很多，「畫流程圖」只是其中一種方法。所以「能畫流程圖 -\-\> 有邏輯能力」這條我贊成。但李先生說的「要有邏輯能力 -\-\> 必須要會畫流程圖」這條反過來的推論，我就不贊成了！「能畫流程圖 -\-\> 有邏輯能力」這條，並非「反之亦然」的條件。「有邏輯能力」對應出去的，是個「一對多」的關係。能畫流程圖的人，邏輯能力一定不差，但邏輯能力好的人，不一定會畫流程圖。否則巷口早餐店掌廚阿姨不會畫流程圖，不就成了最沒有邏輯能力的人？（不知道我這樣解釋，大家覺得我的邏輯能力還可以嗎？ XD ）

另一點我不太贊成讓程式初學者去靠「畫流程圖」學會程式邏輯的原因是，業界已經不太要求程式設計師繪製流程圖了。用流程圖來表示程式邏輯，已經是 1980 年代「結構化程式導向」工法那個時期的事情了。進入 1990 年代，程式已經全面改用「物件導向程式設計」工法，「流程圖」裡的那些方塊、菱形，沒有辦法表示出「物件」、「類別」...等這類概念。所以 1990 年代業界提出另一套符號，叫做「UML（Unified Model Language）」圖。用「Use Case」、「Class Diagram」、「Sequence Diagram」...等這幾套符號，全面取代以前的流程圖符號了。想簡單了解 UML 的朋友可以參考這篇文章： https://goo.gl/LTv4fS

時序進入 2000 年代，大家發現「寫程式前先畫流程圖 / UML 圖」這件事是不切實際的。因為 2000 年代的軟體生命週期更短！汰換率比以前更快！已經沒有時間讓程式師慢慢畫流程圖後，才開始寫程式。況且，辛苦畫好的流程圖，會因為修改程式碼但忘了順便修改流程圖，導致流程圖漸漸無法反應現時這套程式的邏輯，而成了廢物。另外，流程圖並非每位新進員工都會，新人訓練還要加上教會他流程圖的各種符號，以便看懂公司內各種文件，C/P 值太低了！所以 2000 年後，資訊業界就不太要求程式師用流程圖或 UML 圖，來表示程式邏輯了。

那現在資訊業界用什麼方法表示程式邏輯呢？最簡單的方法：用文字條列。把一小段的程式該做哪些事情，一條條列出來，簡單描述即可。把該做的事情用文字條列，人人都不用特別學習另一套符號，成本超低！也能表現出程式邏輯（其實流程圖要表示的，不就是程式邏輯嗎？用文字表示效果一樣）。甚至於還能把這些條列文字，用「註解」的方式，寫入原始碼中。這樣修改原始碼，就會順便修改註解，保持「邏輯」與「原始碼」同步。如果你想把程式邏輯從註解抽出來變成文件，用特殊軟體抽出註解、拋棄原始碼就行了。業界最出名的這類抽取註解變文件的工具，有 JavaDoc（這部影片有示範 JavaDoc 抽出來的註解可以變成多精美的文件： https://youtu.be/Ls-NHebXY20 ）。正因為用的是最簡單的「文字」，才能輕易地把程式邏輯內嵌在原始碼中。如果是圖形，那就辦不到了。

如果你真的要用圖形表示程式邏輯，業界現在流行「直接把操作介面畫出來」。不用畫得很精緻，用一些方框代表「這裡是文字框、這裡是確定鈕」即可。這類手法，稱為「Wireframe」。這邊有一篇 Wireframe 的中文說明： https://goo.gl/KIrq0Y 。用 Wireframe，不僅好學（基本上沒有特定規則，看得懂就好），畫出來也可以分享給客戶，示範我們會怎麼幫他設計他想要的程式，而不用擔心客戶看不懂流程圖。更適合用來表達 1990 年代後期興起的「圖形使用者介面（GUI, Graphical User Interface）」。流程圖某種情況下，只適合表示 1980 年代那種「文字式介面」的需求了。

那為什麼現今資訊系畢業的學生，不會寫程式的比例變多了呢？事實上，是現在資訊系學生要學的東西變多了。所以分配到每一樣的「練習」變少，就變成「樣樣通、樣樣鬆」了。光學完理論，還來不及實作，就被逼著去學下一項。就像剛考上普通駕照，沒時間給他道路駕駛，然後逼著他又去考職業駕照、大客車駕照、連結車駕照，再來感嘆：「現在年輕人道路駕駛變差了」。我開始學程式設計的時間，應該只比李家同先生晚一點，大概都是 1980 年代前後。那時候，只要學會 C 語言，加上資料結構、演算法，人家就虎視眈眈地問你什麼時候畢業、能去他們公司工作了。沒有 GUI、沒有網頁程式設計、沒有手機程式設計、沒有大數據...通．通．都．沒．有！所以，不太會寫程式的原因，是「練習不夠」，而「邏輯能力」就是靠大量實作練出來的。因此，真正的因果關係，我認為是「學習項目太多 -\-\> 實作練習不足 -\-\> 邏輯能力無法提昇 -\-\> 寫程式時腦袋一片空白 -\-\> 被人家說不會寫程式」。真正解藥是：「專注一項，多多實作練習」。你至少要把一種語言練到精通，養出基本的程式撰寫邏輯後，再去跳其他語言。這樣就不會「樣樣通、樣樣鬆」了（我個人的基本功底，是 C 與 Java。兩種語言我都練到真的很強！學新語言，我都會去找對照關係：這個語法對應到 C/Java 的哪一種，來加速學習）。

最後讓我重述一下我的觀點：我不反對用繪製流程圖來訓練邏輯能力，但說訓練邏輯能力，一定要會流程圖，這件事情我不贊同。天底下還有比流程圖更簡單、也能訓練邏輯能力的方法。千萬不要認為「流程圖」是訓練邏輯能力的唯一方法就行了。

啊！對了！麻煩不要拿著我這篇文章貼到李家同先生的網誌去戰人家。您可以兩篇文章都看，甚至選擇不同意我說的論點。李先生是我們這行的大前輩，我個人還是蠻尊敬他的。

[軟體工程] 設計一個大系統應該遵循什麼步驟？有哪些要注意的地方？

「系統設計備忘錄（System Design Cheatsheet）」
https://goo.gl/FcuIqo
#SoftwareEngeineering #SystemDesign #Cheatsheet

常有「突然」當上小主管、或者被要求「帶 Team」的朋友問：「設計一個大系統，有沒有步驟可以遵循？」或者「設計大系統時，有沒有哪些一定要考量的地方？」您需要的是「軟體工程」相關的知識。可是軟體工程的書厚達上千頁，我們家的「慣老闆」（笑）要求我下週提個計畫給他耶！怎麼辦？有沒有速成的方法？今天介紹的網頁，可以稍稍解決您這部份的痛苦。

我簡單不負責任翻譯一下騙讚...不是，方便英文苦手的朋友參考好了 XD：

一、系統設計基本五步驟
1. 明訂系統目標（System Scope），並取得客戶同意。設計內容包含：
(1) 收集客戶使用案例（User Cases）/ 使用情境
(2) 明訂系統承載上限（網路流量、同時登入人數、記憶體限制...）

2. 系統概念設計（High Level Design）
(1) 一般會設計到包含哪些系統元件。
(2) 至於系統元件在此步驟就當成黑盒子，直到下一步才做細部設計。

3. 系統元件細部設計（Component Design）
(1) 特定軟體元件內部設計
(2) 供外部呼叫用的 API 設計
(3) 設計該包含哪些物件，並指定每個物件的功能。
(4) 資料庫架構設計

4. 了解瓶頸所在
(1) 根據「需求」與「架構」，預先猜測壓力最大的元件（如：CPU 速度、資料庫速度...）
(2) 如何修改架構、紓緩瓶頸，以求達到客戶需求，則交由下一步驟來做。

5. 增刪系統架構與設計（Scaling）
(1) 是否應該增加硬體速度與規格（Vertical Scaling）？或者該多買幾台，平行運作（Horizontal Scaling）？
(2) 快取（Cache）是否足夠？
(3) 是否要「平衡負載（Load Balancing）」機制？
(4) 資料庫切分、抄寫、備份考量
(5) 是否應該用「多重軟體層（Multi-layers）」來分散負重、加快效能？

二、系統設計考量關鍵
1. 並行處理（Concurrency）
2. 網路（Networking）
3. 各軟體層職責分明（Clarify each Abstraction Layer）
4. 實際效能優劣（Real-world Performance）
5. 估算（Estimation）
6. 在線率（Availability，如：保證 99.99% 的在線時間）與可靠度

三、網頁系統設計考量關鍵
1. 資訊安全考量（Security）
2. 如何受益於全球各地的快取伺服器（CDN），將客戶等待時間降至最低
3. 全文檢索機制
4. 有沒有離線支援
5. 是否需要背景執行的程式（Web Worker）
6. 後台語言的選用（Server Side Rendering，如：PHP？ASP.NET？）
7. 非同步載入（在你不用網頁資源時，偷偷預先載入待會可能用得上的東西）
8. 如何最小化網路負載
9. 開發工具選用
10. 是否針對聽障、視障人士，提供友善存取網頁內容的方法（Accessibility）
11. 是否提供多國語系（Internationalization）？
12. 是否在不同寬度的螢幕（電腦、平板、手機），提供不同的版型，以便舒適閱讀（響應式設計，Responsive design）？
13. 是否能相容於不同的瀏覽器（IE、Firefox、Chrome、Safari、Opera...）

四、網頁前台架構開發相關元素
1. 原始碼（Code）本身
2. 文件（Documentation）
3. 測試機制的設計（Testing）
4. 開發流程（Process）注意事項
(1) 版本控制（如：使用 Git 工具）
(2) 元件相依管理（如：npm, Bundler, Bower）
(3) 自動化建構工具（如：Grunt/Gulp）
(4) 系統建置與導入流程（如：Docker）
(5) 持續整合工具（如：Travis CI, Jenkins）

（喘...）哈哈！有不少名詞礙於篇幅限制，我沒在這裡解釋得很清楚。如果您有什麼問題，不用客氣留言在下面給我喔！今天的分享希望各位喜歡，也祝福大家有個美好的週末！還請大家多多按讚鼓勵，或者分享給您臉書上的好友喔！