推 senjor: 要把非同步改成Promise有空再做，但是一開始就應該直接用 04/25 14:46
→ senjor: promise+async去做了，我本來以為他說的是後者不需要。 04/25 14:46
※ 引述《wandallin (萬大林)》之銘言：
: 大家晚安，因為本身沒什麼朋友在新創上班，自己也是第一次在新創
: 所以想在這邊詢問大家開發上的一些小疑問
: 開發環境是react.js + create react app + firebase
: 目前公司是MVP剛上線的狀況還在補足一些功能
: 好讓老闆出去推銷，尚未盈利也還沒確認商業模式
: 不過在開發過程中其他工程師會提一些作法，說是為了未來著想
: 例如：
: 1. PR要merge的時候做Squash，因為這樣git tree比較好看
這點可參考這篇
https://softwareengineering.stackexchange.com/questions/263164/
: 2. function超過一百行，就想要拆出來
個人是覺得行數不是重點,
要看它的內容是不是有某部份能被視為具體完整的動作才拆出來
不過通常到一百行時有很大的機會是 "是"
: 3. 完全遵照eslint的規範，任何warning都不能出現
話說這個有線上版 https://eslint.org/demo/
你可以把一些知名開源專案 (如 ng react vue) 的程式丟進去
看看是不是都沒有 warning... :p
如前面另一篇說到的, 這是給你用來自己設規則方便提醒的,
完全照做就不必, 重點是你違規時知道自己在幹麻
: 4. 時常想回去重構程式
這部份我覺得需要好好檢視, "時常" 是多常呢? "回去" 是回哪裡呢?
是每次想重構的部份都不一樣, 還是同一部份改了 N 個版本?
如果是隨著開發, 時當想這裡調一調、那裡修一修,
這還算正常範圍, 不過這種通常也不會太費時,
如果是某個功能, 一直想到新架構新流程, 重寫再重寫,
那...個人建議動手之前多想一想再開工比較實際
也要看看重構的地方值不值得花時間,
核心主幹是有需要, 但那種通常不會是他一個人猛鑽研而是要大家一起討論
支微末節的地方就沒有時常重構的必要
: 5. 想把所有非同步的function都改成promise
這我覺得有閒可以做, 不然之後要改動到時再順便就好
: 6. 想導入TDD以及jest，讓系統減少錯誤發生機率（目前沒人會這東西）
剛好有在寫 node, 剛照官方試了一下
https://facebook.github.io/jest/docs/en/getting-started.html
跑起來不難, 麻煩的是要讓它順順地進入你們的建置佈署流程,
也看你公司是做什麼的,
假如是寫網頁, JS 是很多分別獨立小小片段的那種, 個人是覺得不必,
用 JS 寫底層框架或 lib 才比較有需要
而如果是寫網頁的話建議跑跑瀏覽器自動測試就好了, 現在資源真的有夠多
有影片教學
https://www.youtube.com/watch?v=S4OkrnFb-YY
應該也可以找得到 docker 直接 pull 或 build 一下就能用的環境
裝 docker 抓來用就好
: 7. 註解盡量刪除，只留jsdoc，減少封裝程式碼
這點改用工具做吧 @@
: 上面除了第六項其他都開始做了
: 不知道大家的公司的情況是怎麼樣
: 我沒有想過這些東西的壓力會遠大過我思考服務架構的問題
: 這些東西讓我覺得滿煩的，沒有制度化都是看個人喜好
: 可能哪天他看到一個別的覺得不錯又要用了
: 還是說新創本來就是這樣，可能我比較適合回去一般公司
: 這輩子第一次覺得寫程式這麼煩＝＝
"遠大過" 個人是覺得一定有哪裡不對勁,
用的範圍不恰當/沒有使用好工具/頻率太高/etc...
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.80.109
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1524637064.A.643.html