※ 引述《csjs87 (思念的季節)》之銘言：
: 各位年薪三百萬的大神們好，小弟不才又上來請益了。一年前為了選擇資策會的課程在版上發了問，有幸獲得許多人的回覆。
: 從資策會畢業、順利找到工作也一陣子了，現在月薪37k，主要是協助開發後端。但我碰到一些對於自己不足的地方，想再次請教各位。
恭禧轉職成功 :D
: 一、
: 因為公司沒有一套完整的教育訓練或是架構的教學，所以即使我有嘗試在我負責做的小工具、api中盡量使用"我認為的oop觀念"、"solid的開發原則"。但還是不曉得是否正確，同事們大多也都很資淺，加上沒有太多時間幫我看（專案忙）。我要怎麼檢視自己的code是良好、容易維護的呢？
大部分都是如此，但不用灰心。因為，過去接受訓練的型式，
常讓我們以為有替一些人排好課表、找幾個固定的主講人，
拿著講義坐下來好好聽課才算是教學或者訓練。
有些公司比較有機會做到這種典型的課程式教育訓練，
即使公司的大小有關係，但主要還是公司主要用到的技術的範圍
這些範圍內的東西，依產業或職位不同，變化的速度也不同。
若是沒幾個月就變了一輪，那麼做個制式的訓練教材就是不划算的事了
若東西一直沒變，那就可能是所以 tech stack 都鎖定了
像一些會被嚴格稽核的金融系統會有這樣的特性。
(舉金融為例，不代表它全都如此，金融也是一直導入新技術的。)
多數的公司在這二個極端之間，
所以特別準備通用的教育訓練就不那麼容易了。
在沒有固定模式的訓練材料，大致會怎麼訓練人呢？
大多是以處理 issue 跟參與 pair programming 為主。
issue 以特定 bug 並明確是 reproducible 為佳，
因為只要學會如何啟動系統，能開 debugger 來看問題為主
(或是硬加 log message 來用)
(或運氣好，已有 unit test 基礎建設)
在 trace 的過程中，你可以漸漸理解正在開發、維運的東西怎麼工作的
若是公司沒有教材，你就有機會成為生出教材的那個人
像是你可以用 sequence diagram 來表達從啟動到結束需要經過哪些
大小元件或 method call。你可以有不同粒度的版本。
或是 component diagram 來表達幾個大元件的依存關係。
做好後，拿著它與其他同事解說，請他們給你 feedback
你可以觀察並意識到，自己哪些部分理解了，哪些部分誤解了。
而誤解的原因是單純看錯了，還是缺乏了某個基礎知識，
或是過去人為決定的設計，讓你無法以目前的直覺適當地理解它。
這樣互動並修正自我認知的流程才是真正的學習。
由其他的的回饋，你可以知道自己說出來的東西，是否跟別人的理解相同了。
這樣漸漸你可以內化這些知識，成為理解你工作領域的人。
: 二、
: 偶爾會看版上或是104徵才需要什麼樣的能力，為將來不管跳槽或是談薪水更有籌碼。我印象中常看到的有雲端架設相關（aws、azure）、程式設計上（單元測試、graph api）、其他（CI/CD、Docker容器、TDD）。雖然都有查過也大致知道是什麼，但也僅此而已，更不曉得知識還很淺薄的我有沒有誤會什麼。
這些都是好東西，但你得有基礎概念輔助才行。
基礎概念包含『三』的部分，但遠比『三』本身更多，因為所列的這些工具
還包含了方法論、哲學觀與工作文化的轉變，如果你沒有吸收到相關 mindset
那你只是單純學習了新的工具而已。
你其實該在意的是，如果我會 OOO，那麼在 XXX 的時機適不適合。
在工作流程中，引入了 OOO 後，對於所處的工作環境是否有好的影響
基於 XXX 的概念準則，為什麼 YYY 是個好/壞主意。
其實蠻多社群都有相關的 talk，或上 youtube 找相關影片看。
多跟人互動，理解他們為什麼選擇，站在什麼樣的視角去做選擇
比單純像集點一樣，把工具集一輪有用得多了。
: 三、
: 最後是一些比較底層的資料結構、計算機概論這類都幾乎是0知識。雖然計概有自己看台大開放課程的計算機概論，是多少有學到一些，但又好像不是我現在急迫必要的知識。聽說資工有本聖經恐龍本，看過目錄發現，很多都是我常常看到的陌生詞彙。I/O、thread、Process等等，我覺得好像不看懂這些我就很難更精進。
OS 部分，其實沒有離這麼遠。但是直接看教科書挺硬的。
至少 process 與 thread 對應到你使用的語言、工具時相關問題要理解。
像是怎麼處理 race condition 的問題
(其實第 0 步是，培養識別 race conditon 的眼光)
在沒學習之前，應該要有的敏感度是：
『這程式，有時候會對，有時候有不對。沒什麼特別的規律』
那麼對應到語言的層次，大部是使用 thread 後出了問題。
你會開始在意到你的資料是否得在 mutlithread 下共用，
開始關心 library 有沒有標示 thread-safe。
再進一步，怎麼寫出 thread-safe 的共用元件，
(像是多數支援 multithread 的語言都有的 volatile 關鍵字)
(它影響者你 shared variable 的 visibility)
或是走向 immutable object 與 functional programming
等避免狀態改變造成的困擾。
另外，資料結構算 Big-O 不會算沒關係，大多的複雜度都查得到。
(至少寫了幾層 loop 這種 N*M 要看得出來)
它是用來協助我們處理選擇障礙與實作優化的幫手。
像是你要在一堆資料中，找 1 個東西存不存在，並取得對應的值：
在 List 與 Set 中選擇，你對照一下時間複雜度，應該是內心有譜的。
像有些給入行工程師的考題，都喜歡考你某 2 個容器的實作，
為什麼選 A 而不選 B，若題目改成 ..... 那麼選 B 就是比 A 更好
這也是為什麼資料結構能處理許多選擇障礙的問題
另一種情境是優化，你手上有個已經實作的好成品，它是用某個資料結構
你要試著去安排你的資料，以發揮這個資料結構的特性，獲得較好的結果。
(這是常見的資料庫的 indexing 的問題了，
如果某些大大有開課的話，快去搶票先)
: 其實我本身不是“非常”熱愛寫程式的人，我會在寫code的時候為解出bug感到開心，也會邊騎車邊想程式的事，看到好像很神奇的新技術新聞也會很興奮，也想做side project，想使用新知識。但到了休假日，也很少真的著手進行。
: 總之我現在稍微有點迷惘，對於程式這條路我覺得我才剛起步，也不想離開。但學海無涯，光上面就太多東西要學。
: 根據我自己的感覺，只知道自己暫時還不太想鑽研前端。而對於我上面提到的各種知識，能怎麼安排、規劃比較好？謝謝大家。
: