【2017.11.29 週三 轉載之李航博士的文章：努力成爲優秀的工程師 】

原文地址：http://blog.sina.com.cn/s/blog_7ad48fee01019xhg.html

一直在IT企業的研究部門任職，迄今經歷了三家大公司：NEC、微軟、華爲。工做都是既有基礎研究，又有產品開發。其實，這二者既有密切聯繫，性質上又迥然不一樣。前者在於發現或發明普適性的理論與方法，後者在於開發實用性的系統與工具。能夠說，前者須要的思惟方式、基本技能與素質是科學家的，然後者是工程師的。常常提醒本身的是，必定要明確在具體項目中本身到底帶着什麼「帽子」在工做，是科學家，仍是工程師？

 

曾經將如何成爲優秀科學家的體會整理成若干篇博文發表，本文談談如何成爲優秀工程師的一些心得。我認爲，作工程時應該遵循五項原則，在實際的工做中把它們做爲本身的指南。這些原則是，面對問題、解決問題，系統地解決問題，站在用戶角度看問題，以最小的代價得到最大的效益，磨在細處。這裏作一總結，供你們參考。

 

面對問題，解決問題

西方有句諺語：當手中拿着榔頭的時候，你會以爲看到的東西都像是釘子。根據本身的喜愛、特長、習慣來解決問題是工程師的大忌。作工程時最重要的是要面對問題、解決問題。可取的策略應該是探明問題的本質，弄清問題的機理，用最直接、最有效的辦法解決問題。經驗告訴咱們，拐彎抹角地解決問題，效果老是很差的。作工程時並不必定須要理論。只要可以有效地解決問題，其實什麼方法都行。「無論白貓黑貓，捉住老鼠就是好貓」在這裏也是適用的。固然有理論指導的方法每每更能抓住問題的本質，以其爲工具經常能把問題解決得更好。

 

在NEC工做時，曾參加一個天然語言研究小組的立項會議。他們建議開發語音系統來幫助用戶遙控電視機，由於如今的遙控器操做都過於複雜，不利於老人與兒童使用。用語音聲控電視，固然是很好的想法，如今仍有許多企業在進行這項應用的開發。印象特別深的是他們斷言，除了經過語音的辦法，不存在其餘解決方案。當時，我也認爲他們的想法頗有道理。不料，沒過幾個月，日本的其餘幾家電器公司推出了用編碼遙控電視的方法，更簡單、更實用。遙控器的操做主要靠數字輸入，每一個電視節目都配上一個編碼，報紙天天將編碼在電視節目欄中公佈，用戶只要輸入編碼就能夠觀看或錄製相應的節目。這件事對個人心裏產生了很大的震動，自問爲何NEC的同事們只想到天然語言這條路，而忽視了其餘路？不正是由於他們手裏拿着天然語言這個榔頭的緣故嗎？

 

系統地解決問題

動畫片《沒頭腦與不高興》描寫了兩位少年：「沒頭腦」與「不高興」。「沒頭腦」作起事來老是丟三拉四，「不高興」待人處事總愛彆彆扭扭。不久，「沒頭腦」當上了工程師，「不高興」當上了演員。「沒頭腦」設計了一座一百九十九層高的少年宮，樓建好之後，才發現忘記了設計電梯。孩子們爲了在這個大樓頂層的劇院看戲，須要帶着鋪蓋、乾糧爬一個月的樓梯，貽害不淺。其實，咱們在平常生活中也能看到很多「沒頭腦」的做品。工程師須要構建的必定是一個系統。系統必定須要全面、總體、有機的設計，不能有缺陷與差錯。切忌成爲「沒頭腦」的工程師。

 

在微軟，與唐朝暉博士等合做開發了SQL Server 2005中的文本數據挖掘功能。其中的Term Extraction工具能夠從數據庫中的英文文本中自動抽取名詞短語。這個工具的輸入一般是英文文本，看似單一，可是設計這個工具時，必須考慮處理其餘非正常輸入，應對全部可能，好比，亂碼、非英文、特殊字符、全文本大寫、不含標點符號文本，等等。記得開發團隊一塊兒構建了一張巨大的邏輯圖表，將全部可能的輸入列出，準備處理方案，力圖作到「兵來將擋，水來土掩」。這個項目確實鍛鍊了你們系統解決問題的能力。

 

站在用戶角度看問題

蘋果公司的產品，如iPad，用戶界面很是簡單、直觀與易用。聽說兩歲的兒童也能無師自通，自如地使用iPad。理由很簡單，蘋果的產品都是爲用戶着想，站在用戶的角度上設計的。正是由於如此，蘋果的產品可以獲得廣大用戶的喜好和追捧。道理雖然簡單，但咱們會發現，許多工程師在開發系統時經常作不到這一點，因此作出的東西，根本很差用。

 

