現在對程式只有兩個要求:簡單、堅固;其餘一切都不在心上。
不知道多少人有到別人家上廁所的經歷。
我的一些朋友家裝不錯,但是有一點我是特別頭痛的:那個好幾千的馬桶。這些馬桶賣相不錯、技術先進(具體牛在哪兒我就不懂,但肯定確實構造比最便宜的馬桶複雜很多),就是有一點,萬一我不幸想在這些朋友家大號,總有可能衝不乾淨。收尾工作經常不是擦pp沖水,而是做好清潔工作才敢出去。
我還有乙個朋友,便便非常大條,多大下水的馬桶都堵過;我常想,如果來的不是我而是他... 所以搬到現在居住的地方的時候,選擇馬桶,我的標準就是:最簡單中較好的。
不知道大家有沒有經常逛家具城的。
我沒這方面需求和愛好(生活水準低、要求也低),但偶爾會去宜家,因為宜家很多東西的設計符合第一條,有時候會去當公園逛逛。長話短說:如果你仔細觀察,宜家的很多家具,都是釘在牆上或地上的;如果碰巧碰到沒有釘上的,或者到自提區看樣品,你會發現輕輕一推,所有的東西都是晃晃悠悠的。
也許宜家最初的定位是給窮人、經常換住所的人提供臨時家具;但相比我家乙個50年代傳下來的桌子,這感覺還是讓人不爽。當然考慮到宜家是從需求出發,能夠釋然一點。
簡單是必須;堅固在所有非臨時的東西上與它並列,就是這樣。
p.s. 堅固,在這裡並不是僅僅說正確性,還包括了「抗推」能力。即一段程式、乙個設計,只要它完成,它在乙個預期的時間內,能承受一定範圍的外力;外力主要指:同一層次其它部分的變更、其它層次設計的變更等外在於當前部分帶來的影響。
聽著似乎有點象「高聚低耦」等等那套,不過那些並不是我在這裡要說的東西:它們既不充分,且還存在很多多餘的東西,從而也就不必要了。事實上遵循種種原則往往並不能達到我在這裡所說的目標,甚至連這些原則本身的目標也達不到。
這一方面是因為:很多原則需要具體的方法,而方法是否成功又依賴於實施,實施呢則又看使用者對問題的理解;而前面這一大串在很多時候都會使得「對問題的理解」的關注被分散。可一旦問題被理解了,前面一大串也就無關緊要了。買櫝還珠。
另一方面,需要長篇大論、細心研討的東西一定不是根本的;為什麼?參見第一條:它們不夠簡單。
拋磚引玉 ERP
看了這個故事,估計你對erp enterprise resourses planning 企業資源計畫 有個大致的了解。妻子 當然可以,來幾個人,幾點來,想吃什麼菜?丈夫 6個人,我們7點左右回來,準備些酒 烤鴨 番茄炒蛋 冷盤 蛋花湯 你看可以嗎?商務溝通 妻子 沒問題,我會準備好的。訂單確認 妻...
接 拋磚引玉
接上次,考慮到轉datatable實際效能問題,我把本地linq複雜物件不轉成datatable,僅去掉中間的複雜物件.這樣list就可以在webservice中傳遞了.同樣拋磚引玉 1public static list tentity togenerallist tentity this ili...
拋磚引玉,說平台概念
今天看到史玉柱在說推遊戲創業平台,由此相到目前眾多的有實力的公司,都在用這樣的手法謀劃未來 大家都在講平台,阿里的saas,google在謀劃它的網路平台,它的眾多的基礎服務,gae及g2馬上推出還有和學習iphone的開發者分成模式,google有google的戰略 中移動,成立卓望互網,謀化sn...