程式設計師如何描述清楚線上bug
案例
一個管理後臺的bug，把操作記錄中的操作員姓名，寫成了該操作員的id。原因是修改了一個返回操作人姓名的函式，返回了操作人的id。但是還有其他地方也用這個函式，導致其他地方把姓名欄位填寫成了操作員的id。
該bug汙染了一條修改記錄，操作員手動刪除就好了。回滾程式碼後恢復。
本質是修改了函式的返回值，卻沒有檢視所有呼叫的地方。這個函式的名字叫getinfo，但是在程式碼的其他模組中也有同名函式，返回的都是id，讓修改的人以為都是一個函式，引起了混淆。所以函式名也要修改，做到通過名字能夠清晰看出函式功能。
本來很簡單的一個線上bug，按照上面的描述幾句話就說清楚了，但是一個組員說了一個小時，才勉強讓組內的其他同學聽明白。
他在描述的時候，先說程式碼，還有更改程式碼的背景，而且描述的隻言片語，讓大家不停提問，花了很多時間。
怎樣能夠描述清楚線上bug，也是有方法論的，大家可以看看。
描述的順序
1. 對齊背景
對於線上bug，先描述影響，從使用者角度把bug描述清晰。可以把自己想為測試，測試給我們報bug的時候，從來都不會說你程式碼哪裡錯了，只是把現象給出，再加上覆現的步驟。
同時也說清楚影響範圍，多久恢復，讓大家放心，知道影響面。
2. 交代錯誤原因
用直白的語言，說明出錯的原理。為什麼出錯？注意是直白的語言，不是交代程式碼層面那個函數出錯。例如上面的例子，應該說是函式返回值修改導致，而不應該直接說getinfo是一個什麼函式，為什麼要修改這個函式。
3. 說明引入錯誤的始末
一般線上bug都是由於變更引起的。究竟是什麼變更，為什麼會有變更需求，也需要交代清楚。
4. 如何預防
發生bug不可怕，可怕的是重複發生。 吃一塹長一智，不讓錯誤發生第二次，要反思預防的方法，防止再次發生。把預防的方案想好，說出來。
按照上面的順序會比較清晰、快速地描述清楚線上bug。讓聽眾能夠快速瞭解到影響，和處理方式。
描述清楚線上bug是每個程式員都要必備的能力之一，也是日常經常遇到的場景。掌握先交代背景和影響，再說明錯誤原因和如何預防，是一種行之有效的描述方法。
延伸閱讀
通用的方法論可以學習《金字塔原理》《問題的分析與解決》中的SCQA、MECE等方法，這些才是根本，要努力學習和刻意練習才能夠掌握。