※ 引述《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，減少封裝程式碼
以後面維護程式碼的人 在越短時間看懂 為基準 才是對的
至於怎麼操作 看人
: 上面除了第六項其他都開始做了
: 不知道大家的公司的情況是怎麼樣
: 我沒有想過這些東西的壓力會遠大過我思考服務架構的問題
: 這些東西讓我覺得滿煩的，沒有制度化都是看個人喜好
: 可能哪天他看到一個別的覺得不錯又要用了
: 還是說新創本來就是這樣，可能我比較適合回去一般公司
: 這輩子第一次覺得寫程式這麼煩＝＝
老實說 你還沒待過真正的新創
因為真正的新創 才不會有時間讓你想這麼多