不要去弄髒構造器方法！
---------------2009-02-24
這是來自自己最近的專案salesys的乙個經驗之一。坦白說，在這個專案，還有以前的幾個專案中糟糕的設計有很多，這個只是其中之一。
在salesys的乙個很大的特點就是大部分的模組在開始頁面都有乙個資訊列表，用於顯示這個模組的主要資訊。就像這樣：
在我們的**設計中（其實根本就沒進行設計），這個資訊列表是儲存在乙個 list中的。很自然的，我們會在backing bean 裡面為這個屬性寫構造器方法。順便說一下，salesys 是jfs+ejb架構的。現在的問題是我們要去呼叫ejb裡面的方法來從db讀取這些資料。接下來自己做了乙個很業餘的決定，改寫get方法，讓get方法來呼叫ejb，而忘了使用者觸發這個事件的方法。
而這個該死的決定帶來的後果是：當我們要分頁顯示這些資料時，程式每次都去讀資料庫，到後來程式就會變的很慢很慢。更該死的是我們在所有模組都快寫完的時候才發現這個問題。於是我們採取了乙個補救措施，在get方法裡面加乙個判斷，當list 等於null的時候才去讀資料庫。
我們以為問題解決了，而忘了還要做那些該死的新增，刪除，編輯等操作。就這樣新的問題來了，當我們向db新增了一條資料的時候，並不會在這個資訊列表裡面顯示出來。因為我們的list不為null。於是我們又去修改我們的新增，刪除，編輯等方法。 等到業務上的方法加進來的時候，我們又發現我們的get方法還不夠用，於是又加了寫**進去。
經過不停的給**打補丁，程式終於能正確的顯示頁面了。但是已經不那麼穩定了，**的意圖也很難看懂了。
後來我不斷的問自己，為什麼當時不在響應使用者操作的方法中來讀寫db，而讓構造器方法只有一行**呢。這樣**的意圖不是很清楚，程式不是更穩定？
設計極其糟糕的select函式
設計極其糟糕的select函式 相較windows而言，大部分unix api函式設計都比較考究，但也有少數簡直就是奇葩，select函式正是這些奇葩中非常燦爛的一朵。我原來一致鍾情於ace，接觸的只是reactor，最近由於開始自己設計網路層的類庫，被迫和select打了一些交道，被迫和這個函式打...
糟糕的應用層通訊協議設計
去年和今年分別參與了兩個公司的專案，這兩個專案都涉及到了通訊方面的程式設計，或者是以太網路通訊，或者是串列埠通訊。凡是通訊就必須要有通訊協議，個人認為協議的設計是個非常嚴肅的工作，需要理解業務需求和掌握基本的協議設計知識。但是從這兩個專案來看，其協議的設計可以說是 糟糕到了極點。下面就其糟糕的設計之...
記住糟糕的過去
原文 remember the bad old days evilapi讓我想起了乙個最早的mashups，它將xml放在web上，讓我們大受啟發。philip greenspun 的關於bill gates 的財富時鐘 就是lorest和基於文字格式 albiet html 的威力的乙個了不起的應...