Wednesday, July 28, 2010

Elegant Code

每個Programmer,都應該是有能力分辨出一段code是否具有美感。只是有時候有人問我靠什麽去評判時,我一時無法詳細地去解釋,只能説是靠種感覺。現在仔細想來,優雅的Code應該是具有「簡潔明瞭精致有效」這八個字。

前四個字是做WhiteBox時的評判,只有Programmer在意,因爲他們看得到内部的code,他們需要clean code是因爲這樣他們可以更快速的去理解(無論是自己寫的還是別人寫的),從而能在理解基礎上快速修復或增加新的東西。

后四個字是BlockBox時的評判,User和Developer都在意,這關乎的是一個成品的表現。成品在意的是效率,就是速度與精確。而一般來説,聰明的算法與數據結構總是有更好的效率。換句話說,我們現代CPU架構的模式使得在相同標準下短小精悍的code有優勢。

這些東西說太多,也只是意會,不好理解,下面用四個例子來做更好的作説明。需要注意的是,這四段Code都是合理優秀的,裏面就算最普通的第一個也是有如教科書般經典。

 def f1(list):
string = ""
for item in list:
string = string + chr(item)
return string
 def f2(list):
string = ""
ichr = chr
for item in list:
string = string + ichr(item)
return string
 def f3(list):
return "".join([chr(item) for item in list])
 def f4(list):
return "".join(map(chr, list))

給一個相對大的list,f1-f4的運行時間分別是:
  • f1: 3.01409792928ms
  • f2: 2.99986600876ms
  • f3: 2.69300198555ms
  • f4: 1.84089493752ms
  1. f1是最正規的寫法,只要不是很performance intensive的程序,相信大多數Programmer都是這麽寫。

  2. f2只比f1相比只有一處變化,性能上也只是稍微快了一點點。因爲python的特性,當執行chr()這個function的時候,intepretor需要不斷向上回溯去找chr()被定義的地方。而f2則將local variable ichr指向了chr,避免了每個loop都要向上回溯的時間。當然,這個減少的時間微乎其微,因爲大多數compiler都會幫你優化。

  3. f1和f2還有一個地方是很浪費資源的,就是string concatenation。一般Programming初學者總是喜歡用這個方法:初始化一個empty的string,然後再把内容用+ operator粘貼在後面。這個方法在string相對小並且操作量少的情況下並無壞處。但是在上面的function裏,每個loop可能都以運行十萬計的情況下,就非常耗費資源。因爲其操作是每次重新初始化一個string在memory裏,然後把舊的string和新的string添加在一起放入那個memory位置。這樣的complexity是O(n**2)。而使用join()這個内建函數,其complexity則是O(n),因爲它一次性把所有要加的部份粘在一起。

  4. 這4個function裏面,以f4的字符數最少,但是速度提升最大的也是f4。f4比f3的改變僅僅是用map代替了for,如此小的改變獲得的效果比前兩個改變大得多。你可以把map當作是for被移到了C code裏了,唯一不好的地方是map的loop body必須得是一個function。結論就是一個program的效率最大影響的還是compiler,只要有内置相同作用的function,還是用内置的更快也更方便。

以上是我最近從http://wiki.python.org/moin/PythonSpeed/PerformanceTips所學到的小技巧,每种語言都有其類似的提升方法。

Good programming style的視覺美感不僅僅是如何format及indent,簡潔的code也總是能有更高的性能。如果要做一個更好的Programmer,光遵循書上或者老師教的好code是不夠的,優雅的code,那是必需的。

Sunday, July 25, 2010

CM娘與Agile君

一個是靦腆寡言默默在背後服務的女僕式隨從,一個是當今最灸手可热的万人迷,兩人之間又有什麽不得不說的故事呢?

CM娘,可不是Agile君專屬的天使喲!早在Agile君成爲萬人迷很久之前,CM娘就默默地在幕後耕耘了,才不在乎誰是現在的主子呢。她不為堯存,不為桀亡,管你是瀑布君,還是叠代君,都能很好的為之服務。

只是她實在太不爭太小眾了,以至人們甚至都忘記她也是IEEE Computer society所制定的SWEBOK十大技術娘之一,知名度甚至遠不如其妹妹QA娘。爲什麽呢?人們難道忘記CM娘帶來的諸多便利的服務了嗎?


