※ 引述《wandallin (萬大林)》之銘言：
: 大家晚安，因為本身沒什麼朋友在新創上班，自己也是第一次在新創
: 所以想在這邊詢問大家開發上的一些小疑問
: 開發環境是react.js + create react app + firebase
: 目前公司是MVP剛上線的狀況還在補足一些功能
: 好讓老闆出去推銷，尚未盈利也還沒確認商業模式
: 不過在開發過程中其他工程師會提一些作法，說是為了未來著想
: 例如：
: 1. PR要merge的時候做Squash，因為這樣git tree比較好看
我自己是沒意見，因為懶，但我會照做，這沒什麼好爭論的，管專案時程與掌控
細節的人有需要的話，這種程度的overhead 可以吞
: 2. function超過一百行，就想要拆出來
我是寫Java的，即使是古早時代寫Eclipse Plugin那種超複雜的Desktop GUI Program
我都可以壓在50行內，到目前為止，只要是『程式碼要持續維護超過半年』的情況，
我看不出有任何藉口一個Method可以超過100行
: 3. 完全遵照eslint的規範，任何warning都不能出現
: 4. 時常想回去重構程式
我的重構發生在：
1. 那個地方已經變成Error Prone，照三餐來煩你，不修整就是天天給他出代誌
2. 加新功能，重構本來就是『新功能實作』的一部分，把原本的結構鋸掉一塊然後硬插
東西上去就說新功能做好了，這算哪門子做好？這樣搞的人到底是在搶功勞、討好老闆，
還是好好做事？明天要Demo那我沒話講，但這不會去說它做好了。
3. 可以預見未來會有很多地方都依賴這個部分，那就是照三餐做重構，特別是API的切
分與命名，doc要補齊，當然我說的『很多』，指的就是至少三個跨instance的Module
4.重構絕大多數不是改架構，通常只是把責任切分清楚，讓該在一起的在一起，一段
程式碼不要同時得考慮太多不同層次的業務與工程需求，當然這有能耐的問題，對我來說
開個interface透過polymorphism把service內不該看到的東西遮掉，把合約訂清楚是了
不起一個下午的事，但有些人就是會用上兩天，那就是自己能力範圍內做好
: 5. 想把所有非同步的function都改成promise
我不曉得你的語言環境這塊是不是已經很成熟，Java的話是沒啥好談的，我知道的就至少
有三四個成熟的方案能選，用哪一個都可以，自己的玩具程式還是測試才會用Thread硬幹
選擇的重點在於程式碼是用在什麼場景？簡單的問，就是你是開發自己的App？還是開發
給人用的lib、甚至是framework？
這個程式碼會跑在哪幾種container裡？
Servlet? Android? Spark? Spring? 凡是有Component lifecycle的都要想一下他所處的
環境的水電基礎能不能支援這種介面
然後測試是重要的，如果你決定讓自己的interface去依賴別人開發的lib，這種async的
東西測試用的utilities、await()該做的都要做
: 6. 想導入TDD以及jest，讓系統減少錯誤發生機率（目前沒人會這東西）
大部分pure code我是不寫測試的，我認為靜態強型別的語言使用要義，就是透過型態
約制與meta programming，利用compiler 與IDE來幫開發者預先糾錯，會搞TDD只有在：
1. 核心邏輯複雜度極高，比如說開發DSL Interpreter、rule engine等需要用上finite
state machine的場合
2. 重構寫太髒需要大清掃的程式碼的時候
有side effect的程式碼我寫測試粗分三類：
(隨便寫，不然認真寫下去不曉得多少字，叫qrtt1來補好了)
UI、Persistence、Downstream portocol
UI我個人經驗(偏見)是：他基本沒救，搞那種起虛擬環境去按鍵精靈的成本非常的高，
startup還是認命自己點吧，要稍微有救一點的從E2E test開始，前提是model view
presenter的view abstraction不能偷工太多，不然protocol不清楚的東西測試也是亂寫
Persistence的測試除了效能測試以外的都是在確定異質系統(DB, HDFS, 其他)是不是
如同你想像的，把DB或File System Mock掉的測試是沒什麼意思的，除非在測異常處理
邏輯
Downstream portocol一般就是有切Micro Service，上下游都是同一家人寫的，也
就是兩造間該怎麼講話還有喬的空間，通常這些測試就是真正的規格，可以拿來畫押、
拿來當教學、拿來保證重構完不會死人
即使是startup，測試異常與正常的比例經驗上也至少得2:1到5:1，完全只考慮happy
path那是明天要給大客戶做demo才這樣搞
最能寫code不會錯的人，都是預先知道要測該測哪裡的人，那人要怎麼知道該測哪？
就是平常寫夠多測試寫出心得啊，不然難不成靠擲杯嗎？
這就是我說的：『平日經常練習舉100KG，今天突然要賭110KG才有機會』的意思
: 7. 註解盡量刪除，只留jsdoc，減少封裝程式碼
每個function body都小於30行，就會發現註解就是method signature，重構等價
於寫註解
: 上面除了第六項其他都開始做了
: 不知道大家的公司的情況是怎麼樣
: 我沒有想過這些東西的壓力會遠大過我思考服務架構的問題
: 這些東西讓我覺得滿煩的，沒有制度化都是看個人喜好
: 可能哪天他看到一個別的覺得不錯又要用了
不試肯定不行，連SI都會試了startup還不試那是要拿啥贏別人？
一直亂試當然也不可以，這是在做生意，不是在玩
拿捏這之間的分寸就是tech lead的價值，看老闆的眼光一部分就是在看這個
: 還是說新創本來就是這樣，可能我比較適合回去一般公司
: 這輩子第一次覺得寫程式這麼煩＝＝
凡事總有第一次的，習慣就好