AppWorks School Batch #16 Front-End Class 學習筆記&心得（Week 17）

（本文所有內容禁止媒體引用）

進入個人專案最後一個短衝（sprint），歷經跟同學互相測試，才發現原來不管是使用者介面（user interface, UI）或使用者體驗（user experience, UX）都一堆待改善處，於是又開始了漫漫的除蟲之路...

取自 AppWorks School 前端班課程大綱

短衝四回顧

跟前三次的專案演示（demo）比起來，這次相對正式了些，週一兩個手機班先一起進行、週二再輪到前端+後端+資料工程班。因為是跨班報告，我再度特別擬定了講稿，週一幾乎花一整天在練習，讓整體的流程順暢、報告時不出現贅字，且能在規定的三分鐘內完整講完。

本次演示大部分的校務與導師也都在場，校長 Shirney 強調下列三個重點：

1. 作品中的模擬資料要充足且擬真，不應出現 test123 等測試文字。
2. 瀏覽器上個人化的書籤宜隱藏。
3. 作品要具備自我解釋的能力，讓第一次使用的人也能有順暢的體驗。

這其實呼應了個人專案階段最開始講的「不能看起來像作業」，因為是要拿出去給廠商看的，呈現起來要有專業感，足以說服別人「我的作品很有水準」。

前兩點相對容易自己處理，但要驗證第三點，就有賴第一次使用的人親自分享心得。於是，我們進入互相玩對方專案的「測試」環節，透過同學之間互相體驗彼此的作品，才能夠找出自己不管怎麼玩都不會發現的盲點，許多不順暢的 UX 都是這樣發現的，而這些缺點通通都會寫入待改善清單，可以把握最後一週期的短衝慢慢修。

進行個人專案首次測試

本次的「回顧會議（retrospective meeting）」也與以往不同，改為探討下列四點：

1. 有什麼推著我們向前？
2. 有什麼事情讓我們開心？
3. 有什麼是我們前進的阻力？
4. 針對新一週期的短衝，是否有什麼潛在風險？

短衝四「回顧會議（retrospective meeting）」討論看板

個人專案進行到現在已經過了一個月，是個相對於其他階段更漫長且煩悶的過程，這時一定要找到一些樂子、還有那些推著我們向前的動力。這種感覺非常像是在準備大考，在最開始唸書時總是動力滿滿，隨著過程中遇到許多可預期與不可預期的阻礙，衝勁會逐漸減弱，尤其到了考前數天，最容易彈性疲乏，但若開始出現放鬆、擺爛念頭，就等於前功盡棄，因此，維持穩定的前進步調是相當重要的，尤其現在已經不是在準備期末考、考完就沒事，要隨時讓自己持續成長，才得以適應不斷變化的大環境。

個人專案－短衝五

短衝五的目標是解決上述測試階段發現的問題，以會造成網站當機的錯誤為優先處理項目，接著是提升作品的自我解釋能力、讓使用者體驗更為順暢，還有優化使用者介面與響應式網頁的畫面設計。

我的專案問題多半為使用者介面設計，使用者流程雖因在上個短衝新增使用者故事而略為不順，但測試起來並沒有太大的問題，因此，本週短衝在簡單優化完使用者流程後，主要是把所有的畫面重新切版，讓網站文字不要過大、並把看起來與主題關聯性較低、可有可無的項目移除。

調整後的首頁畫面

週五主題短講：作業系統

本次的主題短講內容是「作業系統」，是資工系必修、資工領域相關研究所必考科目之一，其重要性可見一斑。

什麼是「作業系統」？

電腦、手機等裝置的實體構造稱為「硬體」，我們使用的瀏覽器、資料庫等各類應用程式皆是「軟體」，而「作業系統」的主要功能就是調控硬體資源，供軟體使用，簡單來說，就是進行「資源管理」。

目前市面上常見的作業系統共有五個，分別是微軟的 Windows、蘋果的 Mac OS、企鵝 Linux、蘋果手機的 iOS 與非蘋果手機的 Android，而這當中，開源的 Linux 是作業系統課程主要介紹對象，由林納斯·托瓦茲（Linus Torvalds）於 1991 年發明，他也是 Git 的發明者，可不是袁宗南在三立政論節目上說的「林姓商人」。

話說，林納斯的出生地是芬蘭赫爾辛基，發明 Linux 時就讀的是赫爾辛基大學，其 1997 年發表的碩士論文《Linux: A Portable Operating System》就是在赫大出版，看到時還真不免有些親切感，沒想到芬蘭在電腦科學領域也有如此劃時代的一筆。

作業系統：夾在硬體與軟體之間，負責「資源管理」。

行程／程序（process）

電腦並不能理解我們透過 C、C++、Java 等高階程式語言寫的程式碼，需要經過編譯器（compiler）將其轉為只有 0 和 1 的二進制機器語言（machine code）。位在硬碟中、未執行的機器語言稱為「被動實體（passive entity）」，而當這些程式碼要執行時，作業系統會將機器語言載到記憶體中，並妥善分配記憶體中的資源。