其實是在於,如果說Developer衆是一輛法拉利跑車,那麽CM娘就是這輛跑車上的各種減速系統。雖然速度被控制讓人很不爽,但這能避免你車毀人亡。

所以嘛,CM娘這個女僕,並不只是單純的服務於Developer眾的喲,她同時也監督著這些小祖宗們。所以這些小少爺呀,當然會去選擇性的忽略她,讓她越不起眼就越好。


回溯結束,讓我們就來開始開始八卦一下CM娘與Agile君的故事吧!

如前所述CM娘並不為Agile君而存在,她幾乎能適應各種主子們,所以呢,這個八卦的真相就是:其實是Agile君更需要CM娘!

爲什麽呢?如上一篇所述,Agile君的特質具有更大的多變性與適應性,並且需要進行更頻繁的交付。這些都需要CM娘們更多更細心地為他打理一切,進行調控和提供管理服務。

著名的Agile君專屬八卦雜誌AgileJournal.com曾經向Agile君的粉絲們推出一份問卷,請粉絲們為CM娘對Agile君的重要性從各方面進行投票,0分爲最不重要,10分爲最重要。

下面這份圖表,就是問卷答案在各方面的平均得分

我們可以看出,其中最低的平均得分“CM娘的報告”也有6分,而整體平均線在7.5分以上,可見就算是Agile君的粉絲,也是對CM娘的重要性相當的認同哦!

也難怪CM娘的粉絲們,如其專屬的八卦雜誌CMCrossroads.com會對這兩者的關係相當瘋狂的追逐了。在他們看來,這可是麻雀一朝變鳳凰,躍上枝頭衆人羡的美事呢。


在我看來,願望是美好的,但事情都不是那麽容易的。CM娘一直都是孤獨的CM娘,她缺少與其他人在同一個氛圍進行交流的機會,她的圈子太局限太被動了。這也是爲什麽CM娘的粉絲們那麽希望兩者能結合在一起,畢竟Agile君理論上也應該是獨行俠,現在卻大受歡迎。CM娘如果能學習Agile君身上的那些讓他流行起來的元素,例如專業集群化,那麽兩者就算最終不能在一起,又有何懼呢?

Friday, July 23, 2010

The Knight bringing Agile to the Day

Agile君是誰?

傳説很久以前,有一位聖騎士對他的國王說,我們應該給人民他們所需要的,而不是我們想給他們什麽就給他們什麽。並且,與其在他們已經等了很久以後再把他們想要得到的一次性全部給與,還不如分階段按需分配,這樣他們可以更快地獲得缺需的,從而改變他們的生活,讓人民更快樂。

聖騎士他認爲國家中的人民才是真正推動各種需求的,而政府所能夠提供的價值,其核心就在於如何讓人民從這個不斷改變的世界中感知並獲得他們的價值。

這位聖騎士就是被後人稱之爲Agile君的那位,他建立了Agile騎士團,制定了騎士團的四大信條:

  1. 政績實效大於完整文檔。
    這不是說文檔不重要,只是人民更看重施政效果,而非口號、文件、以及各種上級部門所下達的各類指示。
  2. 個體互動大於工具過程。
    這也不是說工具與過程不重要,只是要讓人民進行生産並不是把他們當成無腦的機械,而是需要通過體現個人,並相互之間的互動來達到。
  3. 協同合作大於律法合約。
    只有當政府持續與人民互動時,才能減少危機的出現,才能帶給人民更多他們所需要的。
  4. 適應變化大於盲從計劃。
    能夠適應各種變化地來與人民合作及進行控制;表現出各種意見都是受歡迎、可理解、什麽時候都是有其道理的誠意。


能夠擁抱變化,接受現實生活的這種不定性,Agile騎士團通過提供方法與技術來最大限度的降低風險並增加確定性來治國,這減少了政府與人民之間的隔閡,保證了政府能夠讓人民獲得他們真正想要的。

With that, the Knight brought Agile into the day and people into the light.

--「Agile君做軟件則軟件大賣,治國則國富民強。」

Wednesday, July 21, 2010

Cloud

Cloud叔叔(右圖)與CM娘的關係?

按照之前所提到那些高人的説法:
  1. Cloud叔叔現在在更多方面進行的擴展,這必將需要更多的CM娘來協助其進行管理;
  2. CM娘通過Cloud叔叔的模式進行專業服務,這已經有許多案例,比如美麗雪梨情人港兼Market St FF旁的Atalassian就有提供CM娘專業服務的一些。
