劍法三套,程式設計師也能賺大錢(2) 轉

weixin_34104341發表於2020-04-07

3 設計,方法為指導
3.1   階段釋義

老李:老張,你負責的這個模組,要有分散式事務處理能力,還要能與客戶的OA系統通訊,從OA中獲取客戶資料的資料。
老張:好的。我將用EJB來實現分散式事務處理,然後開發一個專門的介面,用來與OA通訊。
老張畢業五年,是專案組的開發經理,負責完成子系統的設計,並指導其他成員完成編碼。老張從老李處獲得關於所開發的產品的需求情況,然後進行設計和分析,用UML建出模型,並生成框架程式碼,由小王等去實現。
老張屬於第二階段中人,通常工作了三年以上。此階段中人,已經完成了一定程度的技術積累。對《設計模式》、《J2EE核心模式》、《UML》等爛熟於胸,張口就是IOC(控制反轉),有事沒事也要說說AOP,最差也得是Factory、Delegate吧,你要是說不知道什麼是Facade,都不好意思跟人打招呼……
與第一階段“我能——I can do it”不同,本階段的人,特點是“我知道它能——I know It can do”,對,就是“知道它能”,至於如何去“能”,就不需要關心了。例如老張,他只需要把EJB介面定義清楚,知道有了這個介面就能完成相應的功能,至於小王如何去實現這個介面,是寫了三個類還是五個類,就不關心了。
從技術角度,追求的不再是純粹的技巧,而是方法這個層次,努力尋求正確的做事方法。即關心“怎樣才能蓋出好房子”,而不是“如何把石頭從貨車裡搬運到工地上”。用流行的話說,就是“只要方法正確,結果就會正確”。
當然,達到這個階段的人,技巧本身,通常也是很厲害的。舉個例子吧,小王要用一個開源的XML檔案比較工具,並編了個測試程式,比較a.xml和b.xml的區別,卻怎麼著都得不到正確的結果。後來老張來了,牛人根本不看JavaDoc,而是拿著XOP提供的命令列比較了a.xml和b.xml,發現結果是正確的,然後直接開啟與命令列對應的main(),檢查與options對應的API,發現小王少呼叫了一個API,加上這個API後測試程式就通過了。在這件事中,老張根本不熟悉XOP的API,但他掌握了查詢API的方法,那就是:元件或工具,都有其外在特性,通過元件或工具提供的命令列能做到的事,也一定能通過它提供的API來完成。如果不知道如何去呼叫API,對於開源軟體,看它的source code或samples中的main()即可;對於非開源軟體,看StackTrace;如果都看不出來,就放棄該軟體,選擇別家的吧。
此階段中人,也需要編寫程式,但編寫的是與業務和框架相關的核心類。所用的語句通常樸實無華,用最簡單的語句完成最複雜的功能是他們的習慣。例如,求b和c中的較大值,通常不會寫成
result=(b>c)?b:c
而是寫成
if (b>c)
result=b;
else
result=c;
因為後者更容易懂,而前者,相對生僻一些。開發經理的工作,是把產品的需求,轉變為編碼人員能理解的介面或類,並保證團隊的所有成員在理解上的一致性、無二義性,在這個前題下,簡單而又精確的語句是必然的首選。所以,如果你的經理編寫的程式,在你看來很“幼稚可笑”時,千萬不要洋洋得意。
舍小巧而用大巧,捨棄繁花似錦的程式設計細節,換取簡單穩定的框架結構,換取無二義性的交流效果……獨孤劍聖四十歲前,以玄鐵重劍縱橫天下,劍法古拙,大巧不工,就是此境界(孤獨大俠也走過彎路,30歲時用紫薇軟劍,可能是追求劍招的繁複和劍法的華麗,失去控制,最終誤傷義士)
3.2   應該做的事
該階段的人,該做可做的事非常多。須知一個完整的軟體產品的開發過程,編碼僅僅是其中的一個環節而已。作為開發經理,老張的典型工作如下:
首先充分理解需求,挑選其中20%左右的功能,結合非功能性需求,設計出系統的結構(Architecture Design)。通過邊界類、控制類、實體類的應用,分析清楚Use Case中的互動流程,然後用一系列介面來表達這個流程,最後執行各種設計模式或技巧,實現這些介面,建出UML模型,並生成程式碼框架。

