Re: [問題] 求助～專職後遇到的瓶頸

[art1 (人，原來不是人)]

※ 引述《ponyufang (yufang)》之銘言：
: 我是從設計轉前端工程師，原本只會切版。
: 最近轉職後遇到的瓶頸，不是在寫程式本身，而是對很多程式以外的東西不瞭解。
: 比如說node.js、git等等，剛進公司是同事幫忙架環境，我只能看著他操作，卻不懂意思
: 。
: 爬了一些文章，才好不容易知道要怎麼使用終端機，還有學會git 指令，但覺得自己還是
: 一知半解，好像沒有真的了解原理。
: 我回到家想用自己的電腦操作看看，但是一直不成功。
: 想裝node.js，查了文章之後又看到homebrew、npm等等的，照著步驟做又會有問題，覺得
: 主要還是不懂這些東西在幹嘛。
: 不知道是不是自己對很多電腦的基本概念不懂，我自己本身周遭沒有相關背景的朋友可以
: 詢問，公司的同事都是資管、資工背景出身，有時候詢問他們問題，都無法得到明確的答
: 案，他們無法理解我為什麼不懂這些，所以都只會回答就是這樣、就是那樣。
: 我覺得很困惑，不知道有沒有朋友跟我有過一樣的經歷，可以給我一點指引。
: 是不是要從哪裡著手去把基礎的東西學起來？
: 可能這樣問會被罵，但希望有人可以給一點意見。

  當初 javascript 這個程式語言開發出來是為了可以在瀏覽器下完成一些工作
  node.js 就是讓你可以在瀏覽器之外還可以執行 javascript 程式碼的一種環境

  npm 則是 node.js 內建的一個工具軟體

  你應該有軟體常常在更新的概念，前陣子你安裝一個軟體來用，過了一個月這軟體出了
  新版的，結果你更新成新版之後使用上出了很多問題，你就想說那不如移除之後裝舊版
  的來用，於是你就到作業系統提供的管理已安裝軟體的介面移除該軟體，再去下載舊版
  的來安裝

  以上就是手工的作法，而 npm 則是讓你可以透過下指令讓電腦幫你完成同樣的事情，
  更好的是你可以編輯 package.json 檔案來讓 npm 完成更多其他的工作，不過 npm
  管理的軟體只限於能在 node.js 環境下執行的軟體

  homebrew 也是類似的功能，不過專門用來管理執行於 Mac 中的軟體



  而 git 則是版本控制軟體

  以前若你想備份一個檔案是怎麼做的？ 複製起來存到某個資料夾，對吧？
  若這個檔案會隨著時間被人編輯而一直增加內容，而你又想保存舊版本的內容，好讓
  你可以在某個時間點能夠再從這個舊版本重新開始，是不是開始每次存檔時就另存新檔
  ，並對檔名加上一些可以辨識版本的資訊？

  上面描述的就是很手工的版本控制方式，而各種版本控制軟體就是為了同樣的目的，
  但卻可以透過下指令讓電腦來幫你完成同樣的工作，效果還更好




  在你還不熟並試著安裝這些工具來使用時，記得把你做過的事情，遇到的錯誤訊息，
  一步一步記錄下來，當你卡住時，這些記錄下來的資訊可以幫助別人快速判斷問題出在
  哪裡，而且日後你若忘記了也能重新照著這些步驟來做

  在你開始寫程式之後，會發現常常要安裝一堆工具軟體，這些都是為了幫助程式設計師
  可以更快速、更正確地開發軟體

  例如未來你可能會需要寫測試，所以需要安裝一些測試框架，像 jest 或 jasmine
  可能會需要流程自動化，所以需要安裝 gulp 或 grunt 或其他的軟體
  可能會需要統一程式碼風格，所以需要安裝 eslint 之類的軟體
  可能會需要更進一步的整合所有流程，所以需要安裝 jenkins 之類的軟體

  會不斷重複做的事情，就交給電腦幫我們做，這就是安裝這些工具軟體想達成的目的

