※ 引述《wandallin (萬大林)》之銘言： : 大家晚安，因為本身沒什麼朋友在新創上班，自己也是第一次在新創 : 所以想在這邊詢問大家開發上的一些小疑問 : 開發環境是react.js + create react app + firebase : 目前公司是MVP剛上線的狀況還在補足一些功能 : 好讓老闆出去推銷，尚未盈利也還沒確認商業模式 : 不過在開發過程中其他工程師會提一些作法，說是為了未來著想 不用過早完美 或 普通 甚至爛 都可以 客戶只關心 什麼時候上線 可以動就好 專注完美的後果就是把自己搞的壓力很大 而且老闆+客戶會覺得你不專業 工程師常常會非理性 認為OOXX現在不做 之後就會OOXX的結果 只能說 常常都是想太多 : 例如： : 1. PR要merge的時候做Squash，因為這樣git tree比較好看 基本，不過用rebase會更好 但前提是會用 squash會有owner不清的問題 : 2. function超過一百行，就想要拆出來 沒有什麼超過100行就要拆出來的淺規則 遵循行之有年的SOLID原則 或許是你可以考慮的部分 : 3. 完全遵照eslint的規範，任何warning都不能出現 基本 不過現在都改用 javascript standard style 懶得設定eslint : 4. 時常想回去重構程式 沒時間 而且 在MVP版本不確定是否可行之前 也沒必要 : 5. 想把所有非同步的function都改成promise async await , promise 已經是基本款 根本不需要考慮 : 6. 想導入TDD以及jest，讓系統減少錯誤發生機率（目前沒人會這東西） tdd見仁見智，jest一般來說也沒時間 可以考慮先用最基本的snatshop 過早全域component化，基本上就是痛苦的開端，不過這也是讓unit test or snatshop 最能達到效果的部分 : 7. 註解盡量刪除，只留jsdoc，減少封裝程式碼 以後面維護程式碼的人 在越短時間看懂 為基準 才是對的 至於怎麼操作 看人 : 上面除了第六項其他都開始做了 : 不知道大家的公司的情況是怎麼樣 : 我沒有想過這些東西的壓力會遠大過我思考服務架構的問題 : 這些東西讓我覺得滿煩的，沒有制度化都是看個人喜好 : 可能哪天他看到一個別的覺得不錯又要用了 : 還是說新創本來就是這樣，可能我比較適合回去一般公司 : 這輩子第一次覺得寫程式這麼煩＝＝ 老實說 你還沒待過真正的新創 因為真正的新創 才不會有時間讓你想這麼多 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.171.95.22 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1524593018.A.284.html