“閑居少鄰并,草徑入荒園。鳥宿池邊樹,僧敲月下門。過橋分野色,移石動云根。暫去還來此,幽期不負言。”賈島為琢磨這首《題李凝幽居》,也不管交通法規,騎驢闖了官道。對于全詩只有一處拿不定主意,那就第二句中的“僧敲月下門”的“敲”是否應換成“推”。可他又覺著“推”不太合適,不如“敲”好。不知是“敲”還是“推”好。嘴里就推敲推敲地念叨著,也不管屁股下的毛驢往那里走,結果那毛驢也不認識什么大官小官,就直奔韓愈的儀仗隊里,韓愈雖然官高位重,但是也是一介文人,問賈島為什么亂闖。賈島就把自己做的那首詩念給韓愈聽,但是其中一句拿不定主意是用“推” 好,還是用“"敲”好的事說了一遍。韓愈聽后對賈島說:“我看還是用‘敲’好,去別人家,又是晚上,還是敲門有禮貌呀!而且一個‘敲’字,使夜靜更深之時,多了幾分聲響。再說,讀起來也響亮些”賈島聽了連連點頭。他這回不但沒受處罰,還和韓愈交上了朋友。
賈島在唐朝被人稱做苦吟派詩人。什么叫苦吟派呢?就是為了一句詩或是詩中的一個詞,不惜耗費心血,花費工夫。賈島曾用幾年時間做了一首詩。詩成之后,他熱淚橫流。當然他并不是每做一首都這么費勁兒,如果那樣,他就成不了著名詩人了。
軟件開發和寫作在我看來,多少有點相似的味道,都是靠人腦力勞動,通過作者的想象,分析和努力,把原本憑空存在的東西變成現實。只是作家寫作可以天馬行空,筆尖上揮灑千里,隨意發揮。但是軟件開發卻需要一步一步求證,嚴謹科學。不過很多人把開發軟件也稱為寫軟件,這是因為軟件工程的開發和寫作一樣,都是一字一字的代碼堆積成每個功能,然后匯總成為系統,這和寫作基本相同。作者往往在需要反復推敲文章之后,才能寫出讓己讓人都滿意的美文。那么軟件開發呢?
當然在做軟件開發的時候,不會像賈島那樣,幾年才寫成一首詩,這樣的產量估計留給自己業余玩玩還可以,對于公司來說,這種產量估計老板會把他那張臉繃得比豬皮還緊。我們在做任何開發的時候,也是條條道路通羅馬,對于同樣的一個動作,文章中講究推和敲的意境,對于軟件來說,同一個功能,也可以用不同的方法來實現,可能有些人會把其中的公用的功能抽象出來,做成通用的函數,或許另外一些人就通過復制和拷貝來實現這種功能的復用。雖然功能都做到了,但是對于后期的維護的人,估計他對兩種方法的會有比較大的反應,搞不好還會念叨三字經,順帶拜會寫代碼人的父母長輩。
對于軟件開發中,我們的代碼其實也需要像寫文章那樣推敲,反復提煉,特別是在于團隊開發中,這種推敲工作顯得更為主要。不是說我們一個項目完成之后,我們的代碼超過十萬行,百萬行就是一個了不起的項目,其實對于如此龐大的代碼量,我們需要在興奮之余想想到底有多少的代碼是有用的代碼,有多少的代碼是值得再三提煉的代碼,而不是說這么多的代碼都是廢話,就像是海綿浸了水,擰干之后就什么都沒有。
我剛剛把面試的人送出會議室,返回到我的位置上,木子已經迫不及待地問道:“小余,剛剛那個時不時那個百萬大俠?”并用一種崇拜的眼神望著那人離去的背影,仿佛漸行離去的人就是她仰望已久的偶像。
我聽完之后搖了搖頭,說道:“不是他,他會在半個之后來。”因為項目的準備工作已經逐步開始,在前期的準備過程中,人員招聘也是非常緊迫的一個環節。畢竟想要找到一個合適優秀的人員,所花費的周期往往都比較長。昨天HR那邊送來的幾個的Senior級別的應聘者的簡歷,有些是自己投遞的,有些是他們通過獵頭找來的。在這些簡歷中其中有一份簡歷讓陣個團隊幾乎炸鍋了。
簡歷是Word的文檔,在第一頁不像一般人的簡歷那樣,先寫自己姓名和基本情況,還有一些工作的履歷情況。開頭先來了一個特別說明,其中說明有兩點,其中第一點赫然寫到:“XX油田項目曾經在半年的時間寫代碼量總共寫了100萬行代碼。”說明的第二點就是關于這個項目實現的功能說明。但是我看到這里的時候,看到100萬行代碼的時候也忍不住驚訝,心里面也不由的佩服此人,畢竟我估計還不可能在半年之內完成這么多的代碼開發工作。
“哇,100萬!”因為大師也在看應聘者的簡歷,即便平時顯得沉穩的他也不由自主的驚嘆道。
“什么100萬?”開發室中其余幾個人聽到大師的感嘆,好奇的問道。
很快,此人的簡歷被整個開發團隊的所有成員都閱讀了一遍,全部的人對他從滿了好奇和期望,都希望能夠盡快看看如此厲害的人物到底是什么樣子?時不時有三頭六背,否則怎么能夠在半年內完成如此多的代碼工作量呢?阿毛還特地計算了一下這個人每天寫代碼的數量,半年等于180天,那就是一天寫接近5600行的代碼,如果一天工作12個小時的話(確實,這樣的項目不加班不可能),1個小時需要寫460行的代碼,那么每一分鐘需要寫8行代碼。經過阿毛的計算,所有的人都覺得不可思議。結果在短時間內,沒有人都去關心這人的真實姓名,百萬大俠也就加冕給他。木子還特叮囑我說,如果明天百萬大俠來了,一定要讓她看看。
我在位置上作了議會,前臺就通知說有面試的人來了,我看了一下時間,比約定的早10分鐘。我拿著簡歷正準備和大師一起走到會議室,木子也隨后跟在我們的后頭,我笑了笑便由著她。我和大師進了會議室,面試的人已經坐在里面,木子腦袋在門口探了兩次,便回到了開發室。
我和大師一坐下來,便仔細觀察眼前的人,倒沒有三頭六倍的感覺,中等的個子,年齡和簡歷上所描述的30歲倒也相符,短短的頭發看起來顯得很精神,坐在那里喝著水,顯得神色自若,并沒有看出有緊張的樣子。
面試的開始都是流水的操作模式,他簡單地做了一個自我介紹,等他一介紹完成之后,大師便直接問到他:“你能不能說說你這個XX油田的項目?”
“這個項目是B/S的項目,其中我完成中核心的功能是報表的功能,因為對于油田項目中報表的要求比較復雜,在這個項目客戶需要實現報表的功能是報表的字段可以隨意自定義,而且我們還實現了數據正確但是不正常的數據的自動檢測和自動預警功能……”
其實他對項目的介紹是比較清晰的,他所承擔的主要是針對報表部分的功能,在這個功能上主要實現的是自己編寫報表逐漸來自定義報表模板,使用存儲過程與通用控件交互的方式實現報表的瀏覽、導出、打印等功能。對于報表來說,不同的行業對于其要求的復雜度存在的非常大的差異,如果說對于要求比較特殊的行業來說,要實現其報表絕非通過簡單的報表工具就可以實現,所以對于這部分的功能的確存在大量編碼的可能性。不過由于沒有從事過石油行業的開發工作,所以對其中的復雜度也無法度量,所以我就沒有針對為什么會有100W的代碼去深究。
而大師卻緊接著問道:“你簡歷上寫著XX油田項目曾經在半年的時間寫代碼量總共寫了100萬行代碼。我想知道你這100萬行的代碼是怎么算出來的?”
“我用工具統計出來的,大概有100W行左右。”
“這100W行的代碼都是你自己寫的嗎?”大師繼續問道。
“不是,其中30到40萬行的代碼是通過代碼生成工具生成的,還有部分的代碼是html上的代碼,所有的代碼文件都加在一起大概是100W行。”
大師沒有繼續追問了,其實到這里他大概也能憑借自己的經驗估計出來有用的代碼數量是多少,實際上利用現有的開發工具進行開發,開發工具自動生成的代碼數量也非常驚人,很多時候開發人員通過拖拖拉拉就可以生成數以萬計的代碼來,對于這部分的代碼統計出來又能夠說明什么問題呢?
其實在團隊開發過程中,我們需要時常斟酌、推敲我們自己寫出來的代碼,看看代碼的效率,代碼的復用性等等。很多時候我們需要控制代碼的量,代碼并非越多越好,如果成了老媽子的裹腳布,那只會是又長又臭。對于這樣的代碼,開發一旦進入后期,其維護的成本非常驚人。如果再10人的開發團隊中,有時候部分的功能代碼是可以通用,但是10人之間彼此獨立成章,每個人都自己對于某個功能寫一套代碼,可能由于項目缺乏標準的原因,缺乏有效的代碼注釋,開發的人也懶的去讀代碼,分析功能,就自己寫了一套;還有可能因為怕對現有的代碼進行修改,影響了其余部分的功能,所以就再寫一套代碼,這樣項目中存在的重復性的代碼就非常多。在后期維護的時候,帶來的結果是往往改了左邊丟了右邊,問題不斷的出現。
在團隊開發中,我們既要控制我們代碼的冗余,避免出現大量無效雜亂的代碼,這些代碼往往來自于開發工具的自動生成,有時候來自開發人員低效率的代碼編寫。還需要對代碼進行歸納集中,對通用性,公用性的代碼進行抽象,提取。同時還需要加強開發規范的約束。通過這些來保證代碼的質量和效率。
一個程序員一天能夠寫出來的代碼是有限的,我們既要減少他們彼此之間的重復勞動量,還需要提高他們的代碼書寫質量,如果質量能夠得到控制,那么效率就能夠提高,進而就是時間的節約。如果我們能夠從有限的時間中節約出來部分,那么項目的整體進行就是另外一番景象。
作者:Yice(小余)
本文版權歸作者所有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。

浙公網安備 33010602011771號