第4章 ☆、4.大神的脾氣

小江的建議得到了謝聯航的認可和采納，第二天打算繼續嘚瑟嘚瑟，尾巴剛翹起來，就被凍得縮了回去。

謝聯航來了幾天，雖算不上笑容晏晏熱情待人，臉上一直沒什麽表情，但也算不上冷淡，沒什麽架子，比想象中好相處，做事一絲不茍，只要對工作有事說事，他還是容易溝通的，當然，一句多餘的話也是沒有的。

但是今天，技術一部的人都感覺整個辦公區域氣壓特別低，每個人都收到一份郵件，是謝聯航針對每個人工作的指導意見。內容直白得讓所有人啞口無言，每個人工作中會出現的問題和工作方式的不當之處都被無情地點了出來，什麽委婉的職場術語一點都沒加，就是特別直接地列出123幾點，邏輯清楚地說明哪裏做的不好，哪裏總是出錯，要求怎麽改。

一開始這群随便拉一個出去都是大牛的技術男們都很是不服氣，但是互相看看其他人收到的郵件，不禁樂了：

“嘿，你丫就是這樣，老是脫離構架設計，每次都得老子給你善後！”

“你TM才是，幾種參數老是搞不清，英文26個字母認得不？老大說你一點都沒錯！”

“老大才來幾天就看出來你小子的問題不在編譯器上，編譯器總算是沉冤得雪了！”

“我早就想說你對版本管理太混亂了，別說我們搞不清，你自己到後面也都分不清了吧？”

“你看不懂了吧，我幫你翻一下老大的意思，你的思路太鑽牛角尖了，老想在你擅長的編程語言上做到極致，卡住了吧？換個方向馬上就容易解決了。”

……

互相揭發完同伴們的缺點，然後自己冷靜下來，再仔細看一遍謝聯航的郵件，大都都服氣地閉了嘴，除了一個人。

給小江的郵件是最詳細的(見作者有話)，而且是最不客氣的，讓咱們來概括一下：

不愛寫注釋和文檔，這都已經是老生常談了——寫你MB，三部的人不會自己看嗎？老子又不是文案策劃。

不想做測試？就要求你以後在編程之前就先寫測試——我就是不愛做測試，怎麽滴！

代碼結構、功能算法過于臃腫，必須精簡——前兩天不是說讓我完善嗎？我寫得全了又嫌我胖了？

即使客戶是SB，你也得按他的需求和産品設計做——我給他寫個SB自爆的功能，要不？

Advertisement

要和其他同事好好溝通、協作，你就是太獨了——溝通？我說的他們聽得懂嗎！協作？其他人跟得上我嗎！

命名可是門藝術，這我也不擅長，咱得準備一本詞典——老子就是取名廢！生個孩子取名字都沒這麽費勁的！

哈哈最後一條是拼寫錯誤，小江同學請準備好詞典并養成檢查作業的好習慣——滾你媽個蛋！！！

當然，謝聯航的郵件可沒這麽生動，語言刻板得讓小江越看越火大，字裏行間的嚴謹讓他有些反駁無力。前面是同事們一邊調侃一邊概括的，後面就是小江死愛面子一句句給頂了回去。他覺得謝聯航就是故意針對他，昨天差點就上當了。

“有本事你上老大桌前理論去。”小胖慫恿着。

“去就去！”

謝聯航的辦公室不像其他部門主管那樣随時關着門進入需敲門得到允許，所以小江剛轉身離開工作位，就能遠遠看到敞着門的主管辦公室裏坐在辦公桌後的謝聯航。

剛才同事們都在讨論，謝聯航今天是不是心情不好，一早就群發了批、鬥郵件，小江越走近越覺得大家分析得對，今天謝聯航的氣場的确不大尋常。

在會議上被小江公開嗆聲都淡然處之的謝聯航，這時候和往常一樣專注地伏案工作，但是雙眉緊促，臉色……有點黑。平時的謝聯航就像個機器人，冰冷、嚴謹，完全看不出喜怒和其他情緒，但是今天他的臉上就明晃晃地挂着大寫的兩個字：不、爽。

