軟體工程師所需掌握的“終極技術”是什麼?

sinchb發表於2012-10-19
軟體工程師所需掌握的“終極技術”是什麼?

轉載自51CTO部落格,作者李雲,原文連結:http://yunli.blog.51cto.com/831344/1019990

最近,我在微博上看到@程式設計師鄒欣老師發的一條微博 — “不少大學同學都有一個想法:先做幾年技術,然後做管理;也有一些同學說:我技術不行,希望直接找到一個管理的工作,就像PM那樣。請看 PM 需要什麼樣的能力:(連結略去)”。在讀這條微博的前一部分內容時,我的第一反應是:難道同學們以為做技術管理不需要很好的技術功底?剛好在此之前,我寫過《技術敏感度 — 基層技術管理者必備》一文,強調技術功底對於基層技術管理者的重要性。於是,我對該條微博評論了:“建議鄒老師建議他們好好地學一學技術,技術的精進一定會讓我們或多或少地貫通管理(掌握軟體開發的常識)。對於真要做管理的,建議他們在以後擺好心態 — 承認自己對技術的‘無知’,以及充分尊重技術人才並放權於他們”。之後,鄒欣老師幫同學們提了一個讓人深思的問題 — “技術有很多,有些技術還會過時,你具體指哪些技術呢?”某種程度上,這問題可以理解為是問:“終極技術”是什麼?


在執筆本文時,我總覺得以前寫過類似的文章。查了一下,兩年前的確以《軟體開發,到底應當學什麼?》為題寫過了一篇博文。不過,過去的兩年我又有了新的收穫,或許可以藉此機會再梳理一下自己的認識,以便與大家分享。

身處節奏很快的IT行業,軟體工程師一定希望自己在職業發展的道路上掌握“終極技術”,以便將來即使“長江後浪推前浪”仍能獲得競爭優勢。掌握“終極技術”對於我們究竟意味著什麼?深刻理解這一問題有助於我們在面對技術學習和技術選擇時不至於迷茫或人云亦云。我認為,掌握“終極技術”的最終目的不是為了能在工作中“耍酷”(“哇,這問題其他哥們都搞不定,只有我能!”),也不是為了追趕“技術潮流”(“聽說Go語言以後能替代C/C++和Java,我得趕快去學!”),而是為了高質高效地工作,因為只有這樣才能提高我們的生活品質和減少浪費(浪費可能包括奢華的青春和/或寶貴的社會資源)。

實際上,我們一生都是在工作質量和工作效率的二維座標系上“畫線”。有的人一生都難以走出低質低效的困境(比如下圖中黑色曲線所代表的人),而有的人卻能進入高質高效的殿堂(比如下圖中紅色曲線所代表的人)。

明白了掌握“終極技術”的意義,那“終極技術”究竟是什麼?會是C/C++、Java、Objective-C或Go等程式語言嗎?當一個只精通C/C++程式語言的人加入到以Objective-C為程式語言的專案上時,顯然他必須重新學習程式語言。由此看來程式語言因為對不同的專案並不具備普適性,難以擁有“終極技術”之名。對於網上不少為程式語言而打口水仗的人,我真懷疑他們將程式語言當作是“終極技術”了。一旦知曉了“終極技術”的存在,你一定會發現,其實所謂的程式語言“優劣”跟本就不是業內的大問題。如果某種語言直接導致了專案的失敗,那該語言早就絕跡了;反過來,如果某種語言直接導致了專案的成功,那世界上估計也只會有這一種語言了。因此,選擇程式語言的重點不是考究其“優劣”,而是其適用性。過分計較程式語言的“優劣”其實是不成熟的一種表現。這類人還容易犯的一個毛病是 — 生怕落後,熱衷於學習新的程式語言。請別忘了,程式語言我們無論如何也學不全,即使真有人學全了,我也懷疑他所學的只是皮毛。

“終極技術”又會是Linux或Windows這樣的作業系統平臺嗎?由於它們同樣不具普適性,所以不可能有“終極技術”之實。同樣地,.Net、ACE、QT等都不可能是“終極技術”。

真正的“終極技術”一定具有一定的普適性,能讓我們將之運用於各種不同的軟體專案。正因如此,“終極技術”具有一定的抽象性。對於軟體行業來說,真正掌握“終極技術”意味著:深刻地理解軟體(開發)的複雜性本質,並擁有有助於實現高質高效工作的行為(意識、工作習慣等)、能力(思維、業務、溝通)和方法(流程、工具、複用)。

由於“終極技術”過於抽象,使得我們不得不通過一些問題來間接感知。比如:
1)程式設計好習慣對於軟體產品的質量重要嗎?如果重要,如何讓團隊形成良好的程式設計習慣?哪些程式設計習慣算是好的?
2)軟體質量的根本是什麼?是設計,抑或測試?高質量的軟體對工程師的工作與生活又意味著什麼?
3)軟體架構師重要嗎?還是隻是個虛職?如果重要,軟體架構師需要掌握哪些技能?
4)在軟體行業具有很大影響力的CMM(軟體成熟度模型),其倡導用軟體過程的成熟度來度量組織的軟體開發能力。那為什麼通過CMM最高階別認證的組織仍會開發出質量一塌糊塗的軟體?如果你身臨其中,能發現導致這種糟糕結果的關鍵因素嗎?
5)軟體平臺與框架被廣泛地認為是高效開發高質軟體的方法,但為什麼企業運用這一方法後,平臺與框架最終卻成了一個包袱?困境的表現是什麼?什麼因素造成了這種困境?有方法避免進入這種困境嗎?
6)業內大量使用“最佳實踐”這一詞彙。真正存在最佳實踐嗎?為什麼有的“最佳實踐”在組織中卻無效?
7)……

這些問題大多是開放性的,而且不少問題既涉及管理域,又涉及技術域。面對這些問題的關鍵不在於其是否有標準答案(或許根本沒有標準答案),而在於我們是否為之痛苦過、思考過,並形成了自己的想法。要知道,這些想法就是我們在工作中面對選擇時用作決策的依據。如果從來沒有這類苦惱,很難想象我們真正掌握了“終極技術”。值得一提的是,這些問題只是基於我自己膚淺的認識所提出的,我相信讀者還有很多類似或其他的問題。

如果將軟體(開發)的複雜性比喻為一頭大象,那麼我們每一個人或許是正在摸象的又瞎又聾的人,我們窮一生通過“摸”的方式,在頭腦中構建“象”的模樣。這個比喻間接地告訴我們,“終極技術”並非是某種一成不變的內容,其中更涵蓋有每個人根據自己的閱歷所總結出來的在高質高效工作道路上成功應對困境的方法和信念。

“終極技術”一定是通過掌握象程式語言等非“終極技術”而最終掌握的,也需要我們通過經受軟體專案的痛苦磨礪去沉澱。在沒有掌握“終極技術”之前,請不要停留在程式語言專家、Linux核心專家、.Net專家這樣的光環之下,繼續探索,前面還有更大的舞臺等著你!在掌握“終極技術”的職場旅途中,我們得先認識到一點:就技術內容而言,職場首先比拼的並不是智商,而是我們的堅持與良好的工作習慣。工作中的很多道理我們都懂,但就是不能堅持做到深究,也難以通過堅持克服陋習去形成更多的好習慣。在掌握“終極技術”的道路上,我們一定會看到很多不盡人意的內容,也會面臨不少困難與挫折,即使理智上悲觀,但我們在行動和意志上一定要保持樂觀(注:Antonio Gramsci的原話是“理智上悲觀,意志上樂觀”)。

相關文章