編程達人們在程式碼的舒適區裏沈浸久了，會以為除了程式碼其他都不重要，事實上程式碼之外的事情，占據我們很大一部份時間，卻又容易被忽略，因而高效的溝通協作、獨立的思考精神也變得難能可貴。看完本文，你可能會對怎麽開會溝通、怎麽辯論 PK、怎麽「置身事內」地參與計畫規劃等等有一些新的靈感。
一、溝通協作
溝通占據我們完成目標的大部份時間，溝通需求、反饋進度、總結進展等等。下面介紹一些常見場景的處理經驗。
1.收到請回復
收到請回復，這是一個關乎個人品牌建設的大事 。收到訊息及時回復是職場人的共識，如果你收到訊息不回復，容易給對方造成誤解，一旦你養成習慣，也容易在與人溝通上出現理解偏差。企業微信有已讀功能，當你已讀卻不回復訊息時，容易給人造成無視、忽略的誤解。你可以關掉這個功能，但讀訊息必回復的習慣建議養成並保持，也建議開啟這個功能，並塑造及時回復的形象。
下面舉兩個對共識無認知，造成事故的負面案例：
案例1： 同事 A 習慣性不回復，他把溝通理解為單方向的訊息通報，不僅自己這麽做，且也認為別人可以這麽做的，某次他在群裏通知：「A DCache（註：一種儲存服務） 要更換到 B DCache，這幾個 IR（註：搜尋召回平台） 的策略需要對應更改」。群裏沒有人回應他，而他也不覺得有問題，兩個月後，線上業務還在存取 A DCache，而它已經下線，導致線上事故。
他通知訊息的群是一個小群，這幾個 IR 策略的負責人都不在群裏，群裏的人都以為是其他人要負責跟進的，所以沒有在群裏響應，而同事 A 自己理解為：訊息沒有得到回復是正常的，我已經通知到位。這就是忽略溝通共識造成的事故，A 同事的溝通做法，也是一種推卸責任式通知：不管你們有沒有收到，反正我是通知了，這是很不靠譜的行為。
案例2： 同事 B 也有習慣性不回復的習慣，特別是在群聊中，並且認為別人也可以這麽做。某次五一長假，他在群裏通知五一值班安排，僅把訊息貼到群裏，並 @ 了多位負責人，但沒有確認大家是否都回復，僅是看企業微信的「已讀」，看到大家都已讀，就認為大家都通知到了。後續某一天輪到同事 C 值班時，他沒有做值班，導致線上告警沒有人處理，造成事故。事後復盤時，同事 C 反饋沒有收到通知，此時同事 B 無話可說，因為同事 C 確實沒有回應確認他已經收到訊息，同事 B 要負值班安排不到位導致事故的責任。
2. 外部依賴的處理
當你依賴外部同事幫你完成某個功能、或者你負責一個大計畫的某一塊時，你需要了解計畫的全貌，需要主驅動去跟對方溝通、跟進。
有幾個溝通的原則：
想清楚 ，溝通之前先想清楚你的訴求，思考是否全面，避免溝透過程浪費對方時間；
禮貌溝通 ，譬如：
a. 說話之前先稱呼對方，然後再描述要求，表達要有條理有邏輯；
b. 如果是遠端溝通，要及時回應對方的資訊；溝通效率：當面溝通 > 電話溝通 > IM 溝通 > 信件溝通；
時間節點 ，需要對方給出完成時間承諾；
簽字畫押 ，確保大家意見統一之後，透過信件或者討論群將討論結果同步；
進度跟進 ，協定達成之後，接下來就是非週期性地跟對方溝通，確保進展順利，或者是將不順利的影響面降到最低；
上升反饋 ，當事情無法按承諾執行，並且跟你對接的同事也無法很好地處理時（溝通不順、能力不濟、資訊不足...等等多個方面原因），需要跟雙方的上級做反饋。上升反饋可能會給對接同事造成很大的壓力，這可能會影響到與該同事的下一次順暢溝通，所以上升反饋非必要不使用；
一些常識：
當你找對方要時間節點時，可能會遇到：「還不知道，需要評估」、「事情太多，不好說」等等類似的無法給出時間點的情況。怎麽辦呢？
一般人的做法：每天問一次，類似編程裏的while死迴圈輪詢，低效且讓人煩躁。
高效人士做法：讓對方給出來什麽時間點可以給出事情完成的時間點，類似編程裏的事件通知，高效且有條理。
外部依賴優先，在處理工作事項時，盡量優先處理有外部依賴的，因為這部份是最不可控的。
最後，很重要的一點：即便你負責的是一個計畫裏的一小部份，你也需要知道整個計畫的計劃節奏，這有利於你做出更有全域觀的決策。
3.應對緊急故障
緊急故障並不少見，如何成熟處理，也是個人品牌建設的重點。同事在業務群裏反饋你負責的某個業務出了故障。
靠譜的反應是這樣的：
及時響應。 首先，你告知反饋者訊息我已經收到：「收到，我們看一下。」
階段性反饋。 如果問題非常嚴重，你馬上透過幹預工具臨時解決問題，然後再回復：「問題原因還在調查，我們先透過幹預工具將問題臨時解決，避免對使用者造成更大傷害。」
總結反饋。 case 解決之後，你再回復：「case 已經解決，case 現象是......，case 原因是......，case 解決情況是......」 。
轉出。 如果這個 case 你調查之後發現是其他人的問題，你應該把球傳給他，並給他提供必要的資訊幫助。
一位不靠譜的同事他的表現可能是這樣子：
看到反饋不管不顧 ： 他大概沒辦法成為我們的同事。
看到反饋之後： 悶頭幹活，快速地修復 case，然後再到群裏回復：「case 已經解決……」。做事無交代，大家都在幹著急。
看到反饋之後： 馬上回復「收到，我們看一下」，然後發現不是自己的問題，私下把問題丟給了另一位同事，導致大家一直不知道事情進展。做事無回音，大家都在幹著急。
這位同事及時響應，也階段性反饋，但是最後總結反饋的時候，沒有給反饋者一個合理的預期，譬如：什麽時候解決 case？這裏解決的是一個 case 還是一類 case？
4.如何組織多人會議
1）常見的錯誤
在日常工作中，經常見到一些不專業的會議組織者，使得會議難以成行或者效率低下。會議組織者常見的錯誤包括：
臨時起意，並且特別強調是某位領導參加的會議，未經預約的會議容易失敗，也會給其他人的工作計劃造成幹擾；
沒有日程，會議沒有加入到參會者日程，導致參會者時間做了其他安排；
沒有會議議題，導致參會者無法決策到底需不需要參加，可能會浪費大家時間；
只是例行的資訊傳遞，寫信件或者文件即可搞定的；
會議修改通知不到位，會議議題、參會者、參會時間等資訊的調整沒有及時同步修改；
沒做好參會人挑選和會議控場，導致參會者雖然參會了，但心不在會議上，坐在會議室裏寫程式碼或者刷手機。
2）會前
組織者自審
會議組織者首先需要想清楚會議的目的是什麽，是否一定要開會才能解決，會議有哪些議題，能否分階段，哪些人需要參與，是否需要全程參與，參與需要提前準備什麽事情，是否可以先做文件評審 等等。明確這些資訊之後，發起會議預約，並把會議的關鍵資訊給出。
自審要點：
會議的目的是什麽？
會議有哪些議題，分為幾個階段？
哪些人必須全程參與，哪些人只需要部份參與？
參會者需要準備什麽？
會議是必須線下還是線上？是否需要預定會議室？
組織者預約會議
組織者通常需要先拉起溝通群，溝通群方便資訊的快速同步，然後再做會議預約。預約資訊包括：時間、地點、人物、議題、參會者需做的準備。
不同型別的會議，在給參會者傳遞會議資訊上有不同的側重點，對於知識分享類會議，應該突出「參會者能獲得什麽」；對於工作協同類會議，應該突出「參會者對計畫有重大影響」。特別註意「參會者需做的準備」這一點，如果需要參會者先做文件評審，那麽預約的會議時間需要在文件發出後，預留 1~2 天時間。在預約大家的會議時間時，應先參考參會者的日程表，給出幾個可選的時間讓大家選擇，避免詢問「大家什麽時候有空」，甚至有時候可以先占住大家的日程表空閑時間，然後再詢問是否可行。
下面舉一個會議預約做得不夠好的例子：
會議預約信件錯誤示範：
錯誤的地方：
時間： 沒有提早發出會議預約；會議有多個主題，沒有針對多個主題排時間；本次分享是否真的需要 1 個半小時？
人物： 哪些人需要參與？必要參會者混在一長串文本中，不利於參會者快速的了解到；
議題： 會議主題的表達沒有條理邏輯，一長串的介紹內容混在一起，主題容易分散，不利於只想參加部份主題的參會者，參會者也沒辦法快速了解到他能獲得什麽；
重點不突出： 本次分享重點在於給大家介紹怎麽高效的使用，「反饋、改進」之類的話跟本次分享無關，沒必要提。
會議預約信件修正示範：
註：現在大家習慣用企業微信的日程預約，預約資訊可以填寫到會議的「描述」中。
提早發出會議材料
建議會議材料需要提早發出，可以填寫在會議的描述中，也可以放到群聊的公告中。提早發出材料可以讓參會者有時間先做閱讀和思考，有利於縮短會議時間，特別是計畫需求評審、技術方案評審的文件材料，應該提早發出，並提醒參會者先做文件批閱，可以大振幅提升評審效果和會議效率。
會議調整
會議目的、議題、參與人、材料、時間、地點等任何可能影響到參會者的資訊修改，都應該及時修改預約日程，並確保參會者收到資訊。
3）會中
參會人。 組織者要確保必要參會人必須出席，同時也避免臨時拉人入會。如果會中才發現某個關鍵環節缺少參會者，應該擱置該項討論，待下次再約或者小範圍約聊。也盡量在會前做好充足準備，避免在會議中才發現缺參與者。
控場。 組織需要做好控場，確保會議圍繞主題展開，避免偏航、避免陷入某個細節導致浪費集體的會議時間。
記錄。 組織者需要指定會議記錄人，確保達成的結論和待辦事項不會遺漏。
錯誤案例：
在會議中間發現缺少某位必要參會者，於是臨時電話他入會。這會打斷他的工作安排，很不禮貌，並且他沒有提早做準備，可能參會效果不佳。
在多方參與的匯報會議上討論技術細節、在排期 PK 會議上討論需求實作細節等等。這些細節只需要少數人參與，應該線上下或者其他小型會議上對齊，避免浪費他人時間。
4）會後
會議結束後，記錄者需要立刻總結並在溝通群中或者信件發出會議紀要，內容包括：會議達成的結論、待辦事項及其負責人等，同時應再次和參會者確認紀要文字內容無錯誤、無遺漏。
到此會議全流程就結束了，待辦事項可能會在後續的會議中繼續跟進，或者是線下逐個處理，不管是哪種方式，都需要有人執行、有人檢查驗收。
5.如何處理大量的溝通訊息
我們有各種途徑去找某位同事，我們也被各種途徑觸達。當面、電話、信件、企業微信、微信，企業微信群裏還有大量的群聊說著不同的事情。大量的溝通訊息，我們既擔心處理不及時，又不想寫程式碼被頻繁打斷，還擔心忘記答復，怎麽辦呢？
首先不要逃避訊息轟炸，這是無法回避的，應該正視並接受這種狀態，然後設計流程解決問題。下面這套流程供參考：
1）設定響應的頻率
需要立刻響應的：
當面，當面找到你，肯定需要立刻響應，但如果當時時間不允許，確認緊急程度後可以另約時間；
電話，打電話的一般是緊急情況，需要立刻響應；
微信，通常工作事項都在企業微信上溝通，如果微信找你，是緊急情況，需要立刻檢視，但如果有些同事組建了溝通日常業務需求的微信群，則建議做通知遮蔽，然後定期檢視；
短周期定期檢查的通訊工具：
企業微信和微信，定期檢查溝通訊息，如果可以馬上答復處理的則馬上處理，否則給對方答復表示訊息收到，同時標記為待辦。企業微信和微信的待辦記錄通常是置頂。
每天檢查數次的通迅工具：
信件，信件通常不是需要高優響應的資訊，可以在每天的固定時間點處理，譬如：上午到工位時、下午幹活之前、離開公司前。
2）記錄待辦事項和處理
如果是企業微信，待辦事項可以置頂，如果是其他途徑的待辦，可以記錄到工作日誌文件中。前面的【計劃與執行】章節建議寫個人工作日誌，既用來復盤計劃與執行，也可以用來記錄待辦事項，待辦事項需要及時處理，避免企業微信置頂過多，全都置頂就相當於沒有置頂，建議待辦事項做到日清、周清。
3）信件分類
雖然大家更喜歡用 IM 做溝通，但每天的各類通知信件還是有不少，有些需要重點關註，有些則可忽略，建議建信件過濾規則，將信件分類，譬如：組織架構調整信件、表彰信件、告警信件、工蜂通知信件、OA 系統信件 等等。
6.避免低效率的追問式溝通
在協作過程中，我們經常遇到需要咨詢別人或者答復別人的情況，不同水平的協作者在這裏會表現出不同的特征。
例子 1：
A 向計畫負責人承諾完成某個需求，今天接近 deadline。
負責人：明天能不能完成需求？
A ：不能。
負責人：遇到什麽困難了？還需要多久？
例子 2：
某天在群裏聊到業務有異常。
負責人：服務有超時監控嗎？
A 回答：有。
負責人繼續追問：超時了嗎？
例子 3：
某天在群裏聊到業務有異常。
負責人：服務有超時監控嗎？
A 回答：沒有。
負責人繼續追問：能加上嗎？
分析：
例子 1 中，計畫負責人的溝通訴求是：A 按期完成，如果不能按期完成，請給出一個合理的理由以及新的排期。
例子 2 和 例子 3 中：負責人的溝通訴求是：有超時監控，那就給出數據；沒有超時監控，那應該給出能加上的監控時間。
上述 3 個例子，A 在首次回答時，就應該把對方的核心訴求回應出來，讓對方不需要在這個問題上再次提問。如果 A 不了解對方的核心訴求時，也可以在回答的同時做反問。
總結：
溝透過程中，需要多想一步：對方的訴求是什麽，避免在一個簡單問題上陷入不斷追問的低效率溝通中，當無法滿足對方訴求時，也應該給對方一個預期。
7.群聊的基本常識
大家經常會在群裏溝通，我介紹一些溝通的常識。
1）大群和小群
群聊的一個重要用途是資訊廣播，當有多個小群時，容易導致資訊廣播遺漏，譬如：作為「數據中介」的團隊，一方面要對接合作方的資料來源，一方面要分發給下遊的數據套用團隊，如果要拉一個上下遊資訊同步的溝通群，應該把多方都拉到一起，確保有一個可以全流程線上溝通的群聊環境。而當要單獨聊一些技術細節時，則建議在開發小群中溝通，避免對其他不需要關註的人造成打擾。
2）群聊是集體溝通
很多人可能會說，誰不知道群聊是集體溝通呢？而據我觀察，很多人並沒有理解什麽叫做「集體溝通」。舉個例子：小 A 在群裏問小 B 一個問題，小 B 覺得這個問題不適合在群裏溝通，於是私聊小 A 解答，這時候群聊記錄就停留在小 A 提問題，而沒有人解答。按照「群聊是集體溝通」這個定義，小 B 應該在群聊中做出回應，譬如答復：「已私聊解決」。
群聊不只是溝通雙方或者多方，還有大量的相關人在，為提高效率和避免誤解，應當確保群聊資訊是完整的。潛在的誤解：「小 B 這人做事不靠譜，有人提問也不答復」、「這個問題我也關註，咋沒有人答復，我再問一次」、「這個事情不重要，群裏問題都沒人解答」....
3）必要的總結陳述
你是否有遇到這種情況：某個群裏聊了幾十上百條聊天記錄，他們好像達成了某個結論，或者暴露了某個問題，你想了解到底是什麽，需要看幾百條聊天記錄。
突然被拉入到某個群裏，附帶了幾十條聊天記錄，拉你的人還說，「@xxx，看看這個問題」。你心裏想，「臥槽，你就不能總結一下？」。這是不禮貌的行為，我說的是拉你進群的人。
對於溝通許久的群聊，建議做總結陳述，一方面確保溝通者意見一致，另一方面也讓閱讀者可以減少爬樓，提升效率。
4）有針對性的 @ 人
你有沒有發現，當你 @all 的時候沒有人理你，當你 @某個人 的時候，他才會答復你？在大多數需要集體承擔的場景都是如此，小時候上課時，老師提問，回答的誌願者總是稀缺甚至沒有，點名是高效獲得回答的解決辦法。當你在群聊裏想要高效獲得答案時，@某個責任人 是最有效的，避免 @all。
8.在對抗中產出最佳決策
每個人都在捍衛自己的目標，計畫管理者要趕在 deadline 之前完成計畫，開發者要確保做出高品質產品。
反面案例：
A：這個功能下周一必須上線
（B 知道這個功能至少要到下周五才能做完，但他還是答應了）
B：好的，我試試
下周一到了，功能帶著很多 bug 上線，最終不得不回滾，給產品口碑造成傷害。這個案例合理的做法是，B 要盡力去爭取更多的開發時間或者是功能做減法，而非簡單地答應或者說「不」。
如果 B 輕易地答應，那麽可能之前 B 的工時預估過於寬松，這是不靠譜的表現。但更可能的情況是 B 做出了錯誤的承諾，導致功能無法符合預期地上線。如果 B 粗暴地拒絕，又可能給人一種「不善協作」的標簽，因此最合理的做法應該是結合工作計劃（註：靠譜的程式設計師必須做工作計劃），有理有據地給出拒絕理由，最終產品經理和工程師達成對產品最有力的協定，可能是功能做減法，也可能是另外約定一個上線時間。
9.基於事實的討論
避免陷入偏執，辯論應該基於事實。我在做評審、需求溝通的時候，有時候會陷入長時間的討論，很重要的一個原因是被評論者有了情緒，不是基於事實在做討論，而是基於情感。
反面案例1：
程式碼評審人：這個成員變量應該在構造的時候就判斷有效性，不應該在每一個成員函式裏去判斷空，這會有效能浪費。
程式碼開發者：防禦編程，就應該判斷空。
開發者不正面回應「效能浪費」這個關鍵點，轉而參照不合適本場景的「原則」做詭辯，合理的討論應該正面回應對方的論證，而不是回避對方的論證轉而討論其他。
反面案例2：
借用幾年前的一個程式碼評審案例：
案例中的開發者明顯有情緒，陷入了偏執。他沒有正面回應評委提出的建議，反而去討論無關緊要的筆誤，以及後續進一步去討論評委行為背後的動機，其實評委的動機很簡單，就是為了讓程式碼更好，開發者卻認為評委在攻擊他。我和你講道理，你和我講情感，沒法聊。
反面案例3：
需求評審人：你要開發的這個需求，是真實的使用者需求嗎？有沒有對使用者的日誌做分析？
需求提出者：還沒有做分析，我作為一名資深的使用者，有深刻的體會，這個需求做了一定有很大價值。
需求提出者在感性地表達需求的合理性，感性確實容易打動人心，但我們更希望看到基於數據的理性討論，即便他說的是對的，也應該想辦法在數位上能證明自己是對的。感情可以騙人，但數位不會，基於理性和數位，可以降低風險。
二、獨立思考
1.權利與責任
從你為產品寫的第一行程式碼開始，你便是這個產品的創造者，這是權力也是責任。產品成功或者失敗，都有你的一份功勞，靠譜的程式設計師從來不會讓自己「置身事外」。
有時候，我們會看到一些推卸責任式的話語，「這是產品經理 A 要加的挽留使用者彈窗」、「我們領導說要用 C++ 來寫業務程式碼」...... 就好像在說：「這都是他們做的錯誤決策，和我沒關系」，但你不發聲就表示你認可這個方案，不能說都是他們的錯誤。靠譜的程式設計師會「置身事內」，他們會積極參與方案的決策討論，他會表達自己不一樣的想法，並在和其他人的辯論中，得到最佳方案。
大多數情況下，我們都有充分討論的環境，如果充分討論之後，無法透過邏輯推導達成共識，那麽我們可以更完整地說：「我並不認同這個方案，但誰也無法說服誰，最後領導拍板決策，事實證明我的想法更合理。」
如果極端情況下，遇到無法討論又頻繁決策錯誤的「一言堂」團隊，這樣的團隊不適合靠譜的程式設計師，應該盡快洞察到這一點並離開。
2.批判性思考
作為獨立思考的創造者，在評審需求、架構、程式碼時，都會先自問一句：「它應該是這個樣子嗎？」，然後去思考它最合理的設計。下面舉幾個例子。
例子1：告警信件的設計
在做搜尋中台 XSearch 計畫早期，我們的告警透過信件發出（後來修改為企業微信群），當時離線系統開發同事設計了信件告警，樣例如下：
這個信件告警的標題設計不合理。我們看信件，首先看到的是標題，點選之後才看到內容。這個告警標題無法讓閱讀者快速得知是哪個業務有告警，我們服務了上百個業務，不同業務有不同的關註人，每個告警都需要點開之後才能看到是哪個業務，效率太低。修正後樣例：
最佳化後的版本，看標題即可知道是哪個業務出了問題，且標題內容亦不會長到難以閱讀。
例子2：監控看板的設計
我們為搜尋中台 XSearch 設計了一個看板，可以直接展示歷史存量數據，而即時數據則需要跳到 007 監控頁面（現在的伽利略監控），我們決定在看板上增加一個跳 007 監控頁面的快鏈。前端開發同事給的第一版樣式如下：
操作步驟：
滑鼠移動到頁面右側
點選「監控」快鏈
滑鼠移動到頁面中間
下拉選擇「地區」
滑鼠往下移動幾厘米
點選 007 監控連結
這一系列操作時間不長，最終也能實作目標，但很繁瑣，我們可以做得更簡單。
最佳化後的樣式：
最佳化後的操作步驟：
滑鼠移動到頁面右側
點選地區快鏈
減少了使用者多次滑鼠點選和移動操作。這不僅僅是體驗的最佳化，更是保持極致追求的態度。可以點選一次滑鼠完成的事情，不要點選兩次，即便是一秒鐘的最佳化，也是值得的。
例子3：微服務和單體服務的思考
22年底，我們團隊接手並重構一套經過多次交接的數據接入和處理系統，之前也分享過【 】，這次重構最大的一個改造點是從微服務服務改造為單體服務。微服務設計這些年在後台系統架構上得到廣泛套用，我們很容易去講它的合理性，但也自問一句「忘記微服務和單體服務的鬥爭，我們系統這麽設計是合理的嗎？」，很快我們就聯想到，我們老系統有大量的服務間數據一致性容災處理，進一步還能想到一個需求拆分到多個服務去實作帶來的人力消耗。最後我們判斷，微服務帶來的好處無法抵消它的代價，前人的設計是錯誤的，我們需要一個單體服務。
我們的設計也不是一次成型，最初開發同事給的新設計方案是兩個服務，又經過一番批評性思考和討論之後，大家才達成共識，只需要一個服務。
靠譜的程式設計師會捕捉心靈中稍縱即逝的叛逆，去思考它的本質，去解答它應該是什麽樣子。另外，還有一點需要註意，有時候：「自由思考比暢所欲言更重要。」——【黑客與畫家】
3.系統性思考
作為考慮周全的創造者，我們在思考問題時，想到的是這個產品的方方面面，它能做什麽、它由哪些組成、它的使用者是誰、它依賴了誰等等，系統性的考慮問題，看到的是一系列的問題點，這一個個「點」組成「面」。下面舉幾個例子。
例子1：我們給介面呼叫增加了重試
某同事 A 接手一套老系統，在完成系統串講後，他在工作計劃裏列了很多項最佳化工作：
解決企業微信群的業務告警
數據處理從 20 分鐘最佳化到 10分鐘
接入程式碼規範和安全流水線，解決所有警告
介面呼叫增加失敗重試
……
從串講的 TODO 來看，確實需要做這些事情，但是總感覺哪裏不對勁。譬如，為什麽介面呼叫要增加失敗重試？看起來是為了提高穩定性。那增加重試就能達到這個效果嗎？看起來也不是，程式碼裏的異常沒有捕獲，這也影響穩定性。只看到個別最佳化點，而無法全面看待系統，是缺乏系統性思考的體現，這也是直覺這裏不太對勁的原因。
系統性思考一般可以借鑒【金字塔原理】，先提出一個目標，然後基於目標思考需要做哪些事項，把事項窮舉出來。以「介面呼叫增加失敗重試」為例，這是一個事項，這個事項的目標是「提升穩定性」，因此我們最關鍵的目標應該定義為：提升穩定性，然後基於提升穩定性窮舉出要做的事項，調整如下：
提升系統穩定性，事項拆解如下：
介面呼叫增加失敗重試
程式碼內增加異常捕獲防禦
接入 CI 流水線，修復程式碼規範和程式碼安全警告
……
上述的例子是從某個事項抽象到目標，然後再從目標窮舉事項。有時候有經驗的我們也可以直接正向推導，後台系統不外乎：功能、成本、效能、效率、穩定性這些點，把它們對映到自己的系統上做窮舉。
例子2：客戶需要一匹更快的馬
某天我在評審團隊同事個人工作計劃的時候，發現有一個需求：利用多執行緒加速數據處理。我很奇怪，這個業務索引量很少，每半小時全量重算一次，每次只需要20分鐘，為什麽要做加速呢？仔細咨詢後才知道，因為有兩個反饋：
產品經理反饋，數據處理太慢了，導致他給某遊戲配置的同義詞、標簽等幹預不能及時線上上生效；
合作夥伴反饋，數據處理太慢了，導致他配置的某遊戲即時欄位（一些活動資訊）需要 60 分鐘才能線上上生效。
總的來說，我們的協作方都在反饋數據處理太慢，導致幹預不能及時生效。因此，我們的一線開發同事就去分析為什麽慢，最終得到最佳化思路：多個計算任務之間並列實作加速 50%。於是就制定多執行緒最佳化計劃。
這是一個典型的「浮於表面」分析需求的案例，和「客戶要一匹更快的馬」類似，實際上協作方想要的是幹預更快生效，而不是數據處理更快，數據處理更快是實作目標的手段之一，但不是完整方案，我們只負責數據處理環節，數據到上線生效還有一系列的上線流程，只最佳化個別流程並不能很好的達到目標，並且協作方的本質訴求是個別數據的修改能更快生效，而不是他們嘴裏說的「數據處理更快」。這個需求，我們應該是基於「怎麽讓個別數據修改能更快生效」這個本質訴求，去分析全鏈路所有流程，才能尋找到最佳的解法。
例子3：客戶認為離線批次數據傳輸用 RPC 介面更好
我們團隊負責外部數據的接入和處理，並將處理後的數據存放到 COS（雲物件儲存）上，由使用方拉取。某天新的使用團隊建議我們提供 RPC（遠端程序呼叫） 介面，理由是 COS 用起來不方便，而 RPC 介面更靈活。我們負責對接的同事小 A，想了下覺得批次數據用 RPC 提供不方便，於是退而求其次，建議透過 MySQL 提供數據。
客戶希望用 RPC，而小 A 評估後發現 RPC 很難實作，所以他建議用 MySQL。看起來好像很合乎技術方案 PK 的常見做法，大家都退一步，選擇一個雙方都能接受的方案。實際上是這樣嗎？
客戶為什麽會認為 COS 不方便，為什麽會認為 RPC 介面更適合來傳輸批次數據？小 A 沒有深入了解，便輕率地接受了客戶「COS 不方便」的結論，進而去思考滿足客戶訴求的其他方案，這也是缺乏獨立思考、缺乏系統性思考的體現。
我們和客戶進一步深入溝通之後，才了解到：
他們團隊較少使用 COS，而 RPC 介面用得很多，他們對外提供的檢索服務也是采用 RPC 介面實作的；
他們認為 COS 需要做數據完整性校驗，相比 RPC 介面工作量較大。
看起來不是 COS 不好，而是業務團隊用得不習慣，我們再進一步分析使用 RPC 介面或者 MySQL 儲存的不利：
使用 RPC 介面來傳遞批次數據，需要考慮數據分頁，而分頁之後進一步需要考慮數據版本，需要做不少容錯保護，復雜度較高；
使用 MySQL 來傳遞批次數據，在新老數據版本上也需要做較多工作，要麽是數據按版本分表；要麽是在一個表裏增加一個版本號資訊，然後需要處理同時讀寫出現的資源競爭。總的來說，也有一定的復雜度。
相對來說，用 COS 來儲存批次數據，復雜度是最低的，最後我們還是繼續采用 COS 來做數據傳輸。
客戶提出來的解決方案，未必是最佳方案，我們應該深入地和對方聊聊，他做出這個設計的緣由，而不是對方說要什麽就是什麽，單方面的資訊是有限的，更多的資訊匯聚才能產生最合適的方案。
三、推薦閱讀
盡管我期望本文可以為讀者講解什麽是靠譜的程式設計師，但每個人遭遇不盡相同，在成為靠譜程式設計師的路上，很容易有各種困惑，除了請教導師，還可以閱讀一些書籍，下面推薦一些我閱讀過覺得不錯，且適合所有程式設計師的書籍：
編程知識： 【重構-改善既有程式碼的設計】
軟體工程： 【Google 軟體工程】、【持續交付2.0】
溝通表達： 【金字塔原理】、【一本小小的紅色寫作書】
時間管理： 【高效能人士的七個習慣】、【卓有成效的管理者】
元知識： 【程式設計師修煉之道：通向務實的最高境界】(註：第一版也不錯)、【程式設計師的職業素養】、【黑客與畫家】
作者丨吳銀光
來源丨公眾號：騰訊雲開發者（ID：QcloudCommunity）
dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]