除了開發經理外,你還有可能是專案經理,在中國公司,專案經理和開發經理可能都是你。學習先進的開發方法是你的必修課,什麼用例驅動開發、測試驅動開發,不管用不用,你都得知道個大概;選擇正確的開發模型也很重要,何時選用瀑布模型,何時選用迭代模型,一定不能含糊。
遵守公司的開發流程,為SQA(Software Quality Assurance)提供必需的文件和資料也是你的本職工作。如果你所在的公司尚無規範的開發流程,那麼,你要幫助公司來建立。完整的開發流程貫穿整個產品生命週期,你有可能只與其中幾個階段有關。但只要與你有關,那就要盡力去配合。
該階段的人,通常在公司中是中層幹部,執行能力是一個最主要的考核指標。你的領導,可能根本不懂程式設計,而專案組裡的小夥子們,可能無法領會領導的意圖,這時,你就是中間人,好比足球場上的中場,你的溝通能力和執行能力,將決定產品開發階段的成敗。
3.3   不應該做的事
1、儘量少程式設計。除了“核心介面、類和演算法”,不要與其它程式碼糾纏,那會使你忽視巨集觀上的問題。而且,你也不一定比小夥子們編得快。只有當小夥子們遇上困難時,你才去協助他們解決問題。
2、不輕言放棄。該階段的人,工作壓力巨大,即使他看上去什麼事也沒幹,他承受的壓力也不是編碼人員所能體會的。在壓力面前,容易失去理智,如果不注意控制自己的情緒,可能會發生一些不愉快的事。
現在的你,可以說是“到哪都能找到工作”了。當與公司、同事發生一些摩擦時,可能會“一怒而去”,這是最要不得的。因為你現在追求的,已不是“能找到工作” 了,而是“能找到體現自己價值的工作”,千里馬尚且需要伯樂來發現,換家公司就一定能受重用了?而且,不管你是否意識到,你已經學習了許多行業相關的知識,這些知識,在更換公司後,未必能用上,到新公司後,還得從頭學習——人生有幾次重來的機會?
3、戒驕戒躁。你現在已經是“有本事”的人了,加上工作壓力,難免有點脾氣。但是切記,你還沒有功行圓滿,還要“多長本事,少長脾氣”。因為你的侷限性,與你的優點一樣明顯。技術等級的提升,應該是讓你眼界更開闊,並看到了更大的差距,而不是固步自封。
4、不要迷信新技術。新技術的採用是有一定的風險的。因為技術本身,可能還不成熟。追捧新的框架可能是你的愛好。沒關係,作為愛好,是可以的,但不一定要把愛好帶到工作中來。老闆關心的是你開發出來的東西能否買個好價錢,不是看你用了多少新的Framework。你的使用者關心的,是產品的易用性、穩定性,用起來是否順手,使用者同樣不會關心你用了Tomcat還是Jetty,甚至連J2EE和.Net都不關心——如果他不需要為此購買新的硬體或者重新培訓操作員。
5、多看人文方面的書和文章。此時的你,在技術方面已經有一定的造詣了。但是不是就大功告成了呢?回答當然是“不”,你還需要補充人文方面的知識,即進行感性思維訓練。為什麼?往下看。
3.4   侷限性
你的侷限性,與優點一樣明顯。如果讓你列舉自己的優點,你可能會說:
n 我精通設計模式,能做出重用性很好的軟體
n 我對軟體工程很有經驗,能做一個好的專案經理
n 我熟悉建模工具、開發環境等,能提高開發效率
n ……
是的,這些都是了不起的能力,但是:
1、 你們公司不是研究所,不賣設計模式,也不是諮詢公司,不賣軟體工程經驗,更不是培訓機構,不對外提供“建模工具、開發環境”培訓
2、 你知道軟體是如何被開發出來的,但很少考慮是否應該開發這個產品;
3、 你不知道使用者會怎樣使用你開發的產品,你不知道使用者喜歡什麼、抱怨什麼;
4、 你不知道這個產品為公司贏得了多少利潤;
5、 ……
一句話,你懂技術,但客戶要的,並不是技術。摩托羅拉有世界上最好的射頻工程師,但為什麼手機就是賣不過諾基亞呢?因為諾基亞喜歡聽客戶的意見,而摩托羅拉喜歡聽工程師的意見。
你說:“我熱愛技術,喜歡鑽研技術,至於客戶在想啥,那不是我要考慮的問題——我甚至不知道客戶是誰”。是的,達到你今天的這個境界非常不容易,許多人工作十年也未必能象你這樣優秀,你是公司的骨幹,是同事的偶像,但是……但是……《武狀元蘇乞兒》中有一段經典對白:
洪日慶:先別走!行行出狀元!如果我沒看錯,你會是乞丐中的霸主!
蘇  燦:乞丐中的霸主?!那是什麼?
洪日慶:嗯……還是乞丐!

