Redis崩潰
I'm very serious about software reliability, and this is not just a good thing.
It is good in a sense, as I tend to work to ensure that the software I release is solid. At the same time I think I take this issue a bit too personally: I get upset if I receive a crash report that I can't investigate further for some reason, or that looks like almost impossible to me, or with an unhelpful stack trace.
Guess what? This is a bad attitude because to deliver bugs free software is simply impossible. We are used to think in terms of labels: "stable", "production ready", "beta quality". I think that these labels are actually pretty misleading if not put in the right perspective.
Software reliability is an incredibly complex mix of ingredients.
1) Precision of the specification or documentation itself. If you don't know how the software is supposed to behave, you have things that may be bugs or features. It depends on the point of view.
2) Amount of things not working accordingly to the specification, or causing a software crash. Let's call these just software "errors".
3) Percentage of errors that happen to be in the subset of the software that is actually used and stressed by most users.
4) Probability that the conditions needed for a given error to happen are met.
So what happens is that you code something, and this initial version will be as good as good and meticulous are you as a programmer, or as good is your team and organization if it is a larger software project involving many developers. But this initial version contains a number of errors anyway.
Then you and your users test, or simply use, this new code. All the errors that are likely to happen and to be recognized, because they live in the subset of the code that users hit the most, start to be discovered. Initially you discover a lot of issues in a short time, then every new bug takes more time to be found, probabilistically speaking, as it starts to be in the part of the code that is less stressed, or the conditions to make the error evident are unlikely to be met.
It is good in a sense, as I tend to work to ensure that the software I release is solid. At the same time I think I take this issue a bit too personally: I get upset if I receive a crash report that I can't investigate further for some reason, or that looks like almost impossible to me, or with an unhelpful stack trace.
Guess what? This is a bad attitude because to deliver bugs free software is simply impossible. We are used to think in terms of labels: "stable", "production ready", "beta quality". I think that these labels are actually pretty misleading if not put in the right perspective.
Software reliability is an incredibly complex mix of ingredients.
1) Precision of the specification or documentation itself. If you don't know how the software is supposed to behave, you have things that may be bugs or features. It depends on the point of view.
2) Amount of things not working accordingly to the specification, or causing a software crash. Let's call these just software "errors".
3) Percentage of errors that happen to be in the subset of the software that is actually used and stressed by most users.
4) Probability that the conditions needed for a given error to happen are met.
So what happens is that you code something, and this initial version will be as good as good and meticulous are you as a programmer, or as good is your team and organization if it is a larger software project involving many developers. But this initial version contains a number of errors anyway.
Then you and your users test, or simply use, this new code. All the errors that are likely to happen and to be recognized, because they live in the subset of the code that users hit the most, start to be discovered. Initially you discover a lot of issues in a short time, then every new bug takes more time to be found, probabilistically speaking, as it starts to be in the part of the code that is less stressed, or the conditions to make the error evident are unlikely to be met.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/301743/viewspace-750467/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- WkWebView 令人崩潰的崩潰WebView
- WKWebView崩潰WebView
- Crittercism:KitKat崩潰率0.7% iOS 7.1崩潰率1.6%iOS
- APP防崩潰APP
- WWDC 2018:理解崩潰以及崩潰日誌
- iOS Crash不崩潰iOS
- linux mint 崩潰Linux
- ios 崩潰集錦iOS
- app 崩潰的原因APP
- 執行緒崩潰為什麼不會導致 JVM 崩潰執行緒JVM
- 圖解 Redis | 差點崩潰了,還好有主從複製圖解Redis
- IOS 崩潰日誌分析iOS
- Invalid double崩潰分析
- MySQL 8.0.11 無故崩潰MySql
- iOS 避免常見崩潰(一)iOS
- iOS 避免常見崩潰(二)iOS
- InnoDB 崩潰恢復機制
- zookeeper叢集崩潰處理
- 突發:當機崩潰OOMOOM
- 幽蘭核心崩潰自救記
- 關於Mozilla崩潰的研究
- 崩潰的一天,西安一碼通崩潰背後的技術問題。
- win10 pr崩潰怎麼解決_win10 pr崩潰解決辦法Win10
- iOS開發的底線-崩潰iOS
- 【除錯技巧】Dialog dismiss 崩潰除錯
- Mac騰訊截圖閃退崩潰Mac
- Kdump 檢查 Linux 核心崩潰!Linux
- MySQL 崩潰恢復過程分析MySql
- android Activity崩潰日誌收集Android
- MySQL 引擎特性:InnoDB崩潰恢復MySql
- Android Service入門到崩潰Android
- 【安卓筆記】崩潰日誌收集安卓筆記
- windows10桌面崩潰怎麼修復_win10桌面無限崩潰解決方法WindowsWin10
- win10查詢崩潰日誌方法 win10怎麼檢視崩潰日誌Win10
- 怎麼樣把mysqld壓測到崩潰重啟?什麼情況下mysqld崩潰重啟?MySql
- iOS應用崩潰了,如何透過崩潰手機連線電腦查詢日誌方法iOS應用崩潰
- MySQL 5.7 主庫崩潰切備庫MySql
- GodBlessYou: 讓你的應用不再崩潰Go