Ddavid
大公司未必比較好XD
Ddavid
才不久前,人在 Google 的小光光跟我約了吃飯,就聊到修 bug 的話題,他說到台灣 Google 內部這方面有不少壞習慣XD
然後我覺得理由就是「目前 Google 夠大,底子夠硬,犯得起小錯」XD
pdshingo
這幾年感想就是沒有甚麼真的是一定要的,很多東西其實看狀況而定,成功的產品通常是幾個重點有達成,其他不要致命的錯誤就行了...

不過google內部不是有很嚴格的review制度,還會有"不少"壞習慣喔 XD
Ddavid
他自己目前待的小組主要是在做輔助追查 bug 的系統(當有 bug 出現時,其他小組會用他們的系統來追查問題是哪個版號出問題的機率),所以他來說應該很準確XD
Ddavid
主要就是即便 Google 仍然會有 開發新功能 > 修次要 Bug 的偏向
pdshingo
正常 XD
Romulus
其實我一直對接觸過的所謂優良測試很有疑問就是了 這些測試在寫的時候真的有評估過效益嗎
Romulus
測試應該是和風險的tradeoff 爆了就完蛋的東西要測仔細 爆了修一下就好的東西花一堆時間寫測試幹嘛
Romulus
可是我沒看啥測試教學提這件事……
Romulus
另外正在開發的程式的真正的優良結構應該是非常短時間(一個月內)就可以反餽的 也就是以一季之類的觀點看高質量程式會比低質量程式「快」
Romulus
如果這段code寫不寫所謂優良的差異都只會在五年後反應 那不是真的沒啥多花時間的價值
Romulus
像裡面有講的flag/class我手上的工作就有 我自己現在狀況是偷了一次不好的懶大概兩個禮拜後就要還債 = =
pdshingo
印象一本敏捷測試書我記得是有稍微提到這個的,測試還是得去區分輕重緩急和效益,有建議的切入點等等,不過大企業或公家氣息重的地方很容易變成形式化要去做這些就變得很沒意義...
而另外這種論點有時候也會變成團隊不做的藉口XD
pdshingo
不過如果CI/CD自動化測試有建好也有養成好的架構習慣,是真的能幫上不少忙,光是有做簡單的靜態掃描和初步的E2E/API測試就已經有用了,如果真的能做好架構分層和DI對商業邏輯做unit test、或是效能、探索性測試等等在一些要用牛刀的場合也是能幫上一些忙.. 只是 對 有時候殺雞用不到,而且每件事情都是要成本的,測試當然也是,有時候就是付不起...
pdshingo
然後有時候是實際的組織政治問題,這些東西有用,但是要怎樣轉成credit/contribution ? 加功能改ui大家看得到,解bug多做test甚至架構比別人好需要度量更多進階數據和讓上層有感...結果就是要嘛你得更強做更多要嘛組織應對能力得再上一層樓 XD
Romulus
付不起這件事其實有點微妙 如果真的付不起代表這件事本來就不值得付 需要付但沒付導致之後還債更多的情況才需要付 而這也其實沒啥付不起的說法
Romulus
因為在有意義的時間內需要還債的話不付只是個飲鴆止渴的趕 沒有讓專案能走下去
pdshingo
yeah,就跟說沒時間一樣,其實代表的是這件事情真實優先度不如其他事情XD

不過有時候狀況是既有作法面對既有業務沒問題,但是當公司想轉型或更上一層樓做更複雜的東西時,那某些東西沒有又很難真正做到。

(只是很多時候公司也不見得能認清要更上一層樓那些要付的代價是甚麼...)
Romulus
那就是根本沒p眼上那一層樓(
載入新的回覆