沒錯,乞丐中的霸主也是乞丐。你再優秀,也只是公司的中層幹部,是幹活的人中的霸主——還是個幹活的:
n 客戶給老闆發工資
n 老闆給你發工資
n 你不認識客戶,客戶同樣也不認識你
n 既然你不認識客戶,那就不知道客戶喜歡什麼、討厭什麼
n 如果有一天,你的產品讓客戶不滿意(這個概率還是很大的)
n 客戶很生氣,後果很嚴重
n 老闆請你喝咖啡,並建議你去度假,順便提醒你從外面把門關好

再來看看圈子裡:
n 沒有技術,但手裡有一堆客戶的公司,比比皆是,他們活得很滋潤。
n 沒有客戶,但手裡有一堆技術牛人的公司,很少見——都倒閉了。

現在,你知道侷限性在哪裡了吧?
“正因為你技術太強了,所以只能當乞丐中的霸主,技術恰好就是你的枷鎖”

說件真實的事吧。
某天,我奉命與一個合作伙伴交流我們的平臺產品,目的是讓對方瞭解我們的平臺並在平臺上做二次開發。交流進行得很順利,對方也跟我們籤合同了。後來,市場人員去合作伙伴處瞭解反饋意見,對方說:“你們那個xxxx太厲害了,問什麼都難不倒”。回來後,領導就不允許我參加交流了。原因是:“你可能洩密了”。
作為技術人員,我希望充分介紹自己產品的優勢,並能應付合作夥伴提出來的各種應用場景和問題。但是,從領導的角度來看,“如何滿足應用場景、如何解決問題”本身,就是商業機密,是不能亂說的。舉這個例子的目的,就是說明技術人員看問題的侷限性。
想要達到更高的層次,就要跳出技術看問題,多瞭解市場,瞭解客戶。假設孤獨劍聖陶醉於玄鐵重劍的威力,天天帶著到處亂跑,那麼他就不是劍聖,而是搬運工了。搬運工最多隻能當個中層經理,當不了高層領導。
如果想進入領導班子,與老闆一起玩遊戲,那就趕快升級吧。
3.5   進階指南
1、 跳出技術看技術
達到這個階段的人,在技術上已經“很深入”,眼中所見,盡是技術。但你們公司不是賣技術的,你們賣的是產品,是服務。所以,把你的目光從技術中解脫出來,去思考一下產品和市場層面的問題。例如:
n 市場上有同類競爭的產品嗎?
n 當前已有的產品,客戶有什麼不滿意的?
n 我做的產品應該具有什麼樣的特色?有什麼賣點?
所謂“一招鮮,吃遍天”。只要你知道客戶想要啥,並能有針對性地開發產品,客戶一定會情不自禁地給你錢。客戶都給你錢了,老闆還好意思不給你個CTO的頭銜玩玩?
2、 瞭解業務
計算機技術必須為具體的行業服務,每個行業都有自己的特定背景和業務知識。技術人員應抓住機會,瞭解這些知識。我曾在某個電信軟體公司任職三年,號稱是專案經理,開發電信網管產品。那時我整天的工作就是研究各種框架,討論各種設計模式,我眼中所見心中所想,盡是WEBStrutsHTML等一大堆計算機名詞。如果你問我“為什麼這玩意是個網管軟體,而不是淘寶易趣阿里巴巴?”我一定回答不出來。
一個公司裡面,真正值錢的東西,不是技術,而是業務知識,技術是實現業務的一種手段,是為業務服務的,主從關係,不可搞錯。
3、 加強非技術性的功夫
學書法時,老師曾說過“三分書內功夫,七分書外功夫”。這句話我一直不理解(事實上,到今天依然不理解),但把這句話用於計算機技術,卻是明白的。三分書內功夫,是計算機技術,七分書外功夫,就是非技術性的產品和市場了。
可以通過看些“不務正業”的書,來提高自己的感性思維能力,可以多看看市面上流行的《比爾蓋茲傳奇》《數字化生活》《把信寄給加西亞》等,象《誰動了我的乳酪》這種只會抱怨不會解決問題的書,就不用看了。
3.6   階段小結
適用人群:工作三年以上,上限不封
輸    入:軟體需求(請注意用詞的區別:軟體需求,而不是客戶需求,你所得到到軟體需求,是由別人收集來的,並不一定能代表客戶,如果“別人”的水平一般,錯誤理解了客戶的意圖,那麼你就等著跟他一塊倒黴吧)
輸    出:設計好的類、介面和演算法
階段目標:我知道它能——I know it can work
技術特點:注重方法,不關注程式語言細節
勝任職位:高階軟體工程師、開發經理、系統架構師等
升級祕笈:換位思維,跳出技術看問題
參考薪水:¥6000以上,¥15000以下(僅供參考)

轉載於:https://www.cnblogs.com/yc1990/archive/2012/03/08/2384858.html

相關文章