在NEC參加的第一個項目是個失敗的項目。目標是開發天然語言的用戶界面，自動將用戶輸入的日語問句轉換成SQL語句，以便讓普通用戶很方便地訪問數據庫。這個項目的初衷很好，但面臨的最大挑戰是，語言的表現力極其強大，一樣一個意思，能夠有許多種不一樣的說法。開發到最後，系統只能接受受限的天然語言輸入[1]。拿給用戶使用，反饋很是差，由於對用戶來講要掌握受限的天然語言比掌握SQL語言還要困難。沒有能站在用戶的角度上考慮問題致使了項目的失敗。

 

以最小代價得到最大效益

汽車大王福特曾說：對實業家來講，一條重要法則就是儘量地，以最低的代價生產出最高質量的產品，給工人發出最高的工資。福特公司1908年出的Model T汽車價格是825美圓，當時沒有多少人可以買得起，到1924年Model T價格降到290美圓，成爲一款大衆車，在美國每兩臺售出的汽車中就有一臺是Model T。其緣由是福特公司導入了生產流水線，大大地下降了生產成本。在流水線上，Model T的零部件被標準化，維修成本也大幅降低。工程與其餘領域（如科學、藝術）的不一樣在於它必須考慮代價，包括開發的代價、推廣的代價、使用的代價、維護的代價。工程師開發系統與工具時，必須權衡效益與代價，力圖以最小的代價得到最大的效益。

 

在微軟參與了Office 0七、Office 十、Office 12  中SharePoint的開發，具體從事元數據抽取與企業搜索功能的開發。我所在的研究團隊開發了文件元數據自動抽取工具，有兩種方法實現：CRF與SVM。CRF的精度比SVM高1個百分點，但就抽取部分的代碼量而言，CRF是SVM的若干倍。找SharePoint的架構師Meyerzon商量，到底採用哪一種方法好？Meyerzon絕不猶豫地答道：固然選SVM，由於它的精度只低1個百分點，但所需開發維護的代碼量卻少得多。對產品來講，開發的代價是不能不考慮的因素。

 

磨在細處

對工程師而言，上帝就存在於細處！只有精雕細琢、潛心造做，才能作好工程項目。好的系統與工具是靠一點一滴地打磨出來的。工程師必須在實際工做中不斷磨練本身的技能，以達到手藝精湛、技術嫺熟的境地，可以像庖丁同樣遊刃有餘地解牛，像賣油翁同樣點滴不濺地倒油。

 

在NEC期間，一塊兒工做的工程開發團隊的負責人叫濱田，從他那裏學到了許多編程的技能。特別是在他指導下，開發了文本數據分析系統TopicScope中的核心算法。我不是編程高手，編程只有普通程序員水平，但同事們都說個人代碼寫得很好，條理清晰，結構合理，內容精煉。這是由於我在濱田的影響下，花了不少功夫寫代碼。對項目的設置、文件的分配都反覆斟酌，函數、變量的命名都細心推敲，對系統的執行效率都不斷優化。寫好了程序，過一段時間又拿出來檢查、評價、修改，直至不能找出毛病爲止[2]。

 

從實際工做作起

以上的原則都是簡單的道理，可是真正作好卻並不容易，可謂「知之非難，行之唯艱」。重要的是在實際工做中努力依照這些原則去作，養成成爲優秀工程師的習慣。培養本身直接解決問題，系統地解決問題，從用戶的角度解決問題，考慮效益與代價解決問題的能力。不斷提升本身的專業技能，在工做中努力作好細節。本身必定知道一些優秀的工程師，他們甚至就在身邊，把他們做爲榜樣，虛心向他們請教，學習他們的長處，不斷提升本身做爲工程師的素質和能力。另外，勇於嘗試，不怕失敗，在失敗中及時吸收教訓，總結經驗也是很是重要的。

 

結束語

有人說漢字的「工」，上面一橫表明天，下面一橫表明地，總體表示頂天立地的事業[3]。能作好工程，成爲優秀的工程師的確是一件了不得的事兒。特撰寫本文，與你們共勉。

 

---

[1] 當時尚未基於統計學習的想法，也許能夠經過大數據、統計學習的方法在必定程度上可以解決這個問題，這也是天然語言處理從此研究的一個方向。

[2] 惋惜加入微軟之後，幾乎沒有時間再寫代碼，真但願從此能作一些編程工做。

[3] 較通常的說法是，象形漢字的「工」表明工具。