---

※ 引述《m13m13m (奇怪 還沒收到??)》之銘言：
: 各位好~
:    我目前是網站工程師一枚. 這幾年有一個很深的感覺
: 就是後端愈來愈競爭, 可能是許多優秀好用的框架: Laravel,
:  ror, node.js, Django...陸續出現.


        但出現更多框架，不代表更加競爭。

        能與你競爭的只有上手速度比你快的人。

        這裡的快，不單純是指學習能力，或個人的資質聰明與否。






        這二種應用是有情境上的差別，根天資本質無關，

        而是思考風格比較相關，遇過的用得上，

        那就是套路 (template) 練過，簡單、送分題

       (只要你適時回憶起這段經歷)



        單純來談學習的話，先貼個參考資料。
        面對學習材料，我們需要適當的分類，並決定花多少力氣，
        =======================================================
        http://www.celt.iastate.edu/wp-content/uploads/2015/09/
        RevisedBloomsHandout-1.pdf

        http://bit.ly/2uOatHC

        =======================================================


        這樣的東西，基本花時間，手動做過練習，或對新學的材料，

        實作過 proof of concept 的驗證，就大致有個『手感』知道，

        『在這情境下，這麼用快又有效的』

        下回遇到一模一樣，或是簡單的變形，但還能識別出是同樣的問題時，


       (它是一種『學習遷移』的現象，通俗點叫『舉一反三』)




        你不會換了一個 framework 都得從 html syntax 開始學吧。

        若過去是 MVC Framework，那你應該會快速地想知道，


        而 view 是用什麼樣的 template engine

        是否有個 dispatcher 或 router 去將 request 導向適當的邏輯

        而 db 部分的處理，有哪些 sql/nosql 方案，



        你不是『從無到有』在學習同樣的領域，因為你已經學過了。

        不用再經歷一次，什麼叫 model，什麼叫 view，什麼叫 controller

        這些具體的『名詞、術語』都是一種『事實的知識』，

        也是『初學者』最喜歡花時間『記憶』的內容，


        當然，你已經有工作經驗了，我覺得你應該認同不會花太多時間在上面

        它可能只是換了框架後，目錄結構有一點改變，這些需要花時間記憶的東西



        我們不花時間去記它，而是弄個速查表，邊寫邊參考，多寫幾次就熟了。



        那麼，既然是一個有經驗的工程師，我們上手新框架，



        而代表著不同的概念 (或是作者的執念)。



        所以，經驗人士得先由概念核對開始，在這過程，也許會覺得難以調適

        因為跟過去同樣術語指稱的概念可能不同，

        入境隨俗，只好放下過去，迎向未來。


        我認識一些優秀的開發者，對自我要求比較高一點 (不像我比較沒節操)


        其中有一部分的人認為掌握一向技術是由

        『事實知識』『概念知識』可以完全不依賴書本或任何形式記錄，

        都記在腦中才認可自己的學習成果。



        對面概念知識，只要你看著書或筆記能回憶起來，


        並且用適當的術語與同事交談就行了，

        像是你知道 controller 負責在處理一些邏輯，

        當你跟同事在討論 bug 或某個無法描述的現象出現在某個地方時，

        你不會跑去 view 找問題，然後找不到問題，讓同事覺得你在鬼打牆。

        面對概念衝突時，就花時間接受它，或先不要抵抗它，試著 follow 它幾次

        走過同樣的思路後，腦袋自然順暢了。這階段就是克服心魔而已，

       (由於有 mentor 不同人的經驗，對成長期的開發者來說，

        大都卡在鑽牛角尖而無法茁壯，只能花時間等他自己過得了那關，




        若你意識到自己『卡』很久，那推薦另一個方法，是先進入『程序性知識』

        通常就是書上寫的『動手做看看』的部分，

        因為教學的書通常會告訴你實作的順序，特別是在介紹完：





        以作為學過幾套框架的經驗為底的情況，先撇開語言不同要熟悉語法

        大致能快速推進到程序知識，並在實作過程中交錯複習著概念知識與事實知識

        是有機會變成『初階』的即戰力的，可加入『生產』的行列。


        但是寫得夠不夠『在地化』得靠經驗者指點，

        至少不會換任何框架，都寫得像你原本的母語那樣的 style。





:    工作上遇到一層不變的薪水, 和難以跨越的門檻(做某一個框架
: 幾年, 想換到另一個想去的公司但是框架不同, 好的話,年資是從新算,
: 常常是遇到根本沒機會, 即戰力第一. 久而久之,路變得有點窄.
:    想請問各位如果繼續待在web這塊, 想跳去不同框架, 有沒有什麼建議
: 個人的觀察是php缺最多, 再來"應該"是java, ror, node.js, python
: 比較久一點的公司大多會用Java/php/.net, 新創會用python, node.js, ror
:    關於薪水和未來發展,我研究了很久都沒有頭緒. 如果想跳框架(目前用Laravel)
: , 想請問前輩建議. 主要考慮未來的技術發展和$$, 個人以為java和.net國內外有
: 很多大公司在用? 所以應該是首選???





        2. 你的公司覺得你的貢獻跟他賺的 $$ 挺有關聯的


        公司有沒有賺 $$，如果是上市的看財報就知道

       (其實我們大部分都在小公司，所以不知道公司有沒有賺錢)

        身為在小公司工作的鄉民，我會這麼想，有 2 個基本的方向：


        1. 作為後端工程師大概能知道公司有沒有花錢，


           直接觀察固定在主機花費，繼是否繼續成長 (至少你在的 team 要成長)










:     如果跳出web的話, 寫java好像大多是在Android,別的應用比較少??(小的孤陋
: 寡聞,故來請示), python應該就是往data走是趨勢,不過這塊主要吃數學和讀paper?
:     如果不做web,以我會的主要是python, java, js, 好像就只剩data && android
: data目前正在跟,但是離業界要求還有不少距離. Android則是跟不上了...
: 想請問前輩們給一些職涯意見
:                                                                 打結的大腦

        $$ 源頭確定有足夠的『可能性後』，再來是你怎麼支持你的公司。

        這時就不是討論是不是要用哪個語言，或哪個框架的問題了。

        在基於目前的 tech stack 的前提下，如何對業務的成長做出適當的反應

       (不是人做反應，是架構做出反應)




        像推文有人建議你由 DevOps 與高 QPS 架構下去，都是挺好的方向。



        單純以 Programmer 的角度，會推薦你先由 CI/CD 下手，

        寫寫各種測試，建立整合測試環境，然後部署到 dev/staging server

        這時會漸漸意識到，不是單純把東西實作出來就好，

        還要考慮它在目標的機器上跑起來好不好，

        最好它壞掉時，我比老闆早一點知道

        剛入手這領域的 Programmer 可能部分未有過不同系統的維運經驗，

        像是在 Windows/OSX 上開發，部署到 Linux。

        或是在個人 Windows Desktop 環境開發，

        部署到 Windows Server 等級的環境。

        較常見的抵抗心境是『我只是來寫程式的，為什麼要搞 server』

        這一關要先過去去，你才能順利玩得起其他的東西。


        而 DevOps 就是更強化開發與維運一起思考的原則，

        開發不再只想著眼前著 code 是怎麼實作，還得考慮怎麼實作比較好部署

        多虧這幾年很風行，有許多好用的工具出現。

        雖然它同樣的概念散在 CI/CD DevOps SRE 的領域，

        最終我們的目標是整個系統由出生(新 release)到死亡(寫驗屍報告)



        但多失敗幾次，次次逼進 root cause，一次一次加上防護機制，

        與架構改善，我們就能漸漸增加系統的健康度。

        隨著業務增長，你的系統也在茁壯中。



        開始的監測只是知道系統健不健康的開始，

        我們在監測的歷程與幾次業務推展，可以大略抓出設計上的弱點。

        這麼一來，就有機會擬定架構改善的計劃。



        我們建立多個 replication database 讓不會變系統狀態的動作使用


        只有少數會變更系統狀態的操作會動到能寫入資料庫的部分。

        當系統再更大時，也許會試著將 stateful 適當分割，也就是 sharding

        這麼一作，也就會讓系統能承載更多的壓力。


        或是除了同一個地理區域的 sharding，還有全球分散策略。

        網上有各種架構文章能參考，左岸也很多，反正他們人多這種事超需要的。



        技术揭秘12306改造（一）：尖峰日PV值297亿下可每秒出票1032张
        https://www.csdn.net/article/2015-02-10/2823900

        或微信紅包的架構，或搜尋版上討論『售票』的討論。

        http://highscalability.com/
        https://medium.com/netflix-techblog
        https://medium.com/aws-activate-startup-blog (搬家了)

--
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.250.146.151
※ 文章代碼(AID): #1QmwoWW_ (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1522773152.A.83F.html