顯示廣告
隱藏 ✕
※ 本文為 layzer 轉寄自 ptt.cc 更新時間: 2019-06-06 14:07:09
看板 Soft_Job
作者 qrtt1 (有些事,有時候。。。)
標題
 Re: [請益] 後端工程師要如何更優秀

時間 Sun Jun  2 10:42:57 2019


※ 引述《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,想使用新知識。但到了休假日,也很少真的著手進行。
: 總之我現在稍微有點迷惘,對於程式這條路我覺得我才剛起步,也不想離開。但學海無涯,光上面就太多東西要學。
: 根據我自己的感覺,只知道自己暫時還不太想鑽研前端。而對於我上面提到的各種知識,能怎麼安排、規劃比較好?謝謝大家。
: -----
: 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
※ 編輯: qrtt1 (59.115.104.120), 06/02/2019 10:52:32
yamakazi: 推1F 06/02 11:02
obj: 認真回,推2F 06/02 11:31
vi000246: 推3F 06/02 11:35
loadingN: 好4F 06/02 11:38
devilkool: U文5F 06/02 11:41
shockrabbit: qrtt1 大大的好文,給推6F 06/02 11:46
fish0112: 先推7F 06/02 11:56
atpx: 精闢, 推推8F 06/02 11:58
csjs87: 先推再看,謝謝大大9F 06/02 12:47
neo5277: 推推10F 06/02 12:47
eateat33: 講的很棒 推推11F 06/02 13:41
dream1124: 推12F 06/02 14:27
srwhite: 優文推13F 06/02 15:28
qrtt1: JCConf CFP 中 http://bit.ly/2Ibg4uU14F 06/02 17:02
JCConf Taiwan 2019 Call for Proposals
[圖]
Java Community Conference Taiwan 是由 Taiwan Java User Group 社群主辦的 Java 開發者年會,以提供更多機會讓開發人員之間能夠互相交流。本屆活 ...

 
SuperCry: 好文欸15F 06/02 18:27
LERICAL: 推16F 06/02 19:16
boy955403: 推17F 06/02 19:49
pttrAin: 推18F 06/02 20:37
aa83090202: 推19F 06/02 21:09
cutekid: 推推(Y)20F 06/03 00:01
Eric0605: 推21F 06/03 00:04
BearWu: 推!!22F 06/03 00:30
genius945: 推 "理解他們為什麼選擇,站在什麼樣的視角去做選擇"23F 06/03 02:56
GinginDenSha: (至少寫了幾層 loop 這種 N 的 M 次方要看得出來)24F 06/03 09:45
GinginDenSha: 應該是 N*M 吧
(fixed)

你是對的,因為我舉的例子,跟想說的概念不太一致 XD

原本想到的是另一件事,但忘了寫了。
先前有個程式要算 n-gram 的詞條,做一些自然語言的分析。它複雜度挺大的。
雖然 n*m 不是一樣的數,但文章數越多,時間越久。差不多能視為 N^2 的複雜度了。

拿著目前有的單台機器時間去估計,跟同事講幹話:

「我算了一下,以目前的文章產生出來的候選詞,
  在這台小主機,差不多要跑 1 萬年吧」

「那麼,我們會遇到 10 個橋本環奈吶!!! (不自覺地興奮了起來)」

不過,看看實際上要計劃的東西,是要在相近分數的 tf-idf 中做出排序。
沒需要真的去做 O(N^2) 的東西。當時間不夠找到替代方案時,我們有另一個選擇。
把 N 縮小 => 分組做。

改了一下寫法,送上 AWS EMR 先把很大的 N 分割成小組,再跑杯具的 O(N^2)。
還是花了 3 個多小時才跑完。

謝謝 @GinginDenSha 挑出問題,讓我回想起原本要寫的東西xd

※ 編輯: qrtt1 (36.231.142.167 臺灣), 06/03/2019 10:34:02
※ 編輯: qrtt1 (36.231.142.167 臺灣), 06/03/2019 10:37:25
※ 編輯: qrtt1 (36.231.142.167 臺灣), 06/03/2019 10:38:57
※ 編輯: qrtt1 (36.231.142.167 臺灣), 06/03/2019 10:39:29
fayhong: 熱血的前輩!26F 06/03 17:25
kmjx: 十個橋本環奈XDDD27F 06/04 12:54
qrtt1: 終於有人發現橋本環奈惹28F 06/05 20:28
sersus: 求救29F 06/06 08:41
sersus: 手機發推文什麼都沒打自己變成求救

--
※ 看板: layzer 文章推薦值: 0 目前人氣: 0 累積人氣: 141 
※ 文章分類: 程式設計
r)回覆 e)編輯 d)刪除 M)不收藏 ^x)轉錄 同主題: =)首篇 [)上篇 ])下篇