這倒讓小江有點好奇了，本來理直氣壯的腳步慢了下來，昨天謝聯航剛把大家在新方案上像光榮榜一樣點名挂了一遍，今天怎麽就不高興了？難道真是因為我們組工作太随性散漫了？還是想上任三把火？這什麽脾氣，原來木頭一樣的氣質都是裝出來的嗎？還沒琢磨出什麽來，不知不覺已經走到謝聯航的辦公桌前了，本來也就十米不到的距離。

謝聯航感覺眼前突然出現一片陰影，擡起頭見是小江，眯了眯眼問：“什麽事？”

“呃……”小江看謝聯航的臉色不僅黑，而且臉部線條和嘴角都繃得可緊，不自覺的自己的神經也跟着繃緊了，而且在他看到自己的一瞬，眼裏閃過一抹陰郁，讓小江認定謝聯航就是在針對自己，莫名有些心虛，話都堵在喉嚨裏，說不出來。

謝聯航等了一分鐘見他也沒說出什麽，眉頭擰得更緊了，開口丢下一句話：“一點去銷售市場部提案。”而後徑自低下頭繼續工作，不再搭理小江。

站在辦公桌前的小江一臉的尴尬，明明是來質問的，可是對方氣場太強大，而且一副“別惹我”又公事公辦的模樣，硬是讓他一句話也問不出了。

“不應将個人的感情因素帶到工作中”到底是誰寫在郵件裏的！？摔！就因為自己是他前任的師弟，就因為他剛來的時候我給他臉色看了？——小江重新将原因歸結在兩個人的私人恩怨上，才不承認是自己的工作問題。

下午的提案很順利，銷售市場部和産品設計部門對技術部新提出來的技術提案很滿意，不順利的是小江。

謝聯航帶了兩個人去，一個人負責闡述後臺清算系統的新技術點，提出引入移動支付，如支付寶和微信等第三方合作服務，還提出一個公共交通移動app的想法，不僅是地鐵，還将整合公交和出租車，将公共交通的實時信息、路線路況查詢、充值、支付等全都整合在一個系統裏，對大數據統計也很有幫助。這點讓産品部門很興奮，但是需要重新估算項目周期和預算。

另一個人就是小江，謝聯航讓他闡述關于前臺系統的改進時，小江一臉懵逼，他以為謝聯航帶他來只是為了充場面或是為了讓他見識謝聯航作為領導的能力的，完全不相信午飯時同事們開玩笑說謝聯航要重用他的玩笑，這哪是重用，尼瑪完全是故意讓他當衆出醜來的！

在場七八個人都等着他，小江急得在空調會議室裏直冒汗，狠狠地瞪着謝聯航，對方也沉着臉看着他，其他人一看就知道兩人似是有仇，只得呆坐在位置上不好言語，就看兩人四目之間閃着火花。

怎麽！看不起老子麽！？

“呃……那個……什麽……”小江張張嘴，腦袋裏一片空白。

“先從你的提議開始吧。”謝聯航垂眸收回目光，大方地給指了一條路，小江見他錯開了目光，也松了口氣，轉頭看向Andy他們，緊張的感覺壓下一半，說到底還是最怕在謝聯航面前丢臉，其他人給他的壓力其實還好。

“哦對！我的提議……就是……多從人性化角度考慮，簡化操作流程，改善人機交互。比如針對殘……殘疾人士，增設幾臺降低操作臺和屏幕高度的售票機，這個适用于輪椅使用者和侏儒症患者，也适用于中小學生使用；在售票機增……還有檢票機增加語音操作提示和說明、在檢票機增加語音提醒，适用于盲人和對操作不熟練的生手，還可以加入簡單的語音操作互動；……”

“還有就是……剛才說過的移動支付和售檢票機的結合應用，甚至可以直接脫離售檢票機，移動設備直接購票，從專有通道檢票入站，網絡化電子票可以逐漸替代磁卡車票，除了環保，減輕票卡調配的問題，幾乎可以解決磁卡介質的其他所有缺點……移動端還可以有即時的換乘提醒，提供跟蹤導航的無縫換乘服務……這樣終端會越來越多元化，就需要系統高度集成化，互相兼容、聯、聯程優惠、還有……跨系統結算都需要改進……”

