程序員的口頭禪：技術上無法實現
「技術上無法實現」這句口頭禪，我在過去多年的程序員職業生涯中經常聽見，甚至我自己就曾說過很多次。最近當我再次聽到有人說出這句話時，就不禁思考起來，為什么程序員愛說這句話呢?為什么曾經我也時不時說這句話呢?
不知
當我剛開始工作的***年，我在一家銀行客戶現場工作。當時要給銀行的出納管理部做一個系統，這個系統有個功能就是上傳各個國家的高清真假幣鑒別對比圖片，然后銀行的出納和柜員就可以在系統上學習各國家紙幣的鑒別方式了。
針對這些高清紙幣圖片，客戶為了怕別人盜取亂用，就要求必須對對圖片做加背景水印的功能。當我們在召開需求討論會時，我聽到這個需求就懵了，因為完全不知道要怎么做。畢竟當時我才剛剛開始學習如何做 Web 化的管理系統，從來沒有用程序處理過圖片。
彼時，當我想起程序化的圖片處理時，我就只能想起像 PhotoShop 這樣的高度專業化的圖片處理工具軟件，覺得這肯定是一個很復雜的事情。所以，當我們討論起加背景水印的功能時，我自然脫口而出：“這在技術上無法實現。”
然后我們進一步說起，當前他們是怎么做的，確實是找了專門的外包設計公司用 PhotoShop 來給圖片一張張手工加的水印。這聽起來是一個比較繁瑣的過程，所以，當我回答在技術上無法實現時，客戶都是業務人員，也不太懂程序技術上的事，聽到我的回答就略顯失望。
好吧，如今回想起來，當時我說技術上無法實現時，僅僅是我當時并不知道如何去實現。而且想當然的感覺要進行圖片處理，必須要具備像 PhotoShop 一樣的專業背景知識，而這在當時的我而言是完全不能想象的。
因此，當時我說出的那句：技術上無法實現，僅僅是因為不知和不解而心懷畏懼。
不愿
有一年，我出差在客戶現場趕項目，連續加班了四個周末，也就是大概一個月在連續上班。終于我們的項目快要如期上線了，每個通宵的早晨，看著東方慢慢變得紅潤透亮的天空，感覺已經快要看到了勝利的曙光。
就在這樣一個曙光照耀的早晨，項目經理跑來對我們說：“原有的一塊業務邏輯今天在和客戶聊起時，他們說也只是試試這個流程，可能要改變。但我們的實現方式太僵硬，都是硬編碼趕出來的。要不我們改成更靈活的可以通過配置的方式，一旦上線后再改起來就更麻煩了，我可以先去和客戶再溝通下，再給我們爭取點時間。”
一下子，我們都被打擊的不行，改成配置怎么改?邏輯那么復雜，又不是那種簡單的開關式配置。當然，項目經理早已脫離技術一線時間頗久，也一時半會兒沒啥方案。在沉默的思考了一陣后，我又說出了那句話：“邏輯太復雜，變動太大，這在技術上無法實現。”
老實說，當時我只是想趕快離開這沉默的討論會，去美美的睡上一覺。其實，那時我心里是有一個方案的，如今看來不是什么優秀的方案，只是當時我唯一知道且可行的方案。就是通過動態類加載機制，把業務邏輯外移，流程內置的方式去可以動態熱加載新的業務邏輯類。但這意味著可能面臨一次重大的重構，又是兩周的持續加班，而我當時只想睡上一覺。
后來，這個故事在我睡醒后依然以我妥協結束。我建議了這個方案，***當然也是我去實施了這個方案，沒有加上兩周班，只用了一周，然后項目上線了。再之后的后續維護中，我又學習了新的東西，流程引擎，動態腳本，然后下一版本的重構，我們做了一個更好更通用的產品。
當時我說出的那句：技術上無法實現，只是因為覺得很麻煩，不愿意而已。后來睡醒后，回了一些血，有了能量，覺得應該接受這個挑戰。因為客戶的需求變化就是一個客觀事實，也不會因為我的主觀意愿而改變。
應對
再之后，隨著工作經驗的增多，技能的積累，我便越來越少說這句話了。事實上，我發現大部分的用戶需求，技術上總是可以實現的。這些需求的真正限制，要么是時間、要么是資源。
所以，面對一個緊迫的，不合理的客戶需求，甚至訴求時，不應該再以如此蒼白的一句話去應對了。這個需求背后涉及的技術實現，要么可能你現在未知，要么你至少知道一個方案，只是覺得過于復雜，而且會帶來很多副作用，所以不愿意這樣去做。
但總之，你需要一個辦法去應對一個讓你覺得「技術上無法實現」的需求。我建議不要立刻像我當年一樣做出簡單的判斷，不如我們把這樣的問題放在下面這樣的框架中去思考下。
全局背景
在這一步的目的不是要找到并確定實現方案，只是對這一問題涉及的主題的相關內容有一個全局性的了解。近年我都在做 IM，就以此舉個例子吧。
不時會有用戶反饋在安卓客戶端應用切到后臺就會收不到消息，這里用戶只是提供了一個說法，甚至都不算現象。但這是一個問題，而且是一個我覺得在技術上無法***根除的問題，換言之就是你可能想不出一個方案能讓你的所有用戶都再也不會碰到類似的問題。用戶碰到這樣的問題可能的原因有：
- 移動弱網絡，消息投遞失敗率高
- 應用切后臺就被系統殺掉，所以收不到
- 第三方推送渠道，比如：一類用戶完全沒有這種渠道可達
- 應用本身的問題，比如：bug，版本碎片導致的兼容性問題
以上簡單的問題分類，背后都隱藏著一個解決或優化問題所需的巨大且復雜的實現方案。針對每一類問題的方案，你先去大概有個了解，但這里還不需要很深入。
聚焦范圍
上面列出的全局背景問題分析分類后，發現沒有一個是輕松容易就能解決的。而且這時你必然面臨資源和時間的問題，在特定的資源和時間下，我應該優先解決哪類?所以，這一步的本質就是從上面的全局分類中，聚焦一個范圍，然后集中深入調研評估。
定義標準
前面說了用戶僅僅反饋了一個說法，站在用戶的角度，他們總是希望沒有任何問題的。但站在我的角度，我知道我只聚焦了一部分問題，所以我需要清晰定義這部分問題的解決的成功標準。比如，針對應用切后臺就被系統殺掉，對用戶無感知，所以認為收不到消息有問題。
針對這個問題的聚焦范圍，我可以提供第三方推送渠道在十分鐘內的推送通知補償，重新喚醒用戶重回應用，避免遺漏消息。通過估算每日活躍用戶和可能投遞給第三方渠道消息通知量和第三方渠道自己標榜的投遞成功率和業界一些經驗數據，就能估算出具體的通知喚醒到底能補償多少用戶的標準。
深度評估
有了范圍和標準，剩下的就是深度評估方案路徑問題。大體上任何一個方案，其中有些是你已經輕車熟路的實現路徑，另一些則是你可能從未走過的陌生之路。
輕車熟路的部分可能更容易評估，但很多程序員還是容易高估自己，即使是在輕車熟路的部分。而從未走過的陌生之路，就經常評估的更離譜了。關于評估，我以前寫過好多了，做好日常的時間記錄，那么熟悉的部分就不會差太遠，而陌生的部分呢，只能盡可能的保守點了?，F實總是比理想的路徑曲折一些的。
而那些來自產品 MM 的各種軟語相求或激將捧殺，讓你不自覺得的頭腦一熱當場拍時間的決策，日后都會成為你沒完沒了加班的根源。
【本文是51CTO專欄作者胡峰的原創文章，轉載請聯系作者本人獲取授權】
