如何成為不可或缺的人？
如何成為一個優秀的架構師？這個問題其實分為兩種情況。
1）面霸型架構師。
2）上司眼中不可或缺的人。
前面的一種，如果你做到以下兩件事，很大機率可以做到。
1）認真學習16次架構經曆，完全了解背後要解決的場景問題。
2）把裡面用到的技術及其在這些經曆中用法背後的原理搞清楚。
下面主要讨論如何成為上司眼中不可或缺的人。為什麼把這兩個問題分開談？因為面霸型架構師不一定就是上司眼中不可或缺的人。
下面講幾個筆者的真實經曆。
無關職責，幫上司解決技術難題
我工作第三年的時候，認識了一個老闆，他有個做國外外包的公司，覺得我技術不錯，一直希望我加入。不過我沒答應，隻是願意給他兼職當顧問。某個周六，他打電話給我，說他們的系統碰到一個問題，做了某一個操作後，整個頁面就會當機，怎麼點都沒有用，他們的技術人員沒有頭緒，客戶一直在催，讓我趕緊幫忙看看。
我打開看了一下，的确是做了操作後，整個界面都無法點選或輸入資訊了。然後我重制了很多次問題，發現整個界面當機的時候，好像顔色有點不一樣，會不會是一個透明的浮層置頂了？
最終确認，确實是bug造成浮層沒退出。
那麼為什麼他們的技術人員都沒有頭緒？因為他們主要是後端開發，JS經驗比較少。看了我的經曆，你應該猜得出來，其實我也是偏後端的。
可是，你可以跟上司說，這個問題不屬于我的專業範圍，因為我是做後端的嗎？
上司不在乎你的職責是什麼，老闆最喜歡的是可以幫他解決技術難題的人。
了解上司的非技術問題
再說第二個經曆，這是在外企碰到的一個問題。
有一天，公司的上司過來問我：“你有沒有覺得我們的開發速度很慢？是不是我們的技術不行？”
“您能跟我詳細說說，是哪些地方慢？”
“産品部的人跟我說，他們現在提一個需求，經常需要好幾個月才能上線，有時候一個簡單改文字的需求都是這樣。”
這個問題确實不好解釋清楚，因為這次溝通一開始就不在一個次元上。
開發人員認為，說開發速度慢，應該是指開始開發到最終上線的時間久。
可是上司認為，一個需求從提出到最終上線的時間久，就是開發速度慢。
另外，開發速度慢算是一個技術問題嗎？可以算，也可以不算。
那麼最終怎麼解決？
開發團隊一起讨論後列出了所有影響開發效率的問題，然後能用技術解決的就用技術解決。
表18-1所列為其中兩個典型問題。
表18-1 影響效率的問題
是以有時候上司跟你談的問題并不是單純的技術問題。你需要把上司的問題轉化成技術可以解決的問題。
弄清上司對你的期望值
可能有人會想，開發效率低這種事情不應該找架構師，這是管理的問題。
下面接着講第三個經曆。公司原來的系統用了4年，架構相對比較老舊。然後有一個新的項目，需求比較多。
一位架構師就提議，能不能趁着這次的需求把架構更新一下。之後，他就跟另一位負責這個項目的技術總監仔細讨論了架構更新的代價和好處，最終達成了一緻的意見。
然後，他們一起将這個提案給了CTO，向CTO陳述了新架構的好處及代價。
代價就是多花3周的時間，好處就是以後系統會更穩定，問題更少，疊代速度也會更快。
CTO是産品經理出身，爽快地同意了，然後團隊就開始了如火如荼的項目開發。
當然，任何一個項目都有各種各樣的變數。
比如業務方臨時的需求變更：他們之前沒考慮清楚，還有一部分流程的遺漏，這部分遺漏必須解決，否則系統無法使用。
再比如更新為新架構時，有些系統要遷移過來，有些系統決定不遷移，直接對接。但是開發過程中發現，原來決定不遷移的某個系統，因為資料庫耦合的原因也必須遷移。
當然，也有部分人員因為不熟悉新架構，就需要多花一點時間去學習。
最終，項目果然延期了。
某一次會議期間，CTO就說：“咱們的架構師不行啊，這次系統上線以後如果不穩定，就把他開了。”
開發這邊驚訝地問道：“為什麼？還有其他的原因嗎？”
CTO說：“你看這次項目，本來要一個半月做完，因為加了新架構的遷移工作，變成兩個多月了，現在都快拖到三個月了。這明顯是架構師的問題，早知道這樣的話，還不如不換新架構。”
然後開發這邊就幫忙解釋道：“這其實不全是架構師的問題，項目中不是還有一些需求變更嗎？”
CTO說：“我知道，但是那些需求我看了，改動不大，不至于拖期一兩個月。”
開發這邊都沉默了，心想：“當初遷移新架構，上司也是同意的。”然後在CTO離開後，開發團隊的兩個總監私底下商量，一定要保住這個架構師，不能讓他一個人擔責任。
後來一次聚餐的時候，CTO跟開發團隊解釋道，他的壓力也很大，本來跟老闆說好可以按時完成，結果拖了這麼久。關于架構遷移，老闆原來是同意的，可是第二個月他已經忘記這件事了。老闆對軟體研發沒什麼概念。
團隊事後回顧了一下，這件事情之是以是架構師擔責，其實最重要的一個原因在于：老闆對架構師的期望值是什麼？是開發效率、系統穩定性保障，還是複雜問題的突破？
而這整件事情會由架構師承擔的原因就是，大家對架構師的期望值是不一樣的。
是以我認為，作為架構師最重要的一點就是要明白公司對你的期望值。
小結
這就是我的3段經曆。當然，架構師的優秀有很多的次元可以講，以上經曆并不代表所有公司的評判标準。
不過，希望這些分享能給你一點啟發。當然，如果能夠讓你感同身受，那将是我最大的榮幸。
![微服務進階場景實戰：BFF，如何緩解服務依賴複雜度的問題？[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)