不過這兩個説法都很攀龍附鳳耶,弄得好像CM娘硬要和Cloud叔叔扯上關係似的。Cloud叔叔這種類型的新概念的普及,何時不是需要各種不同的技術娘來多多支持呢?
充其量,CM娘也只是獲得了更多打雜的地方而已嘛,在這方面電腦軟硬諸界以及下屬各領域的情況其實是差不多的才對。

而第二點則更是無稽,Cloud叔叔的這種服務概念,連小狐狸都自稱家裏的視頻共享也是其中一種,IT大千世界又有哪方哪面會應用不上呢?


在我看來,Cloud叔叔對CM娘來説最大的幫助,就是讓本來大多時間都是單獨勞作的CM娘們有更多可能性在一起工作,因爲那些提供Cloud叔叔的應用公司需要好多CM娘而非一個的說。

而其他組織大多數會因爲有了這種通過Cloud叔叔來提供服務的CM娘,就不再需要那種聘請一兩個CM娘來為整個公司提供各項服務的模式了。因爲被外包了,公司内部的Development Services將不再需要,剩下操控的部分則可能被整合入管理裏面(這就給了CM娘與Agile君親近的機會,當然這是後話)。

這種服務專業化的模式是大勢所趨,畢竟CM娘這種缺稀且需求不大的技術娘,無法像Developer眾經常可以通過討論交流來增強自己。大部分CM娘都是獨立工作,最多有事找找Google大神,很少能有互相交流提高的機會。有時候就算去一些CM娘大聚餐、High派對之類的,也都是聼彼此說一些誰不知道你媽是女的之類的東西,再喝喝酒,劃劃拳,讓人無法感知到半點Inspiration。

像Thoughtworks那樣,專業服務專業化,被包的公司可以得到更專業更有效率的服務,而各專業人才之間也經常可以交流,並且可以有渠道在不同行業不同公司提供技術性服務與咨詢,從而更大化的獲得知識,真是美哉!

Monday, July 19, 2010

Cloudy with a chance of Agility

到底我的job title是要換成SCM Engineer,還是Configuration Anaylst,亦或仍是Build Engineer,都尚不可知。但我已覺得CM(Configuration Management)是那麽的無聊,枯燥且缺乏變化。上手之後的大部份時間都是重復性勞作,缺乏創意與巧思的動力不禁讓我懷疑自己還敢這樣做多久。

不過,既然無法在短期(半年内)轉爲C++ developer,那麽秉著幹一行愛一行的原則,還是把本職做精了,做神了,至少做出成果,做出實績再説。既不跳出圈外,我就需要在圈内求變化。

首先要和一些先進性名詞挂上鈎,比如Cloud,Agile什麽的IT新抱,能拉多近拉多近。

Cloud云云,本來就是和IT所有東西可能有關的概念,最近連MS都趁熱打鐵推出了Windows Azure。我貼個近乎,也就是走走過場,理所當然不在話下。

至於Agile,以我敏銳的預判本能,早在半年多前就看到了CM和Agile之間不可分割的聯係,兩者的水乳交合,在公在私,正是大勢所趨。剩下的只是我將如何推進此跨時代的轉型?

Agile的書,看了不少;公司新的Dev Manager,也是Agile正統科班出身,正把這些信條步步帶入三樓。只是這些無論理論還是實踐的玩兒,聞之見之,都只覺是空泛之辭,難覺其妙,無法讓我有那種Programming時見到巧妙算法解決難題時候的興奮。

或者Engineering的東西就是這樣,按班就步,條條有理,不興奮,但穩妥。可悲的是這十分適合我的區域,卻讓我興趣缺缺。性格如此,興趣卻非如此,豈不奇哉怪也!

在這樣十字路口,需要的是高人指點迷津,沒有更多知識來獲取,那就需要前人的經驗。CM這貨,本來就是靠著經驗吃飯的活。

於是乎我上網查詢有關資料,想找一些高人的Blog來觀摩Follow。正好,讓我逮着了http://cmforagile.blogspot.com/,這也是爲什麽我會建此Blog,因爲我follow了人家的blog嘛!沒登陸是無法follow的,既然登陸了就順便建了。順藤摸瓜,又摸到了http://www.cmcrossroads.com/,與其連接或下屬的http://www.cmwiki.com/

於是乎,歷史的車輪又再一次滾動了起來,但在此之前讓我先去FF Market St.!