---

※ 引述《csjs87 (思念的季節)》之銘言：
: 各位年薪三百萬的大神們好，小弟不才又上來請益了。一年前為了選擇資策會的課程在版上發了問，有幸獲得許多人的回覆。
: 從資策會畢業、順利找到工作也一陣子了，現在月薪37k，主要是協助開發後端。但我碰到一些對於自己不足的地方，想再次請教各位。


: 一、

        大部分都是如此，但不用灰心。因為，過去接受訓練的型式，

        常讓我們以為有替一些人排好課表、找幾個固定的主講人，

        拿著講義坐下來好好聽課才算是教學或者訓練。


        有些公司比較有機會做到這種典型的課程式教育訓練，

        即使公司的大小有關係，但主要還是公司主要用到的技術的範圍

        這些範圍內的東西，依產業或職位不同，變化的速度也不同。


        若是沒幾個月就變了一輪，那麼做個制式的訓練教材就是不划算的事了

        若東西一直沒變，那就可能是所以 tech stack 都鎖定了

        像一些會被嚴格稽核的金融系統會有這樣的特性。

       (舉金融為例，不代表它全都如此，金融也是一直導入新技術的。)


        所以特別準備通用的教育訓練就不那麼容易了。



        在沒有固定模式的訓練材料，大致會怎麼訓練人呢？

        大多是以處理 issue 跟參與 pair programming 為主。

        issue 以特定 bug 並明確是 reproducible 為佳，

        因為只要學會如何啟動系統，能開 debugger 來看問題為主


       (或運氣好，已有 unit test 基礎建設)

        在 trace 的過程中，你可以漸漸理解正在開發、維運的東西怎麼工作的



        若是公司沒有教材，你就有機會成為生出教材的那個人

        像是你可以用 sequence diagram 來表達從啟動到結束需要經過哪些

        大小元件或 method call。你可以有不同粒度的版本。

        或是 component diagram 來表達幾個大元件的依存關係。

        做好後，拿著它與其他同事解說，請他們給你 feedback

        你可以觀察並意識到，自己哪些部分理解了，哪些部分誤解了。

        而誤解的原因是單純看錯了，還是缺乏了某個基礎知識，

        或是過去人為決定的設計，讓你無法以目前的直覺適當地理解它。


        這樣互動並修正自我認知的流程才是真正的學習。

        由其他的的回饋，你可以知道自己說出來的東西，是否跟別人的理解相同了。

        這樣漸漸你可以內化這些知識，成為理解你工作領域的人。


: 二、

        這些都是好東西，但你得有基礎概念輔助才行。

        基礎概念包含『三』的部分，但遠比『三』本身更多，因為所列的這些工具

        還包含了方法論、哲學觀與工作文化的轉變，如果你沒有吸收到相關 mindset

        那你只是單純學習了新的工具而已。



        你其實該在意的是，如果我會 OOO，那麼在 XXX 的時機適不適合。

        在工作流程中，引入了 OOO 後，對於所處的工作環境是否有好的影響

        基於 XXX 的概念準則，為什麼 YYY 是個好/壞主意。






: 三、

        OS 部分，其實沒有離這麼遠。但是直接看教科書挺硬的。

        至少 process 與 thread 對應到你使用的語言、工具時相關問題要理解。

        像是怎麼處理 race condition 的問題

       (其實第 0 步是，培養識別 race conditon 的眼光)

        在沒學習之前，應該要有的敏感度是：

      『這程式，有時候會對，有時候有不對。沒什麼特別的規律』





        再進一步，怎麼寫出 thread-safe 的共用元件，

       (像是多數支援 multithread 的語言都有的 volatile 關鍵字)

       (它影響者你 shared variable 的 visibility)

        或是走向 immutable object 與 functional programming




        另外，資料結構算 Big-O 不會算沒關係，大多的複雜度都查得到。

       (至少寫了幾層 loop 這種 N*M 要看得出來)

        它是用來協助我們處理選擇障礙與實作優化的幫手。



        像是你要在一堆資料中，找 1 個東西存不存在，並取得對應的值：

        在 List 與 Set 中選擇，你對照一下時間複雜度，應該是內心有譜的。

        像有些給入行工程師的考題，都喜歡考你某 2 個容器的實作，


        這也是為什麼資料結構能處理許多選擇障礙的問題



        另一種情境是優化，你手上有個已經實作的好成品，它是用某個資料結構

        你要試著去安排你的資料，以發揮這個資料結構的特性，獲得較好的結果。

       (這是常見的資料庫的 indexing 的問題了，

        如果某些大大有開課的話，快去搶票先)



: 總之我現在稍微有點迷惘，對於程式這條路我覺得我才剛起步，也不想離開。但學海無涯，光上面就太多東西要學。
: 根據我自己的感覺，只知道自己暫時還不太想鑽研前端。而對於我上面提到的各種知識，能怎麼安排、規劃比較好？謝謝大家。
: -----
: Sent from JPTT on my Sony G8142.

--
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.115.104.120
※ 文章代碼(AID): #1SypUp5- (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1559443379.A.17E.html