Posted on 2008-10-09 23:58
dennis 閱讀(3075)
評論(4) 編輯 收藏 所屬分類:
涂鴉 、
計算機科學與基礎
Ruby的創造者為《代碼之美》撰寫的文章標題是《代碼如散文》。程序和散文有一些共性，首先是兩者都必須有清晰的意圖，散文內容是什么，想表達什么，程序的功能是什么，能做什么；其次兩者在意圖的表達上（功能的實現上）都依賴于寫作的具體風格，編程的隱喻之一就是寫作。你想表達的思想是好的，但是如果表達得難以理解，那么要把這個思想傳播給讀者將非常困難。代碼被讀和修改的次數是相當多的，因此一個很重要的觀點就是你寫的代碼是給人讀的，你需要考慮可讀性的問題，歸結于寫出漂亮的代碼。
判斷代碼是否漂亮似乎沒有什么國家標準，更沒有國家免檢。代碼是寫給人讀的，從這個角度上看，如果一段代碼能讓人很容易地讀懂，讓人感覺心情愉快，修改起來也不費什么力氣，這似乎就是漂亮的代碼咯。那么顯然，漂亮的代碼的真正含義是
幫助程序員感到快樂和提高生產率。有了這個指導性的方向，你可以從這么幾個方面去努力寫出漂亮的代碼：簡潔性、保守性、簡單性、靈活性和平衡。
簡潔性，文中以Ruby和Java版本的Hello World入手比較，在Ruby和其他動態語言中，你所做的就是你想表達的：打印Hello World
print "Hello World\n"
換成java，哦，你先要定義一個類，這個類有個入口main方法，在main方法中調用System.out對象的println方法打印：
class Sample{
public static void main(String []args){
System.out.println("Hello World");
}
}
我記的我初學java的時候就特別不理解為什么要定義一個類，為什么方法要static、args，而我僅僅想要的只是打印一個字符串，可語言硬塞給了我太多的概念：類、方法、入口、參數。這些額外的東西牽扯了太多的注意力，而往往卻忘記了初衷是什么。因此在《unix編程藝術》一書中對OO的一個評價是：鼓勵具有厚重的膠合和復雜層次的體系，大大降低了代碼的簡潔性和透明性，你無法一眼看出代碼是想做什么的。OO的抽象能力很強大，因此在很多場景下是這種抽象能力的濫用，實現最簡單的功能也是一定要有類，有類才有對象，有對象才有光：）而往往這些對象卻非問題領域中的自然實體，而是某種膠合物，為了抽象而抽象。
簡潔同樣意味著消除冗余。代碼的重復是萬惡之源，拷貝黏貼是滋生bug的溫床，在重構概念如此深入人心的今天，這一點毋庸置疑。因此，謹記請DRY原則。語言級別的冗余可能是需要的，例如Ruby允許方法調用省略括號：
task :name=>:test
task({:name=>:test})
這兩行代碼想表達的意思一樣，顯然第一種方式更簡潔，這種語言級別的冗余顯然是有利于程序員的，盡管將實現的難度推給了語言的設計和實現者。
漂亮代碼另一個有爭議的方面就是它的熟悉性，人們對于新東西的接受程度遠沒有想象中的高，大家都喜歡自己熟悉的東西而非全新的思考方式（嗯，極客例外）。這其實是Ruby一直鼓吹的最小驚奇原則的另一種表達。Ruby看來就是這么個保守的語言，他有很強大的OO能力，但是沒有全然照搬smalltalk，他有FP的能力但是卻沒有讓你驚掉下巴，他仍然遵循著古老的順序、循環、選擇的程序結構。
簡單性強調是減輕程序員的工作負擔，語言和類庫API的優化應當有利于使用者，將困難留給實現者。前面提到的語言的冗余性就是一例。程序的復雜性來源有這么幾個：商業上基于推銷熱點而非實際需求考慮出發帶來的“特性清單”、業務領域本身的復雜度、程序員的自傲心理，最根本在于軟件的開發的復雜性。如果能將復雜的功能，用人人理解的簡單代碼表達出來，當然漂亮！
簡單并不意味著簡陋，保守也不意味著死板。靈活性同樣是代碼漂亮與否的判斷標準，是否隔離了變化點，是否擁有一定的擴展能力，是否無需借助工具的增強而實現某些巧妙的調用。同樣以Ruby為例，open class和元編程給了內置你在語言級別的“工具”，你無需借助antlr、cglib等等類庫去做一些看似復雜的東西。你將感受到編程的快樂，而非為了工具而去做一些違背本意的事情。靈活性可能是把雙刃劍，過分的強調靈活性、可擴展性也可能帶來復雜的代碼，注意你的“炫耀”心理。
最后要強調的是平衡，在這些因素之間做出平衡，我覺的吧，沒有更多實踐的經驗想平衡這些因素是相當困難的，如果了解了平衡的藝術，也許算是透出那么點“編程的藝術”的味道。Matz一直強調的一點是編程的樂趣，如果沒有樂趣，我想我不會干這行，如果沒有樂趣，我想我的工作效率將極度低下，從你認為是枯燥的工作中找樂子，存了這么個心理，你總能找出很多可以做的有趣事情，問題在于，你肯不肯做？
ps.加張圖片，俺的blog國家免檢
