天若有情

發信人: AtomAndBit (原子與比特), 信區: DotNET
標  題: 從招聘的角度談程序員應具備的能力
發信站: 水木社區 (Mon May 23 22:44:14 2005), 站內
昨天寫的，覺得寫得不怎么樣，沒敢發。今天索性發了吧。別笑俺。
從招聘的角度談程序員應具備的能力
今天實在太暈了.這幾天面試了3個人了,這3個人都是科班的,一個大專,兩個大本,大本中
的一個還考上了軟件工程碩士.我的考題很簡單,就是寫一個類,計算平面中2點間距離,注
意類的設計和編碼風格.我暈,一個都沒寫出來!第一個人不知道兩點間距離怎么算.第二個
人寫出來這樣的東西:
Class Distance
{
        double distance = ......;
}
這也叫類,真服了.
第三個回答更干脆,不會.他用c用的多,我讓他用c寫一個.寫出來這樣的:
int Dis
{
        d = ......;
}
不傳參,不return.
真郁悶,這究竟是什么世道.感嘆之下,感覺需要寫一些東西,從招聘者的角度談談程序員(
中國程序員!)應該具備什么樣的素質,希望對即將踏上程序路上的人或剛踏上的人有點幫
助.
一般來說,單位招聘人都有一個定位,一般可分為售前,技術支持,項目經理,系分,高級開發
人員,一般開發人員.咱就不談售前，技術支持，俺在這方面沒話語權。招項目經理關鍵是
信任，對個人項目管理能力還有對個人自身做人的信任，這個談起來江湖成分就比較多了
。系分的關鍵是對業務和技術兩方面的理解能力，還有溝通能力，這個俺也沒資格談，因
為俺不是合格的系分。俺就從俺的經歷談一下高級開發人員和一般開發人員所應該具備的
素質和能力。
什么是高級開發人員。俺這么認為，給一個某個方面的需求，高級開發人員應該是能夠提
出一個有效的解決方案，能夠獨立或者帶幾個人實現這個方案的人。這個需求不是項目級
別的需求，而是更具體一些的問題，比如關鍵類的設計，關鍵服務的設計，根據需求設計
對數據庫進行邏輯設計和物理設計等等。這種人應該對某一領域的技術知識有很深入的了
解，對程序執行流程有很深入的理解，還應有閱讀文檔、撰寫文檔的能力。一般開發人員
應該能夠在高級開發人員的指導下，能夠編寫規范的代碼，能夠完成代碼的實現與部署。
俺從2個故事談起吧，俺經歷過的。當然，這些故事中俺也有問題，俺就不在這里做自我
批評了。
第一個故事，1個哥們。C#還行。一次俺交代了一個任務，盡快做出一個只有2－3個頁面
小網站的Demo。然后俺就去玩我自己的去了。過了兩小時，俺估摸著差不多了，去看看，
還在干呢。又過了1個小時，俺再去看，剛弄好一個頁面。俺一看代碼，嚇偶一跳，雖然
只有一個頁面，但是類就有七八上十個。他用上了領域模式！！實體類都搞了好幾個。問
為什么。他說他剛看過一些網上優秀項目的源代碼，覺得別人寫得特別好。問題是，他看
的那個網站數量級和俺要求做的這個是一樣的嗎？俺還只要做Demo，就用上了領域模式，
只因為這是好的設計。結果他爽了，俺不爽。第一，問題沒解決，第二，進度太慢。俺才
不關心Demo的性能、可擴展性和可維護性呢。這樣的人，在工作中，只能當一般程序員用
，就不能當高級程序員用。
第二個故事，這次是2位，A和B。是Linux下的C++開發。A的C++，Linux狂牛。B的C++，
Linux僅僅會用，但是具有一定的領域知識。俺Linux剛會用。因為系統是要給一般人用的
，俺想弄一個界面出來。這個任務交給了A。A咣咣咣折騰了1周，出來了1個界面，實現了
一點點功能。具體怎么實現的？我的媽呀，底層設計得很龐大，按照他這種設計，到項目
結束，他恐怕就做不了幾個頁面。俺對性能沒什么要求，他也知道的，干嘛不用快速開發
語言呀。俺只好出手了，俺聽說Python在Linux下開發界面很快，俺一邊學一邊編，搞了
一下午，沒搞定。放棄，不玩這個，太靈活。俺又聽說.net在linux下有個mono，俺也不
知道怎么樣，一番調研，可行。現學現用，GTK#+mono，安裝用了3小時，編程用了3小時
，俺就編出來個和他那一樣的東東。B呢。B的特點是編的程序錯誤百出，幾乎沒編過什么
完全正確的程序。但是，B的思路，B的框架是對的，盡管B編的程序跑出來的結果全部是
錯誤的。從我的角度看，B可以做高級程序員用，而A則只能做一般程序員用，盡管A的OS
，C++狂牛，而B的狂爛。俺是讓A做B的助手，B有什么程序上的問題和需求讓A來解決。A
自己編的代碼，到最后用上的只有2個函數。而B的代碼則成了整個框架的基礎。
現實點講，用人和被用的關鍵就是有需求和有應用價值。就拿第一個故事的哥們來說，你
技術倒是鍛煉了，但是你解決了什么問題？我不贊成用技術學習的態度去工作。道可道，
非常道。能學習到的東西的價值始終是有限的。比如，等你把領域模式學好之后，能夠干
些大的項目了，但是此時，大項目各方面的工具都很成熟了，建模工具，ORMAP，什么的
，別人需要的又是對需求、業務和過程的把握能力的人。你干的活，機器都能干，要你干
嘛？能查找得來的東西最沒價值。領悟出來的東西才是最有價值的。從用人單位的角度來
看，它需要的是能夠解決問題。而技術只是解決問題的手段之一。平臺是技術的一種。語
言是能夠操作平臺的工具。必須有所區別，有所把握，有所輕重。如果你能夠解決問題，
你什么技術都不會都沒關系。比如一個門，用麻繩纏得亂七八糟，你要進屋必須解開麻繩
，費了9牛2虎的力解不開，別人拿一把刀，一下就把繩子剁了。他的解決問題的能力就比
你高。你如果理解一個平臺的話，你什么語言不會都沒關系，你只要能夠指揮別人完成你
指定的任務就行了。而如果你只會語言，對平臺不了解，對問題領域也不了解，那么，你
能干啥？茴香豆的茴字有幾種寫法有什么意義？還有的，過分依賴工具，知道斧頭是劈柴
的，而且也能夠劈開柴，但是，某一天，一個木頭沒批開，他就不知道怎么辦了。
具體來說，我覺得一個一般的程序員應該具備這樣的能力：
1，熟悉至少一個工具
2，熟悉平臺中的某一塊，熟悉一門語言，能夠承擔一些具體的任務。
3，還得有些基礎吧。不能工具玩的團團轉，離了工具啥都干不了。連一個最簡單的類都
寫不了。
一個高級程序員應該具備：
1，精通1門語言和1個平臺，熟悉多種工具、語言、平臺，能夠通過對比研究選擇合適的
方案
2，熟悉OO，UML
3，對問題域有一定的了解，熟悉至少1種軟件開發過程
4，比較強的分析問題、解決問題的能力
從學習的角度來說，也不能什么都學習，什么流行學習什么。市場規律最基本的一條就是
什么多了就貶值。俺個人的體會是：
1，從流程的角度來學習。比如，你如果從CLI層面搞清楚了一個Hello world程序的執行
流程，搞清一個ASP.Net頁面的執行流程，了解整個過程中發生了哪些調用操作，就很不
錯了。
2，從橫向的角度來學習。也就是學習平臺的結構，了解類庫哪一部分哪一部分是干啥的
，能干啥，不能干啥，常用的多留意留意。一個平臺通了，其它的都很簡單。
3，用比較的眼光來學習。俺覺得2個以上類似的東西對比學習效果比較好，主學一個，副
學一個，先學一個，后學一個，比如，你學.net，可以適當看看java。windows的看看
unix/linux。這樣作最大好處是思考問題的思路不會狹窄，不會盲目迷信工具，不會盲目
迷信平臺，不會盲目迷信，會明白可選工具的優點和缺點，會慢慢培養出一種對解決方案
的洞察力，會開始具備決策的能力，具備trade-off的能力。你不對方案的優缺點掌握，
就不會總是選擇出好的方案。具有方案選擇能力的人和不具有選擇能力的人不是一個量級
的。