上午騎車上班的途中不只不覺又想到了“業務重要還是技術重要”這個問題。在思考的過程中不知怎的將其聯想到了Factory 方法模式。特分析如下:
“客戶“這個對象相當於是一個調用的用戶端,“公司“對象在這裡就是一個工廠,由它向用戶端返回“程式員”這個介面的具體實作類別“程式員A”或者“程式員B”。如所示:
由圖中可以分析得出:客戶對象不會直接依賴於程式員A或B這樣的具體對象,而只會依賴於程式員介面。因為它關注的是code這個編程方法。而具體的程式員只會由公司對象在程式運行時(對應此處為項目開始時)產生。 所以,對具體的程式員形成調用和依賴關係的只能是公司對象而不是客戶對象。
對於業務和技術的結合問題一般會有以下兩種做法。
做法一:
此種做法使用了專門的業務員這樣一個介面,從而讓程式員和具體的業務分析方法解藕。對於編碼和分析業務相結合的問題通過在公司對象中提供管理方法(的manage方法)來實現,當然具體的實現有可能是方法攔截或者類似模板方法什麼的辦法不一而足。這就類似於給程式員進行專門的業務培訓,而不是讓他只在編程的時候再一個需求一個需求的問,在不斷犯錯和修改的迴圈中去“精通業務”。
做法二:
在公司對象中不提供管理方法(管理很糟的公司一般如此),也沒有一個專門的業務員介面及其實作類別。至於具體的業務問題的解決只能是完全委託給程式員對象的code方法去執行,也就是在編碼的過程中去實現“分析業務”方法。當然這種做法就只能是在犯錯和改正的迴圈中去完成業務的功能。這種做法也就好比是在商務邏輯代碼中同時加入了資料庫存取碼、交易處理代碼、日誌記錄代碼等等。 很顯然這種做法在編程理論和方法日趨完善的今天已經是被廣泛的放棄並被認為是錯誤的和不當的!這也是IT解的共識。這種錯誤也只有一個剛開始學習編程的新手程式員才會去犯。
通過以上兩種方法的分析很對比,孰優孰劣就很明顯了。而我們需要從中得出的結論就是對於一個程式員來說它的核心價值就是它的編程方法而不是其他業務什麼的。如果你不這樣認為,你認為業務比技術更重要從而將主要的時間和精力花在了業務的”精通“上,那就勢必造成你在同等情況下花在技術上的時間減少。那麼同樣的情況下你就比相對在技術上花主要精力的程式員在技術上相對落後。當有一天你面對更好的機會需要再次擇業時(不能保證正好是同樣的行業)你的競爭力就會比那個程式員更差。原因如下:
1,你精通的是“具體的業務”而不是精通“靈活的很快的調用和掌握業務”的這種能力;
2,你在技術上又比別人差;
3,你採用這種方法作事情難免讓公司領導因為你的“敬業”和“認真”而對你產生技術上的寬容和具體做事犯錯的
預設(因為他們沒有提供業務培訓,而你又這麼主動的學習業務)。這樣更加深了你繼續這樣做下去成為業務的精通者的想法。
總之,一個“管理架構”設計良好能夠持續良性發展的公司會按照規範的做法和專業的思想來完成具體的事情而不是過多的寄希望於一兩個業務高手或技術高手的個人能力。這就好比良好的軟體架構設計不會讓一個類去完成太多的任務,也不會在一個方法中去作太多的事情。當然,話說回來,你可能會說我們現在就是一個才起步的小公司不可能按照你說的這種做法來做,因為我們要生存。對於這種情況我並沒有否定你的這種做法。
我只是在這裡提醒那些程式員朋友們:當你因為生活所迫的原因這樣作是沒有辦法的。但是在這樣作的同時,你一定要記住當你的管理者在向你灌輸類似於“業務重要性大於技術”或者“某某大公司也是靠這種牛人撐起來的”從而希望你內心深處認為這種做法是“正確的”是”潮流所趨“的時候 ,你在內心深處一定要明白世界其實本非必然就是這個樣子的。你的管理者要麼就是“井底之蛙”真的不明白這個道理,要麼就是為了公司的利益故意對你進行誤導。你所要作的就是搞清楚身份和“對象”,用物件導向的思維來說就是要分清楚“程式員”對象和“公司”對象是有區別的。他們具有的”方法“(職能)是不一樣的,這就好比資本家畢竟不是無產階級,無產階級不是資本家。各位看管說到這裡可能會罵我:“員工要愛企業,要有主人翁精神!你這樣是鼓吹個人主義!”。是的,員工是應該有這種精神但是這個問題又是另外一個範疇是屬於道德的範疇,員工搞清楚自己的職能並不見得非要用道德的問題來上崗上線評價他。而且安心本職工作,一頭鑽研技術的員工對公司來講也未必一定是一件壞事。相反,這正好是很多公司需要的人才。
為了生存,你可以暫時虛應它,可以裝作認同並“崇拜”它。但是你的思想觀念一定不能去認同這種錯誤的落後的觀念,以至於當真的有一個更好的機會擺在你的面前的時候因為這種觀念的原因而錯過!那才是程式員尤其是才參加工作很容易被誤導同時又需要新的發展的程式員真正的悲哀!!!