困在績效里的程序員們！
共 16636字，需瀏覽 34分鐘
·
2024-05-05 10:36
??導(dǎo)讀
??目錄
01
1.1 收到請回復(fù)
案例1：同事 A 習(xí)慣性的不回復(fù)，他把溝通理解為單方向的消息通報，不僅自己這么做，且也認(rèn)為別人可以這么做的，某次他在群里通知：“A DCache（注：一種存儲服務(wù)） 要更換到 B DCache，這幾個 IR（注：搜索召回平臺） 的策略需要對應(yīng)更改”。群里沒有人回應(yīng)他，而他也不覺得有問題，兩個月后，線上業(yè)務(wù)還在訪問 A DCache，而它已經(jīng)下線，導(dǎo)致線上事故。他通知消息的群是一個小群，這幾個 IR 策略的負(fù)責(zé)人都不在群里，群里的人都以為是其他人要負(fù)責(zé)跟進(jìn)的，所以沒有在群里響應(yīng)，而同事 A 自己理解為：消息沒有得到回復(fù)是正常的，我已經(jīng)通知到位。這就是忽略溝通共識造成的事故，A 同事的溝通做法，也是一種推卸責(zé)任式通知：不管你們有沒有收到，反正我是通知了，這是很不靠譜的行為。
案例2：同事 B 也有習(xí)慣性不回復(fù)的習(xí)慣，特別是在群聊中，并且認(rèn)為別人也可以這么做。某次五一長假，他在群里通知五一值班安排，僅把消息貼到群里，并 @ 了多位負(fù)責(zé)人，但沒有確認(rèn)大家是否都回復(fù)，僅是看企業(yè)微信的“已讀”，看到大家都已讀，就認(rèn)為大家都通知到了。后續(xù)某一天輪到同事 C 值班時，他沒有做值班，導(dǎo)致線上告警沒有人處理，造成事故。事后復(fù)盤時，同事 C 反饋沒有收到通知，此時同事 B 無話可說，因為同事 C 確實沒有回應(yīng)確認(rèn)他已經(jīng)收到消息，同事 B 要負(fù)值班安排不到位導(dǎo)致事故的責(zé)任。
1.2 外部依賴的處理
1. 想清楚，溝通之前先想清楚你的訴求，思考是否全面，避免溝通過程浪費對方時間；
2. 禮貌溝通，譬如：
a. 說話之前先稱呼對方，然后再描述要求，表達(dá)要有條理有邏輯； b. 如果是遠(yuǎn)程溝通，要及時回應(yīng)對方的信息；溝通效率： 當(dāng)面溝通 > 電話溝通 > IM 溝通 > 郵件溝通；
3. 時間節(jié)點，需要對方給出完成時間承諾；
4. 簽字畫押，確保大家意見統(tǒng)一之后，通過郵件或者討論群將討論結(jié)果同步；
5. 進(jìn)度跟進(jìn)，協(xié)議達(dá)成之后，接下來就是不定期地跟對方溝通，確保進(jìn)展順利，或者是將不順利的影響面降到最低；
6. 上升反饋，當(dāng)事情無法按承諾執(zhí)行，并且跟你對接的同事也無法很好地處理時（溝通不順、能力不濟(jì)、信息不足...等等多個方面原因），需要跟雙方的上級做反饋。上升反饋可能會給對接同事造成很大的壓力，這可能會影響到與該同事的下一次順暢溝通，所以上升反饋非必要不使用；
當(dāng)你找對方要時間節(jié)點時，可能會遇到：“還不知道，需要評估”、“事情太多，不好說”等等類似的無法給出時間點的情況。怎么辦呢？ a. 一般人的做法：每天問一次，類似編程里的while死循環(huán)輪詢，低效且讓人煩躁。 b. 高效人士做法：讓對方給出來什么時間點可以給出事情完成的時間點，類似編程里的事件通知，高效且有條理。
2. 外部依賴優(yōu)先，在處理工作事項時，盡量優(yōu)先處理有外部依賴的，因為這部分是最不可控的。
3. 最后，很重要的一點：即便你負(fù)責(zé)的是一個項目里的一小部分，你也需要知道整個項目的計劃節(jié)奏，這有利于你做出更有全局觀的決策。
1.3 應(yīng)對緊急故障
1. 及時響應(yīng)。首先，你告知反饋者消息我已經(jīng)收到：“收到，我們看一下?！?/span>
2. 階段性反饋。如果問題非常嚴(yán)重，你馬上通過干預(yù)工具臨時解決問題，然后再回復(fù)：“問題原因還在調(diào)查，我們先通過干預(yù)工具將問題臨時解決，避免對用戶造成更大傷害?！?/span>
3. 總結(jié)反饋。case 解決之后，你再回復(fù)：“case 已經(jīng)解決，case 現(xiàn)象是......，case 原因是......，case 解決情況是......” 。
4. 轉(zhuǎn)出。如果這個 case 你調(diào)查之后發(fā)現(xiàn)是其他人的問題，你應(yīng)該把球傳給他，并給他提供必要的信息幫助。
1. 看到反饋不管不顧：他大概沒辦法成為我們的同事。
2. 看到反饋之后：悶頭干活，快速地修復(fù) case，然后再到群里回復(fù)：“case 已經(jīng)解決.....”。 做事無交代，大家都在干著急。
3. 看到反饋之后：馬上回復(fù)“收到，我們看一下”，然后發(fā)現(xiàn)不是自己的問題，私下把問題丟給了另一位同事，導(dǎo)致大家一直不知道事情進(jìn)展。做事無回音，大家都在干著急。
4. 這位同事及時響應(yīng)，也階段性反饋，但是最后總結(jié)反饋的時候，沒有給反饋者一個合理的預(yù)期，譬如：什么時候解決 case？這里解決的是一個 case 還是一類 case？
1.4 如何組織多人會議
1.4.1 常見的錯誤
1. 臨時起意，并且特別強(qiáng)調(diào)是某位領(lǐng)導(dǎo)參加的會議，未經(jīng)預(yù)約的會議容易失敗，也會給其他人的工作計劃造成干擾
2. 沒有日程，會議沒有加入到參會者日程，導(dǎo)致參會者時間做了其他安排
3. 沒有會議議題，導(dǎo)致參會者無法決策到底需不需要參加，可能會浪費大家時間
4. 只是例行的信息傳遞，寫郵件或者文檔即可搞定的
5. 會議修改通知不到位，會議議題、參會者、參會時間等信息的調(diào)整沒有及時同步修改
6. 沒做好參會人挑選和會議控場，導(dǎo)致參會者雖然參會了，但心不在會議上，坐在會議室里寫代碼或者刷手機(jī)
1.4.2 會前
（1）組織者自審
會議的目的是什么？ 會議有哪些議題，分為幾個階段？ 哪些人必須全程參與，哪些人只需要部分參與？ 參會者需要準(zhǔn)備什么？ 會議是必須線下還是線上？是否需要預(yù)定會議室？
（2）組織者預(yù)約會議
1. 時間：沒有提早發(fā)出會議預(yù)約；會議有多個主題，沒有針對多個主題排時間；本次分享是否真的需要 1 個半小時？ 2. 人物：哪些人需要參與？必要參會者混在一長串文本中，不利于參會者快速的了解到； 3. 議題：會議主題的表達(dá)沒有條理邏輯，一長串的介紹內(nèi)容混在一起，主題容易分散，不利于只想?yún)⒓硬糠种黝}的參會者，參會者也沒辦法快速了解到他能獲得什么； 4. 重點不突出：本次分享重點在于給大家介紹怎么高效的使用，“反饋、改進(jìn)”之類的話跟本次分享無關(guān)，沒必要提。
（3）提早發(fā)出會議材料
建議會議材料需要提早發(fā)出，可以填寫在會議的描述中，也可以放到群聊的公告中。提早發(fā)出材料可以讓參會者有時間先做閱讀和思考，有利于縮短會議時間，特別是項目需求評審、技術(shù)方案評審的文檔材料，應(yīng)該提早發(fā)出，并提醒參會者先做文檔批閱，可以大幅度提升評審效果和會議效率。
（4）會議調(diào)整
會議目的、議題、參與人、材料、時間、地點等任何可能影響到參會者的信息修改，都應(yīng)該及時修改預(yù)約日程，并確保參會者收到信息。
1.4.3 會中
（1）參會人。組織者要確保必要參會人必須出席，同時也避免臨時拉人入會。如果會中才發(fā)現(xiàn)某個關(guān)鍵環(huán)節(jié)缺少參會者，應(yīng)該擱置該項討論，待下次再約或者小范圍約聊。也盡量在會前做好充足準(zhǔn)備，避免在會議中才發(fā)現(xiàn)缺參與者。
（2）控場。組織需要做好控場，確保會議圍繞主題展開，避免偏航、避免陷入某個細(xì)節(jié)導(dǎo)致浪費集體的會議時間。
（3）記錄。組織者需要指定會議記錄人，確保達(dá)成的結(jié)論和待辦事項不會遺漏。
錯誤案例：
在會議中間發(fā)現(xiàn)缺少某位必要參會者，于是臨時電話他入會。這會打斷他的工作安排，很不禮貌，并且他沒有提早做準(zhǔn)備，可能參會效果不佳。
在多方參與的匯報會議上討論技術(shù)細(xì)節(jié)、在排期 PK 會議上討論需求實現(xiàn)細(xì)節(jié)等等。這些細(xì)節(jié)只需要少數(shù)人參與，應(yīng)該在線下或者其他小型會議上對齊，避免浪費他人時間。
1.4.4 會后
會議結(jié)束后，記錄者需要立刻總結(jié)并在溝通群中或者郵件發(fā)出會議紀(jì)要，內(nèi)容包括：會議達(dá)成的結(jié)論、待辦事項及其負(fù)責(zé)人等，同時應(yīng)再次和參會者確認(rèn)紀(jì)要文字內(nèi)容無錯誤、無遺漏。
到此會議全流程就結(jié)束了，待辦事項可能會在后續(xù)的會議中繼續(xù)跟進(jìn)，或者是線下逐個處理，不管是哪種方式，都需要有人執(zhí)行、有人檢查驗收。
1.5 如何處理大量的溝通消息
我們有各種途徑去找某位同事，我們也被各種途徑觸達(dá)。當(dāng)面、電話、郵件、企業(yè)微信、微信，企業(yè)微信群里還有大量的群聊說著不同的事情。大量的溝通消息，我們既擔(dān)心處理不及時，又不想寫代碼被頻繁打斷，還擔(dān)心忘記答復(fù)，怎么辦呢？
首先不要逃避消息轟炸，這是無法回避的，應(yīng)該正視并接受這種狀態(tài)，然后設(shè)計流程解決問題。下面這套流程供參考：
1.5.1 設(shè)定響應(yīng)的頻率
（1）需要立刻響應(yīng)的：
- 當(dāng)面，當(dāng)面找到你，肯定需要立刻響應(yīng)，但如果當(dāng)時時間不允許，確認(rèn)緊急程度后可以另約時間；
- 電話，打電話的一般是緊急情況，需要立刻響應(yīng)；
- 微信，通常工作事項都在企業(yè)微信上溝通，如果微信找你，是緊急情況，需要立刻查看，但如果有些同事組建了溝通日常業(yè)務(wù)需求的微信群，則建議做通知屏蔽，然后定期查看；
（2）短周期定期檢查的通訊工具：
企業(yè)微信和微信，定期檢查溝通消息，如果可以馬上答復(fù)處理的則馬上處理，否則給對方答復(fù)表示消息收到，同時標(biāo)記為待辦。企業(yè)微信和微信的待辦記錄通常是置頂。
（3）每天檢查數(shù)次的通迅工具：
郵件，郵件通常不是需要高優(yōu)響應(yīng)的信息，可以在每天的固定時間點處理，譬如：上午到工位時、下午干活之前、離開公司前。
1.5.2 記錄待辦事項和處理
1.5.3 郵件分類
1.6 避免低效率的追問式溝通
在協(xié)作過程中，我們經(jīng)常遇到需要咨詢別人或者答復(fù)別人的情況，不同水平的協(xié)作者在這里會表現(xiàn)出不同的特征。
例子 1：
A 向 項目負(fù)責(zé)人承諾完成某個需求，今天接近 deadline。
● 負(fù)責(zé)人：明天能不能完成需求？
● A ：不能。
● 負(fù)責(zé)人：遇到什么困難了？還需要多久？
例子 2：
某天在群里聊到業(yè)務(wù)有異常。
● 負(fù)責(zé)人：服務(wù)有超時監(jiān)控嗎？
● A 回答：有。
● 負(fù)責(zé)人繼續(xù)追問：超時了嗎？
例子 3：
某天在群里聊到業(yè)務(wù)有異常。
● 負(fù)責(zé)人：服務(wù)有超時監(jiān)控嗎？
● A 回答：沒有。
● 負(fù)責(zé)人繼續(xù)追問：能加上嗎？
分析：
- 例子 1 中，項目負(fù)責(zé)人的溝通訴求是：A 按期完成，如果不能按期完成，請給出一個合理的理由以及新的排期。
- 例子 2 和 例子 3 中：負(fù)責(zé)人的溝通訴求是：有超時監(jiān)控，那就給出數(shù)據(jù)；沒有超時監(jiān)控，那應(yīng)該給出能加上的監(jiān)控時間。
- 上述 3 個例子，A 在首次回答時，就應(yīng)該把對方的核心述求回應(yīng)出來，讓對方不需要在這個問題上再次提問。如果 A 不了解對方的核心訴求時，也可以在回答的同時做反問。
總結(jié)：
溝通過程中，需要多想一步：對方的訴求是什么，避免在一個簡單問題上陷入不斷追問的低效率溝通中，當(dāng)無法滿足對方訴求時，也應(yīng)該給對方一個預(yù)期。
1.7 群聊的基本常識
1.7.1 大群和小群
1.7.2 群聊是集體溝通
很多人可能會說，誰不知道群聊是集體溝通呢？而據(jù)我觀察，很多人并沒有理解什么叫做“集體溝通”。舉個例子：小 A 在群里問小 B 一個問題，小 B 覺得這個問題不適合在群里溝通，于是私聊小 A 解答，這時候群聊記錄就停留在小 A 提問題，而沒有人解答。按照“群聊是集體溝通”這個定義，小 B 應(yīng)該在群聊中做出回應(yīng)，譬如答復(fù)：“已私聊解決”。
群聊不只是溝通雙方或者多方，還有大量的相關(guān)人在，為提高效率和避免誤解，應(yīng)當(dāng)確保群聊信息是完整的。潛在的誤解：“小 B 這人做事不靠譜，有人提問也不答復(fù)”、“這個問題我也關(guān)注，咋沒有人答復(fù)，我再問一次”、“這個事情不重要，群里問題都沒人解答”....
1.7.3 必要的總結(jié)陳述
你是否有遇到這種情況：某個群里聊了幾十上百條聊天記錄，他們好像達(dá)成了某個結(jié)論，或者暴露了某個問題，你想了解到底是什么，需要看幾百條聊天記錄。
突然被拉入到某個群里，附帶了幾十條聊天記錄，拉你的人還說，“@xxx，看看這個問題”。你心里想，“臥槽，你就不能總結(jié)一下？”。這是不禮貌的行為，我說的是拉你進(jìn)群的人。
對于溝通許久的群聊，建議做總結(jié)陳述，一方面確保溝通者意見一致，另一方面也讓閱讀者可以減少爬樓，提升效率。
1.7.4 有針對性的 @ 人
你有沒有發(fā)現(xiàn)，當(dāng)你 @all 的時候沒有人理你，當(dāng)你 @某個人 的時候，他才會答復(fù)你？ 在大多數(shù)需要集體承擔(dān)的場景都是如此，小時候上課時，老師提問，回答的志愿者總是稀缺甚至沒有，點名是高效獲得回答的解決辦法。當(dāng)你在群聊里想要高效獲得答案時，@某個責(zé)任人 是最有效的，避免 @all。
1.8 在對抗中產(chǎn)出最佳決策
每個都在捍衛(wèi)自己的目標(biāo)，項目管理者要趕在 deadline 之前完成項目，開發(fā)者要確保做出高質(zhì)量產(chǎn)品。
反面案例：
A：這個功能下周一必須上線
（B 知道這個功能至少要到下周五才能做完，但他還是答應(yīng)了）
B：好的，我試試
下周一到了，功能帶著很多 bug 上線，最終不得不回滾，給產(chǎn)品口碑造成傷害。這個案例合理的做法是，B 要盡力去爭取更多的開發(fā)時間或者是功能做減法，而非簡單地答應(yīng)或者說“不”。
如果 B 輕易地答應(yīng)，那么可能之前 B 的工時預(yù)估過于寬松，這是不靠譜的表現(xiàn)。但更可能的情況是 B 做出了錯誤的承諾，導(dǎo)致功能無法符合預(yù)期地上線。如果 B 粗暴地拒絕，又可能給人一種“不善協(xié)作”的標(biāo)簽，因此最合理的做法應(yīng)該是結(jié)合工作計劃（注：靠譜的程序員必須做工作計劃），有理有據(jù)地給出拒絕理由，最終產(chǎn)品經(jīng)理和工程師達(dá)成對產(chǎn)品最有力的協(xié)議，可能是功能做減法，也可能是另外約定一個上線時間。
1.9 基于事實的討論
避免陷入偏執(zhí)，辯論應(yīng)該基于事實。我在做評審、需求溝通的時候，有時候會陷入長時間的討論，很重要的一個原因是被評論者有了情緒，不是基于事實在做討論，而是基于情感。
反面案例1：
代碼評審人：這個成員變量應(yīng)該在構(gòu)造的時候就判斷有效性，不應(yīng)該在每一個成員函數(shù)里去判斷空，這會有性能浪費。
代碼開發(fā)者：防御編程，就應(yīng)該判斷空。
開發(fā)者不正面回應(yīng)“性能浪費”這個關(guān)鍵點，轉(zhuǎn)而引用不合適本場景的“原則”做詭辯，合理的討論應(yīng)該正面回應(yīng)對方的論證，而不是回避對方的論證轉(zhuǎn)而討論其他。
反面案例2：
借用幾年前的一個代碼評審案例：
案例中的開發(fā)者明顯有情緒，陷入了偏執(zhí)。他沒有正面回應(yīng)評委提出的建議，反而去討論無關(guān)緊要的筆誤，以及后續(xù)進(jìn)一步去討論評委行為背后的動機(jī)，其實評委的動機(jī)很簡單，就是為了讓代碼更好，開發(fā)者卻認(rèn)為評委在攻擊他。我和你講道理，你和我講情感，沒法聊。
反面案例3：
需求評審人：你要開發(fā)的這個需求，是真實的用戶需求嗎？有沒有對用戶的日志做分析？
需求提出者：還沒有做分析，我作為一名資深的用戶，有深刻的體會，這個需求做了一定有很大價值。
需求提出者在感性的表達(dá)需求的合理性，感性確實容易打動人心，但我們更希望看到基于數(shù)據(jù)的理性討論，即便他說的是對的，也應(yīng)該想辦法在數(shù)字上能證明自己是對的。感情可以騙人，但數(shù)字不會，基于理性和數(shù)字，可以降低風(fēng)險。
02
2.1 權(quán)利與責(zé)任
從你為產(chǎn)品寫的第一行代碼開始，你便是這個產(chǎn)品的創(chuàng)造者，這是權(quán)力也是責(zé)任。產(chǎn)品成功或者失敗，都有你的一份功勞，靠譜的程序員從來不會讓自己“置身事外”。
有時候，我們會看到一些推卸責(zé)任式的話語，“這是產(chǎn)品經(jīng)理 A 要加的挽留用戶彈窗”、“我們領(lǐng)導(dǎo)說要用 C++ 來寫業(yè)務(wù)代碼”...... 就好像在說：“這都是他們做的錯誤決策，和我沒關(guān)系”，但你不發(fā)聲就表示你認(rèn)可這個方案，不能說都是他們的錯誤?？孔V的程序員會“置身事內(nèi)”，他們會積極參與方案的決策討論，他會表達(dá)自己不一樣的想法，并在和其他人的辯論中，得到最佳方案。
大多數(shù)情況下，我們都有充分討論的環(huán)境，如果充分討論之后，無法通過邏輯推導(dǎo)達(dá)成共識，那么我們可以更完整的說：“我并不認(rèn)同這個方案，但誰也無法說服誰，最后領(lǐng)導(dǎo)拍板決策，事實證明我的想法更合理。”
如果極端情況下，遇到無法討論又頻繁決策錯誤的“一言堂”團(tuán)隊，這樣的團(tuán)隊不適合靠譜的程序員，應(yīng)該盡快洞察到這一點并離開。
2.2 批判性思考
作為獨立思考的創(chuàng)造者，在評審需求、架構(gòu)、代碼時，都會先自問一句：“它應(yīng)該是這個樣子嗎？”，然后去思考它最合理的設(shè)計。下面舉幾個例子。
2.2.1 例子1：告警郵件的設(shè)計
在做搜索中臺 XSearch 項目早期，我們的告警通過郵件發(fā)出（后來修改為企業(yè)微信群），當(dāng)時離線系統(tǒng)開發(fā)同事設(shè)計了郵件告警，樣例如下：
這個郵件告警的標(biāo)題設(shè)計不合理。我們看郵件，首先看到的是標(biāo)題，點擊之后才看到內(nèi)容。這個告警標(biāo)題無法讓閱讀者快速得知是哪個業(yè)務(wù)有告警，我們服務(wù)了上百個業(yè)務(wù)，不同業(yè)務(wù)有不同的關(guān)注人，每個告警都需要點開之后才能看到是哪個業(yè)務(wù)，效率太低。修正后樣例：
優(yōu)化后的版本，看標(biāo)題即可知道是哪個業(yè)務(wù)出了問題，且標(biāo)題內(nèi)容亦不會長到難以閱讀。
2.2.2 例子2：監(jiān)控看板的設(shè)計
我們?yōu)樗阉髦信_ XSearch 設(shè)計了一個看板，可以直接展示歷史存量數(shù)據(jù)，而實時數(shù)據(jù)則需要跳到 007 監(jiān)控頁面（現(xiàn)在的伽利略監(jiān)控），我們決定在看板上增加一個跳 007 監(jiān)控頁面的快鏈。前端開發(fā)同事給的第一版樣式如下：
操作步驟：
1. 鼠標(biāo)移動到頁面右側(cè)
2. 點擊“監(jiān)控”快鏈
3. 鼠標(biāo)移動到頁面中間
4. 下拉選擇“地區(qū)”
5. 鼠標(biāo)往下移動幾厘米
6. 點擊 007 監(jiān)控鏈接
這一系列操作時間不長，最終也能實現(xiàn)目標(biāo)，但很繁瑣，我們可以做得更簡單。
優(yōu)化后的樣式：
優(yōu)化后的操作步驟：
1. 鼠標(biāo)移動到頁面右側(cè)
2. 點擊地區(qū)快鏈
減少了用戶多次鼠標(biāo)點擊和移動操作。這不僅僅是體驗的優(yōu)化，更是保持極致追求的態(tài)度?？梢渣c擊一次鼠標(biāo)完成的事情，不要點擊兩次，即便是一秒鐘的優(yōu)化，也是值得的。
2.2.3 例子3：微服務(wù)和單體服務(wù)的思考
22年底，我們團(tuán)隊接手并重構(gòu)一套經(jīng)過多次交接的數(shù)據(jù)接入和處理系統(tǒng)，之前也在《騰訊云開發(fā)者》公眾上分享過《微服務(wù)回歸單體，代碼行數(shù)減少75%，性能提升1300%》，這次重構(gòu)最大的一個改造點是從微服務(wù)服務(wù)改造為單體服務(wù)。微服務(wù)設(shè)計這些年在后臺系統(tǒng)架構(gòu)上得到廣泛應(yīng)用，我們很容易去講它的合理性，但也自問一句“忘記微服務(wù)和單體服務(wù)的斗爭，我們系統(tǒng)這么設(shè)計是合理的嗎？”，很快我們就聯(lián)想到，我們老系統(tǒng)有大量的服務(wù)間數(shù)據(jù)一致性容災(zāi)處理，進(jìn)一步還能想到一個需求拆分到多個服務(wù)去實現(xiàn)帶來的人力消耗。最后我們判斷，微服務(wù)帶來的好處無法抵消它的代價，前人的設(shè)計是錯誤的，我們需要一個單體服務(wù)。
我們的設(shè)計也不是一次成型，最初開發(fā)同事給的新設(shè)計方案是兩個服務(wù)，又經(jīng)過一番批評性思考和討論之后，大家才達(dá)成共識，只需要一個服務(wù)。
靠譜的程序員會捕捉心靈中稍縱即逝的叛逆，去思考它的本質(zhì)，去解答它應(yīng)該是什么樣子。另外，還有一點需要注意，有時候：“自由思考比暢所欲言更重要。”——《黑客與畫家》
2.3 系統(tǒng)性思考
作為考慮周全的創(chuàng)造者，我們在思考問題時，想到的是這個產(chǎn)品的方方面面，它能做什么、它由哪些組成、它的使用者是誰、它依賴了誰等等，系統(tǒng)性的考慮問題，看到的是一系列的問題點，這一個個“點”組成“面”。下面舉幾個例子。
2.3.1 例子1：我們給接口調(diào)用增加了重試
某同事 A 接手一套老系統(tǒng)，在完成系統(tǒng)串講后，他在工作計劃里列了很多項優(yōu)化工作：
● 解決企業(yè)微信群的業(yè)務(wù)告警
● 數(shù)據(jù)處理從 20 分鐘優(yōu)化到 10分鐘
● 接入代碼規(guī)范和安全流水線，解決所有警告
● 接口調(diào)用增加失敗重試
● ...
從串講的 TODO 來看，確實需要做這些事情，但是總感覺哪里不對勁。譬如，為什么接口調(diào)用要增加失敗重試？看起來是為了提高穩(wěn)定性。那增加重試就能達(dá)到這個效果嗎？看起來也不是，代碼里的異常沒有捕獲，這也影響穩(wěn)定性。只看到個別優(yōu)化點，而無法全面的看待系統(tǒng)，是缺乏系統(tǒng)性思考的體現(xiàn)，這也是直覺這里不太對勁的原因。
系統(tǒng)性思考一般可以借鑒《金字塔原理》，先提出一個目標(biāo)，然后基于目標(biāo)思考需要做哪些事項，把事項窮舉出來。以“接口調(diào)用增加失敗重試”為例，這是一個事項，這個事項的目標(biāo)是“提升穩(wěn)定性”，因此我們最關(guān)鍵的目標(biāo)應(yīng)該定義為：提升穩(wěn)定性，然后基于提升穩(wěn)定性窮舉出要做的事項，調(diào)整如下：
提升系統(tǒng)穩(wěn)定性，事項拆解如下：
○ 接口調(diào)用增加失敗重試
○ 代碼內(nèi)增加異常捕獲防御
○ 接入 CI 流水線，修復(fù)代碼規(guī)范和代碼安全警告
○ ...
上述的例子是從某個事項抽象到目標(biāo)，然后再從目標(biāo)窮舉事項。有時候有經(jīng)驗的我們也可以直接正向推導(dǎo)，后臺系統(tǒng)不外乎：功能、成本、性能、效率、穩(wěn)定性這些點，把它們映射到自己的系統(tǒng)上做窮舉。
2.3.2 例子2：客戶需要一匹更快的馬
某天我在評審團(tuán)隊同事個人工作計劃的時候，發(fā)現(xiàn)有一個需求：利用多線程加速數(shù)據(jù)處理。我很奇怪，這個業(yè)務(wù)索引量很少，每半小時全量重算一次，每次只需要20分鐘，為什么要做加速呢？仔細(xì)咨詢后才知道，因為有兩個反饋：
（1）產(chǎn)品經(jīng)理反饋，數(shù)據(jù)處理太慢了，導(dǎo)致他給某游戲配置的同義詞、標(biāo)簽等干預(yù)不能及時在線上生效；
（2）合作伙伴反饋，數(shù)據(jù)處理太慢了，導(dǎo)致他配置的某游戲?qū)崟r字段（一些活動信息）需要 60 分鐘才能在線上生效；
總的來說，我們的協(xié)作方都在反饋數(shù)據(jù)處理太慢，導(dǎo)致干預(yù)不能及時生效。因此，我們的一線開發(fā)同事就去分析為什么慢，最終得到優(yōu)化思路：多個計算任務(wù)之間并行實現(xiàn)加速 50%。于是就制定多線程優(yōu)化計劃。
這是一個典型的“浮于表面”分析需求的案例，和“客戶要一匹更快的馬”類似，實際上協(xié)作方想要的是干預(yù)更快生效，而不是數(shù)據(jù)處理更快，數(shù)據(jù)處理更快是實現(xiàn)目標(biāo)的手段之一，但不是完整方案，我們只負(fù)責(zé)數(shù)據(jù)處理環(huán)節(jié)，數(shù)據(jù)到上線生效還有一系列的上線流程，只優(yōu)化個別流程并不能很好的達(dá)到目標(biāo)，并且協(xié)作方的本質(zhì)訴求是個別數(shù)據(jù)的修改能更快生效，而不是他們嘴里說的“數(shù)據(jù)處理更快”。這個需求，我們應(yīng)該是基于“怎么讓個別數(shù)據(jù)修改能更快生效”這個本質(zhì)訴求，去分析全鏈路所有流程，才能尋找到最佳的解法。
2.3.3 例子3：客戶認(rèn)為離線批量數(shù)據(jù)傳輸用 RPC 接口更好
我們團(tuán)隊負(fù)責(zé)外部數(shù)據(jù)的接入和處理，并將處理后的數(shù)據(jù)存放到 COS（云對象存儲）上，由使用方拉取。某天新的使用團(tuán)隊建議我們提供 RPC（遠(yuǎn)程過程調(diào)用） 接口，理由是 COS 用起來不方便，而 RPC 接口更靈活。我們負(fù)責(zé)對接的同事小 A，想了下覺得批量數(shù)據(jù)用 RPC 提供不方便，于是退而求其次，建議通過 MySQL 提供數(shù)據(jù)。
客戶希望用 RPC，而小 A 評估后發(fā)現(xiàn) RPC 很難實現(xiàn)，所以他建議用 MySQL。看起來好像很合乎技術(shù)方案 PK 的常見做法，大家都退一步，選擇一個雙方都能接受的方案。實際上是這樣嗎？
客戶為什么會認(rèn)為 COS 不方便，為什么會認(rèn)為 RPC 接口更適合來傳輸批量數(shù)據(jù)？小 A 沒有深入了解，便輕率地接受了客戶“COS 不方便”的結(jié)論，進(jìn)而去思考滿足客戶訴求的其他方案，這也是缺乏獨立思考、缺乏系統(tǒng)性思考的體現(xiàn)。
我們和客戶進(jìn)一步深入溝通之后，才了解到：
1. 他們團(tuán)隊較少使用 COS，而 RPC 接口用的很多，他們對外提供的檢索服務(wù)也是采用 RPC 接口實現(xiàn)的；
2. 他們認(rèn)為 COS 需要做數(shù)據(jù)完整性校驗，相比 RPC 接口工作量較大。
看起來不是 COS 不好，而是業(yè)務(wù)團(tuán)隊用得不習(xí)慣，我們再進(jìn)一步分析使用 RPC 接口或者 MySQL 存儲的不利：
1. 使用 RPC 接口來傳遞批量數(shù)據(jù)，需要考慮數(shù)據(jù)分頁，而分頁之后進(jìn)一步需要考慮數(shù)據(jù)版本，需要做不少容錯保護(hù)，復(fù)雜度較高
2. 使用 MySQL 來傳遞批量數(shù)據(jù)，在新老數(shù)據(jù)版本上也需要做較多工作，要么是數(shù)據(jù)按版本分表；要么是在一個表里增加一個版本號信息，然后需要處理同時讀寫出現(xiàn)的資源競爭?？偟膩碚f，也有一定的復(fù)雜度
相對來說，用 COS 來存儲批量數(shù)據(jù)，復(fù)雜度是最低的，最后我們還是繼續(xù)采用 COS 來做數(shù)據(jù)傳輸。
客戶提出來的解決方案，未必是最佳方案，我們應(yīng)該深入的和對方聊聊，他做出這個設(shè)計的緣由，而不是對方說要什么就是什么，單方面的信息是有限的，更多的信息匯聚才能產(chǎn)生最合適的方案。
03
盡管我期望本文可以為讀者講解什么是靠譜的程序員，但每個的人遭遇不盡相同，在成為靠譜程序員的路上，很容易有各種困惑，除了請教導(dǎo)師，還可以閱讀一些書籍，下面推薦一些我閱讀過覺得不錯，且適合所有程序員的書籍：
編程知識：《重構(gòu)-改善既有代碼的設(shè)計》
軟件工程：《Google 軟件工程》、《持續(xù)交付2.0》
溝通表達(dá)：《金字塔原理》、《一本小小的紅色寫作書》
時間管理：《高效能人士的七個習(xí)慣》、《卓有成效的管理者》
元知識：《程序員修煉之道：通向務(wù)實的最高境界》(注：第一版也不錯)、《程序員的職業(yè)素養(yǎng)》、《黑客與畫家》
-End-