--
   「看在上帝的份上，我們不能當著孩子的面槍殺他的父親！」
   「那我們就連孩子一起幹掉！」
   「第一槍打中的是那個天真的孩子，第二槍是抱著孩子的母親。第三槍
     停頓了三秒，當難以致信的父親擦拭著臉上愛子的腦漿從震驚中醒轉
     過來，慢慢的轉頭看向停車的地方，分辨出是誰在攻擊他後，第三顆
     子彈才將他的腦殼打飛。」                       ─摘自〈狼群〉

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.121.179.216
※ 文章網址: https://www.ptt.cc/bbs/Web_Design/M.1524927299.A.953.html
推 wooji: 講的通俗易懂
推 wooji: 可以補充一下測試框架和jenkins那邊的知識點嗎
  測試框架我也還在摸索中，jenkins 沒實際使用經驗，只有看別人文章後的一些理解
  以下僅供參考


  測試自己寫出來的函式，也就是想知道呼叫這個函式之後，產生的結果是否正確

  例如你的函式接收一個引數之後會回傳一個二維陣列，你想知道回傳的二維陣列的值
  是否跟你預期的一樣，所以你就直接呼叫此函式，並傳入一個值當引數，然後設定另一
  個變數存放你預期的結果，接著拿預期值來跟回傳值做比較

  若是不靠測試框架，就要另外撰寫程式碼來逐一比較兩個二維陣列的值是否都相等
  有了測試框架，只需要一行程式碼就能完成這種多層陣列或物件的比較

  更進一步的，有時只想知道某個函式是否有被呼叫，或是被呼叫了幾次，或是傳入的引
  數數量與內容是否如同預期，測試框架都有提供相關的語法



  一個軟體的完整開發過程，不只有編寫程式碼而已

  寫完或改完一個功能之後要測試，測試完要把這功能整合進完整的產品之前，還需要檢
  查程式碼風格是否一致，若不一致就不讓你提交(commit)，更嚴格一點的還要先經過同
  事的審查才讓你提交

  成功提交之後又要重跑一次整個產品的整合測試與各種單元測試，都沒問題之後，接著
  把產品部署到有可能的使用者使用環境，像是各種行動裝置或桌上型電腦，各種瀏覽器
  版本、各種作業系統版本等等

  每種裝置或平台要能正常使用產品，都有各自的前提，把這些前提都滿足了才能正常執
  行，之前有看過票選工程師最愛講的話第一名：「在我的電腦上可以正常執行阿」

  當產品需要部署到這麼多不同裝置或平台時，若要確保每次部署都不會出問題，最好能
  自動化，並自動回報是否出問題了

  開發->測試->部署，每做一點修改，就重跑一次這個流程，這就是 jenkins 要做的

  實際上提供了更多的功能，像是提供測試覆蓋率的精美報表，也就是實際上會執行的
  程式碼有哪些被測試程式驗證過了，有哪些還沒




  每當改完一個功能，就驗證一次，這樣可以在出錯時快速判斷出是哪邊可能有問題

  這就是為什麼要寫測試，即使測試無法把所有可能的錯誤抓出來，但絕對能降低花在
  除錯上的時間，而且測試最好都要能自我回報，也就是不需要用肉眼去比對結果是否
  正確，而是在出錯時主動告知在哪個地方發生錯誤了

  前面提的測試覆蓋率達到百分之百也不代表就沒問題了，但不足百分百的意義是還有
  哪些不足之處可以加強

  程式設計師花在開發功能的時間跟除錯的時間，通常都是除錯的時間占多數，當產品
  越來越龐大，若沒有足夠的驗證機制，每次花在除錯上的時間只會越來越長

  更進一步的還有 docker，也就是每個裝置或平台的執行環境用容器包起來，然後測試
  跟部署流程就在容器裡面執行，每次開發完就啟動所有容器，每個容器內可能就從安裝
  相關的作業系統、產品測試與正常執行的必要前提，安裝完之後接著執行測試與部署流
  程，最後回報結果。有時則是從已經準備好各種前提的容器開始運作

  docker 比虛擬機器好的地方在可以執行的數量多上很多
※ 編輯: art1 (122.121.179.216), 04/29/2018 07:12:24
推 ponyufang: 非常感謝！昨天花時間研究怎麼使用終端機還有git的概
→ ponyufang: 念與操作
→ ponyufang: 會再繼續把你上述的東西搞懂，非常謝謝熱心分享的朋友
推 larrykkk: 寫的好
推 sbRICK: 寫的超好~
推 s9250123: 受益良多推～～～