Re: [請益] 新創剛起步的一些開發疑問
※ 引述《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的價值,看老闆的眼光一部分就是在看這個
: 還是說新創本來就是這樣,可能我比較適合回去一般公司
: 這輩子第一次覺得寫程式這麼煩==
凡事總有第一次的,習慣就好
--
『你知道人有腦子,所以不要只是單純的滿足它,偶爾也要使用它啊。』
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 216.52.21.4
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1524596880.A.1BF.html
※ 編輯: zanyking (216.52.21.4), 04/25/2018 05:10:10
※ 編輯: zanyking (216.52.21.4), 04/25/2018 05:14:09
※ 編輯: zanyking (216.52.21.4), 04/25/2018 05:18:02
推
04/25 07:43,
6年前
, 1F
04/25 07:43, 1F
推
04/25 08:10,
6年前
, 2F
04/25 08:10, 2F
推
04/25 08:18,
6年前
, 3F
04/25 08:18, 3F
→
04/25 08:18,
6年前
, 4F
04/25 08:18, 4F
→
04/25 08:18,
6年前
, 5F
04/25 08:18, 5F
推
04/25 10:15,
6年前
, 6F
04/25 10:15, 6F
→
04/25 12:30,
6年前
, 7F
04/25 12:30, 7F
→
04/25 13:45,
6年前
, 8F
04/25 13:45, 8F
→
04/25 13:46,
6年前
, 9F
04/25 13:46, 9F
→
04/25 13:47,
6年前
, 10F
04/25 13:47, 10F
→
04/25 18:21,
6年前
, 11F
04/25 18:21, 11F
推
04/25 21:58,
6年前
, 12F
04/25 21:58, 12F
→
04/25 22:58,
6年前
, 13F
04/25 22:58, 13F
→
04/26 01:02,
6年前
, 14F
04/26 01:02, 14F
→
04/26 01:02,
6年前
, 15F
04/26 01:02, 15F
→
04/26 02:07,
6年前
, 16F
04/26 02:07, 16F
→
04/26 02:07,
6年前
, 17F
04/26 02:07, 17F
推
04/27 16:17,
6年前
, 18F
04/27 16:17, 18F
→
04/27 16:17,
6年前
, 19F
04/27 16:17, 19F
討論串 (同標題文章)