程式（program）：在硬碟中以二進制儲存的被動實體。
行程／程序（process）：在記憶體中執行的活動實體。

當這些在記憶體內的機器語言開始於中央處理器（CPU）的寄存器（register）執行時，就成了「活動實體（active entity）」，也就是「行程／程序（process）」，在行程中執行的單位稱為「執行緒（thread）」。

在「單執行緒（single-threaded）」程式語言中，一個行程只能跑一個執行緒，必須等前一個任務處理完才能處理下一個任務，現今如 Java、C# 等程式語言則為「多執行緒（multi-threaded）」，同一個行程中可以跑多個執行緒，有助於提高記憶體的使用效率。

「單執行緒」與「多執行緒」比較圖

執行緒：行程中執行的單位。
單執行緒：同一行程中，一次只能做一件事。
多執行緒：同一行程中，可同步處理多個任務。

比較特別的是，寫網頁常用的 JavaScript 是「單執行緒」程式語言，但若遇到 AJAX (XMLHttpRequest)、window.setTimeout()、window.addEventListener() 這類非同步的程式碼，就會先丟給瀏覽器的 Web API 處理，JavaScript 自己的呼叫堆疊（call stack）則持續往下執行，並不會因為遇到需要一段等待時間的程式碼就卡住（blocking），看起來仍有「非同步」的效果。

Web API 將非同步程式執行完畢時，會將其放到事件佇列（event queue）裡，由事件循環（event loop）觀察目前呼叫堆疊是否為空，若已清空，則依照「先進先出」原則，將佇列中的代辦任務放回呼叫堆疊中執行。

JavaScript為單執行緒語言，但透過Web API、事件佇列與事件循環機制，依舊可以處理非同步運算。

行程狀態（process state）

當程式開始執行、成為「行程（process）」時，會改變「狀態（state）」，反應著該行程目前正處於哪一個活動階段。狀態共有下列五種：

1. new：行程剛被創立。
2. ready：行程被創立後、開始執行前，被放到處理器中，準備執行。
3. running：行程執行中，一個處理器同一時間只能讓一個行程處於此狀態。
4. waiting：行程等待某件事情（如特定的輸入、輸出）處理完畢中。
5. terminated：行程執行完畢。

在正常情況下，行程會依序走 new → ready → running → terminated 四種狀態，但在 running 階段，還可能出現兩種狀況：

1. 干擾（interrupt）：CPU 被搶走，狀態回到 ready。
2. 有輸入、輸出等事件：因為較為耗時，會進入 waiting 狀態，把 CPU 讓給其他行程使用，事件處理完畢後回到 ready。

行程狀態圖（process state diagram）

每一個行程相關的資訊都會被存在過程控制段（process control block, PCB）內，包含號碼（number）、狀態（state）、計數器（counter）、暫存器（register）、記憶體管理等，而 CPU 要決定哪個行程先被執行，則有賴「行程管理（process scheduling）」。

行程狀態：包含new、ready、running、waiting、terminated五種。
過程控制段(PCB)：存取所有行程相關資訊。

行程管理（process scheduling）

行程管理同樣為 PCB 的儲存項目之一，由行程管理器（process scheduler）執行，根據各類演算法，決定 CPU 處理各行程的優先順序，其目的有二：

1. 多元程式（multiprogramming）：讓 CPU 永遠有行程可以處理，使 CPU 使用率最大化。
2. 分時系統（time sharing）：讓 CPU 快速在不同行程中轉換，讓使用者可以「感覺」同時在處理不同工作項目。例如當我們一邊打文件、一邊聽音樂，CPU 並不是同時幫我們處理打文件跟聽音樂兩種工作，而是一次做一件、但用極短的時間在兩者間切換，讓我們感覺兩件事情是同時發生。

當行程抵達系統時，會先進入「工作佇列（job queue）」中，裡面包含所有系統內的行程；當行程準備好時，便會進入「就緒佇列（ready queue）」，此時的行程皆已抵達主要記憶體中，只要拿到 CPU 就能開始執行。

行程管理的演算法非常多樣，而要評估、比較這些演算法，共有下列準則要考量：

1. CPU 使用率（CPU utilization）：讓 CPU 越忙碌越好。
2. 產能／流通量（throughput）：每單位時間內 CPU 完成的行程數。
3. 等待時間（waiting time）：行程在「就緒佇列（ready queue）」中的等待時間。
4. 完成時間（turnaround time）：行程提交（submit）到全部完成的時間，包含等待、執行與過程中輸入、輸出的時間。
5. 回應時間（response time）：行程提交（submit）到拿到第一個回應的時間。
6. 公平性（fairness）：對於處裡每個行程的公平性。

常見的行程管理演算法包含：

