《致命Bug:軟體缺陷的災難與啟示》讀後感受
如題,這篇文章是看完了《致命Bug:軟體缺陷的災難與啟示》這本書並且回顧了每一章以後才寫的。這本書的整體脈絡是這樣的:
這本書的標題和小標題都算是引人入勝的,軟體的故障已經在各行各業中有了影響,人非聖賢,孰能無過,計算機呢,計算機也不是完全不出錯的,計算機+人=Bug共同體。這本書大部分羅列的是嵌入式軟體帶來的問題,目前非嵌入式軟體和系統帶來的影響也不亞於嵌入式軟體的影響。書中關於“一件事情,如果不能測試,那就不要開始”的觀點本人是非常贊同的,目前的技術也都在努力去做到更真實的模擬線上環境,為了避免上線後的不必要的損失,這也是必要的模擬。這本書本身的事件是實實在在的真實事件,作者本身對於事件的挖掘還是值得欽佩的,對於每個事件,讓我們看到了事件的深層次的不為人知的內容,但是整本書的效果在我看來,作者對於事件的講述和加工效果略差,講故事講的讓人看不下去,我也是醉了。
書中的講述有幾個痛點,會讓很多讀者感覺很不好:
- 翻譯的生硬,這個翻譯人員我就不說了,反正沒聽過,翻譯的也確實不咋地
- 作者喜歡漫無邊際的扯,扯到最後說,這是軟體問題,懵逼了
- 作者在有些事件中根本講不清是不是軟體的問題,欲加之罪,何患無辭似的硬是說軟體毀了一切
- 書中的黑白配圖,哎,有的地方糊成一片,啥都看不到
- 書中好不容易講講虛擬碼,不標註行號,直接就說第幾行第幾行怎麼怎麼了,碼農們表示心好累,寶寶不看了還不行嗎
總的來說,這本書不是很閒還是不推薦看了,看了以後你會發現那剪不斷理還亂的邏輯真還不如看教科書順。
相關文章
- 致命Bug:軟體缺陷的災難與啟示
- 關鍵基礎設施軟體的缺陷可能意味著災難
- 缺陷軟體:大資料驅動科學的致命傷?大資料
- 軟體缺陷的案例
- 【乾貨分享】軟體Bug和缺陷有什麼區別?
- 軟體用例寫作與缺陷管理
- 《軟體故事》讀後
- [軟體測試理論基礎] 記錄第一個 Bug 的誕生,為什麼軟體缺陷叫 Bug/Defect?
- 研究顯示,用Python更易出現軟體缺陷!Python
- 軟體測試:軟體缺陷管理
- 讀軟體設計的要素07讀後總結與感想兼導讀
- 軟體缺陷管理流程
- 【軟體測試】缺陷
- 《軟體方法》讀後感
- [個體軟體過程]之缺陷管理--缺陷預測 (轉)
- 排隊與掉線,線上遊戲的「人口災難」遊戲
- 讀軟體開發安全之道:概念、設計與實施14低階編碼缺陷
- 事後諸葛亮:如何寫出沒有bug的軟體
- 無人車致命車禍視訊曝光:Uber技術失敗的實錘,一場本可避免的災難
- 軟體測試中容易忽略的缺陷
- 軟體測試--缺陷報告
- 案發現場:被注入的軟體及 ORA-600 16703 災難的恢復
- 軟體危機和軟體缺陷的特點和區別
- 機器學習中的維度災難機器學習
- 《C缺陷與陷阱》讀書筆記筆記
- C陷阱與缺陷--讀書筆記筆記
- 軟體Bug引發的十次嚴重後果
- 軟體 Bug 引發的十次嚴重後果
- 軟體開發的難
- 基於UNIX系統,邏輯故障的資料災難解讀
- InstallShield 打包後,啟動軟體
- 03《軟體工程思想》讀後感02軟體工程
- 01《軟體工程思想》讀後感01軟體工程
- 軟體工程的最大難題軟體工程
- SaaS軟體的技術缺陷以及解決方案
- SQL Server災難恢復SQLServer
- 1人作《致命公司》的成功,帶給遊戲開發者的三點啟示遊戲開發
- 從光大證券的軟體設計缺陷想到的。