Beyond Question--后端程序員的反抗（1）

要是有什么方法能省掉動腦筋這檔子真正的體力活，人們斷斷不會放過它。
--- Joshua Reynolds

目錄：

引子：

之前翻看過一本書，介紹批判性思維的。中文書名是：《超越感覺--批判性思維指南》

當時看的是英文版，僅僅是翻看了，有很多都看不懂哈哈哈。

他的英文名是 《beyond feelings-- A Guide to Critical Thinking》。

從書名，望文生義一下就是大概講要培養出一種批判性的思維，不要憑感覺。。

Beyond Question也是取自于此，就是面對一個問題的時候，不要急于去回答，因為這樣很有可能會被問題本身限定住了。

先要抽身出來，Beyond This Question超越這個問題，最后往往能發現關鍵點不在這個問題當中，方能真正解決問題。

引例1：關于買早餐

每天在早餐店買單的時候，收銀員總是會問：“要不要來杯豆漿？”
這個問題暗地里限定了兩個答案：

• 要杯豆漿
• 不要豆漿

如果收銀員換個問法：“來杯豆漿還是來碗粥？”，
問題雖然看似差不多，但限定的內容不同了，變成了：

• 要杯豆漿
• 來碗粥

小結：

不談一些關于顧客購物的心理分析，可以先做出個簡單的猜測：

用后者的問法(句式)所得出來的營業額會更佳，而這僅僅是因為一個問題的限定造成的。
如果你能Beyond Question一下，maybe你就能不會過度消費了。。。

so,進入正題，看看在日常怎么用beyond question來找到問題的真正所在。

Beyond Question--backend programmer's fight：

基本情況：

在公司，我負責的是用Python做后端.
一般是我先寫完后端的程序，調試好了后，提供接口(api)和數據給前端整合到云平臺中使用。

其中，充當產品經理的boss還要負責協調前后端的溝通。

一個新功能放到上線的系統后，bug就會隨之而來。

出現bug后，boss和前端會叫我過去。
不止一次。。。他們會大聲跟我說：

• 怎么你的程序又出錯了？你過來看報錯
• 你寫的是什么api?
• 為什么你把api端口設為10086？
• 。。。。。

一般我都會回答：

劍拔弩張的一次：

有一次趕著將新寫的漏洞掃描器上線，我寫完交付給他們之后
他們還是照舊把我叫了過去。。。

由于趕著上線，他們就急匆匆兇我：

• 你的程序出錯了！快看這是什么錯。。！
• 你寫的是什么api?怎么一下子程序就報錯了？！一下子就斷了？！。。

關鍵的地方來了，Boss和前端把問題定位在我的身上和我寫的程序上。

他們的斬釘截鐵，一開始讓我也以為是我的后端程序與數據庫那邊的問題。。

我看了下報錯，是一個socket報錯，然后趕快google了一下。

這個時候，前端覺得不關他事，就下去吃飯了，而boss覺得是我的后端程序與數據庫的問題，在一頓操作改我的代碼。。

反擊--beyond question：

查了下資料后，我beyond question，定位問題不在他們提出來的地方

然后我說：

• 問題不在后端程序的上面，而是前端在請求api的時候，等待的時間太短了，api在接受到請求后，還沒來得及處理請求，就中斷了與api的通信，這就是為什么api斷掉，然后就不能接受任務的原因了。

boss聽了后，將信將疑，繼續改我的代碼。他覺得問題還是出在后面。

結果：

最后的問題解決了，確實是前端在請求api的時候，等待時間只設置成了3s，改成8秒后，與api的通信就不會那么快就斷掉了。

當然，我的程序也有一點問題需要改，boss定位的地方還是不全錯的。

下次要談談在boss身上學到用必要性思維怎么快速解決問題。

總結：

“同一層面的問題，不可能在同一個層面解決，只有在高于它的層面才能解決。”
--- Albert Einstein

面對一個問題的時候，不要急于去回答，因為這樣很有可能會被問題本身限定住了。

先要抽身出來，Beyond This Question超越這個問題，重新定義、定位、理解問題的根源。

(這當中涉及到理解的大局觀，此處就先不展開談了。)

最后往往能發現關鍵點不在這個第一次提出的問題當中，方能真正解決問題。

未詳細談到的：

• 理解的大局觀
• 必要性思維

挖坑。。。之后填。。

關鍵詞：

• Beyond Question超越問題
• 問題的層面

參考：

• 《影響力》
• 《超越感覺》