1. 先到先服務（first come, first served, FCFS）：即「佇列（queue）」基本概念，不論每個行程的執行時間是多久，都是先到先處理。
2. 最短優先（shortest job first, SJF）：等待時間最短者優先處理，雖可減少所有行程的平均等待時間，但執行時間較長的行程可能一直被較晚進來、但執行時間短的插隊，最終一直等不到被處裡的機會，此現象稱為「飢餓（starvation）」，可用「變老（aging）」方式處理，讓越早抵達的行程具有越高的權重，解決不公平的問題。
3. 最短剩下時間優先（shortest remaining time first, SRTF）：每單位時間都取當下剩下處理時間最短的行程優先處理，因為新行程可能在前一個行程還沒處理完就先佔用 CPU 資源，屬於「佔先式（preemptive）」。

行程管理目的：多元程式、分時系統。
行程管理演算法評估準則：CPU使用率、產能、等待時間、完成時間、回應時間、公平性。
行程管理演算法：先到先服務(FCFS)、最短優先(SJF)、最短剩下時間優先(SRTF)等。

上下文交換／環境切換（context switch）

以上述的「最短剩下時間優先（SRTF）」演算法為例，CPU 要頻繁在不同行程間切換，切換時要記錄下列兩種資訊：

1. 前一個行程當前狀態。
2. 新行程準備執行時的狀態。

用生活化的方式理解就是：假設我們正在看書（舊行程），此時媽媽突然叫我們幫忙做一件家事（新行程），我們會在書本中放入書籤，標示目前讀到的頁數，以便做完家事後可以銜接上次的進度往下看，此外還要先知道家事要從哪開始做，「放入書籤」與「知道家事進度」這兩個過程就是「上下文交換（context switch）」。

只要狀態進入或離開 running 狀態都會產生上下文交換，在這期間，CPU 並未執行任何行程，屬於一種無用的開銷（overhead），而執行緒（thread）可以達成部分資源共享，讓上下文交換的內容減少，提高 CPU 的使用率。

上下文交換：CPU在不同行程間切換時，要記錄原行程當前狀態、與新行程待處理時狀態。

死結／死鎖（deadlock）

若有兩個以上運算單元需要共享資源以完成任務，但各自都只取得資源的其中一部份，雙方都在等待對方完成工作、將資源釋出，偏偏雙方都因為無法取得完整資源而無法完成工作，形成互不相讓的僵局，這就是「死結（deadlock）」。

死結（deadlock）示意圖

死結：兩個以上的運算單位都在等對方釋出資源而皆無法執行任務。

競爭條件／競爭危害（race condition / race hazard）

執行緒（thread）之間要互相溝通，可以透過「共享內存（memory sharing）」或「訊息傳遞（message passing）」兩種方式。

在可搶奪 CPU 資源的「佔先式（preemptive）」演算法中，若使用「共享內存」方式，則可能出現不同執行緒在同一時間針對同一記憶體的內容進行更動，造成最終結果有時正確、有時錯誤。

競爭條件：共享內存時，不同執行緒在同一時間針對同一記憶體內容進行更動。

心得

隨著個人專案階段進入尾聲，演示環節變得越來越正式，隔週甚至還要錄影，在感謝 School 提供這麼豐沛的資源之餘，也不免感受到越來越大的壓力。

本週的演示有機會觀摩後端與資料班同學的作品，不得不說，有些人的作品真的很神，其展現之複雜程度總讓我不禁好奇「這到底是怎麼做到的？」，即便是同為前端班的同學，不管是使用者介面的精緻度、或者核心功能的難度，都讓我十分驚豔！還記得近一個月前，大家都還只是在摸索功能、完全沒有任何的使用者介面設計，連自己能不能把構想實現都不知道，但現在已經出現那些看來跟歷屆學長姐作品一樣讓人看了會眼睛發亮、大喊好幾聲「哇塞！」的成果，即便在測試階段抓到許多待改善項目，經過最後一個短衝的修正，相信最終的成品都是令人期待的。

這星期最享受的是由小賴老師帶來的週五短講。作業系統是我在準備研究所考試時，最沒有頭緒的科目，打開大家很推薦的清大開放式課程，卻是一個字也聽不懂，但週五上午經過這一個多小時的介紹，我居然可以理解什麼是「行程（process）」與「執行緒（thread）」，還有辦法自行解釋，再打開清大課程等線上學習資源，我！聽！懂！了！這是個神奇的時刻，我突然醉心於認識作業系統那些曾讓我一頭霧水的理論，不過這畢竟不是當務之急，還是等個人專案結束之後再找時間慢慢研讀。

記得不久前才看到第 15 屆學員進行最終的個人專案演示，沒想到這麼快也要輪到我們了！感覺有些期待、又有些緊張。再五個星期就要畢業，其實就跟個人專案的時長一樣，說長不長、說短不短。這禮拜剛好畢業神曲《風箏》的十週年復刻版上線，五天將近 25 萬的點閱率我大概就貢獻了其中 200 次以上。畢業那一天通常是值得期待的，但在那之前，最重要的是持續努力、穩定向前，不要辜負每一天的自己。

參考資料

1. 10501 資訊工程學系 作業系統－國立清華大學
2. Operating System - Neso Academy
3. Operating Systems - GeeksforGeeks
4. 【筆記】到底 Event Loop 關我啥事？ －郭耿綸 Kaleb