程式之美

程式的美要從兩個方面進行品味，一是程式整體的架構之美；一是程式的代碼實現之美。 編碼之美： 編程就是為解決一個電腦能夠解決的問題寫出具體的程式實現。 開始，人們總是從發現代碼之美開始的，從把代碼一股腦的寫在main方法裡，到把一些有獨立意義的代碼片斷寫成不同的方法；從不知道代碼重用，到把有重用性的代碼抽象出來在不同的地方重用；從類與類之間沒有什麼組織圖，到開始把程式中的類組織成不同的目錄結構，讓不同的類擔當不同的責任。這個時候才第一次和OO思想沾邊。從把類看成程式最大的組織形式，到把程式設計成不同的模組；從不知道介面有何用處，到發現自己離了介面竟然有點不會寫程式了。這些是我編程的不同階段，相信大多數人也都要在不同的階段走過。代碼之美還有很具體的地方，實現同樣的功能，有人做不出來，有人用1天寫出一個一千行的實現方案，需要運行1s鐘解決問題，有人用10天寫出一個一萬行的實現方案，只要運行0.01s就能解決問題。通常來說，要解決一個問題，人做的工作越多，電腦做的工作就越少；思維越縝密，就越能減少程式出現的bug，同樣，代碼長度也就越長。一萬行的程式不一定比一千行的程式慢。說起代碼之美，我想起以前看到的一個小題目：用最短最高效的代碼實現一個方法，判斷一個32位的int數num是不是2的冪數（既是否存在一個n是的n個2相乘，得到num），存在則返回0，不存在返回非零。 我見過的最牛的實現： public int count(int num){     return x&(x-1); } 代碼之美體還現在很多地方，比如說優秀的演算法，命名規範、代碼格式等等。 架構之美： 好的架構是系統成功的一大半，有了好的架構，實現起來只有好壞之分，基本不存在能不能實現的疑問。對系統進行架構的過程就是對現實世界中的事物和過程進行抽象的過程，抽象的越接近事實的本質，適應性越強，系統的生命力也就越強。作為一個還沒畢業的大學生，我不敢說自己對架構一個系統有什麼獨到的見解。唯一一次像樣的架構程式也就是做那個項目，架構總體還算成功，採用外掛程式式設計，這個思想使得我們整個程式各個模組之間的耦合度都很低，幾乎完全是面向介面編程的。系統架構這個東西感覺一是要學習理論知識，學習成功案例，多想想如果是自己會怎麼辦，有機會自己要多實踐，理論聯絡實踐是最重要的。同時還要多思考，思考世界，思考事物之間的關係，將它們抽象成電腦可以表示可以處理的模型。  系統越小，編碼顯得越重要；系統越大，架構越顯得重要。 但是具體到我現在接收的一個半路項目，其架構是比較好的，完全能夠達到應用的實際需要，但是代碼實現卻做的非常差導致整個項目品質嚴重縮水，這也是讓人很無奈的。 閱讀優美的代碼，體味優美的架構，一種思想的美總能止不住的從心中油然而生，如同醍醐灌頂。