“我的意見主要就是這些，雖然這些從技術上來說，增加這些功能并不難，也算不上什麽技術特點，但是卻很實用，能幫助更多的人……我就是這麽想的，其他……”

小江磕磕絆絆說完自己的意見，這些都是根據自己對上海公共交通的見聞和體驗想了一夜的想法，之後就掰不出別的了，其他同事的建議雖然一同列在郵件中，但是他沒仔細看，小江在桌子地下掐了自己大腿一把，幹嘛就不多看兩眼呢！

有些不甘心地轉頭看了看謝聯航，對方沒有看他，而是對着另外兩個部門的同事，直接在小江發言的基礎上重新整理邏輯，條理清楚地開始補充說明其他前端系統的改進。随後，在做的同事就技術上的難點和實現，向技術部提問，謝聯航都游刃有餘地耐心一一解答，給出明确回應。

謝聯航最後還對系統安全方面，給出了自己獨到的見解，小江聽了訝異地挑起了眉，有些地方的思路竟和[好好學習]大神以前在論壇上發表的一篇《公用設施系統安全淺談》特別相像，當時大神只是提出一個理念，大家并沒有讨論到落地應用，而現在謝聯航的見解卻比大神的理論更加完善更貼合實際應用。

真有兩把刷子？還是也混過論壇？不得不說，小江對謝聯航的邏輯思維能力确實佩服，不管這些思路是不是他自己的，能這樣整合大家的想法，而後條理清晰地闡述重點，應該也是費了不少功夫做功課。不像他，明明在寫方案的時候思路挺清楚的，分123幾點列下來，頭一回碰到在正式場合需要他當衆發言的情況，腦子裏抓到哪個關鍵詞就說哪個，最後說到哪自己都亂了。

所幸另外兩個部門的同事對他的發言似乎也挺看重，散會後，Andy還特地過來拍着他的肩說：“小江，以前你跟着你師兄，就知道你嘴貧，沒想到你這腦瓜還挺活絡，以後還有什麽有意思的想法盡管跟Sheldon說。”

難道自己以前給別人的印象其實是腦袋空空就剩下嘴巴厲害了？老子明明是實力派好不好！

作者有話要說： 小江對地鐵的改進建議是我根據自己的乘車經驗想了一夜想出來的，也許有些已經實現，有些還待改進。

－－－－－－－－－－

謝聯航寫給小江的工作改進郵件，搜了好多關于程序員工作方式的問題，整理出一些符合小江性格、他容易犯的問題，因為是從網上的資料總結的，就不放在正文裏湊字數了，整理如下：

－－－－－

1.創建用于解釋代碼和應用程序的文檔，包括獨立文檔和代碼注釋。目标人群範圍從終端用戶乃至其他後續開發人員。

2.編寫單元測試，以确保每一部分代碼都能正常運作。這些測試不但有助于在開發早期找出bug，還能方便後續的回歸測試。根據開發方法論，建議在寫代碼之前先寫好測試程序。

3.根據系列要求，設計可實施方案，包括設計數據和代碼結構、功能算法和應用程序流程。确保你設計的解決方案得滿足客戶的要求，并且按時完成。

4.摒棄個人想法和意見，竭盡全力地實現或支持功能需求。不管什麽原因，如果客戶或者産品部門同事堅持某個特性和功能，不應将個人的感情因素帶到工作中。

5.收集客戶需求，提供狀态管理報告，配合測試人員，和其他工程師協作。耐心向非技術人士解釋技術問題，必要時應無條件接受其他同事交接過來的任務，與QA或其他開發人員出現意見相左情況應理性處理。

6.為變量、過程、函數、類、對象、數據庫組件等命名，提高代碼可讀性，要求一貫、簡潔、有內涵，能明确表現功能和用意。

7.杜絕拼寫錯誤和其他低級錯誤，必要時請做檢查。

程序員從菜鳥到大神，分很多等級，小江這時候應該就是老油條吧，技術啥的沒大問題但時不時碰到瓶頸，其他就是工作态度問題。