偉大的progame 11:30:40
我又在看我2年多前的代碼 向自己學習
偉大的progame 11:30:50
原來我處在一個極端 現在在另一個極端
量大的老鴇 11:32:14
我3年前的代碼，只能形容為：不忍卒讀
量大的老鴇 11:32:43
現在的代碼，可以很公正的說：垃圾
偉大的progame 11:33:07
我原來走標準的三層 com+ businessobject
偉大的progame 11:34:15
現在是framework + xml
偉大的progame 11:34:28
接下來要中和了
偉大的progame 11:34:31
兩個都是極端
老漁翁 11:34:57
標準的三層是垃圾。
量大的老鴇 11:37:01
我以前是標準的萬物皆類，一個小小的接口都要用類來包裹一番，結果累的不行
量大的老鴇 11:38:05
現在終于幡然悔悟，明白鳥手中無刀，心中有刀的真諦，所謂放下屠刀，立地成佛啊.....
偉大的progame 11:38:33
你不明白 你沒有涉及到復雜多變的業務
量大的老鴇 11:39:30
以史為鑒，展望未來，我們的目標是飛花摘葉，皆可傷人，要做到手中無刀，心中也無刀.....
烏鴉 11:39:50
粒度看自己把握
量大的老鴇 11:40:05
我堅持認為，復雜的需求未必一定帶來復雜的實現
老漁翁 11:40:36
我一直用成熟的技術，不用最先進的技術。
烏鴉 11:40:44
復雜的實現必帶來不穩定
量大的老鴇 11:40:53
葵花寶典為什么那么nb？化繁為簡，一根繡花針就搞定一切啊
老漁翁 11:40:57
這是為什么很多國家不修磁懸浮的原因。
烏鴉 11:41:10
復雜的東西必帶來不可靠
量大的老鴇 11:41:46
再看獨孤九劍，關鍵就在一個破字
烏鴉 11:42:02
以前是數據庫,非要怎么設計
烏鴉 11:42:15
現在是類
烏鴉 11:42:23
然后又是層
量大的老鴇 11:42:34
所謂九賤齊出，群處可破.....
偉大的progame 11:43:41
沒說實現要復雜
偉大的progame 11:43:53
但是你如何有一個靈活的東西去面對多變的業務呢
偉大的progame 11:44:08
最后發現 事實上是很難面對的
量大的老鴇 11:44:09
要靈活，就要簡單
偉大的progame 11:44:32
想一個東西通吃不同的業務是不現實的
烏鴉 11:44:33
很多業務其實實現的代價遠遠大于維護的代價
烏鴉 11:44:43
所以這個業務實際上是錯的
量大的老鴇 11:44:44
越內斂，越通用
偉大的progame 11:44:48
首選是業務模型的建立
偉大的progame 11:45:01
這不比軟件架構的設計簡單
量大的老鴇 11:45:06
所謂濃縮的就是精華
量大的老鴇 11:45:49
個人經驗：要從人的角度考慮，就可以避免一些不必要的復雜
量大的老鴇 11:46:48
幾乎所有的windows程序都有搜索，但你看linux的做法，find+grep搞定一切
偉大的progame 11:46:50
你不精通業務 再怎么設計 都可能走入死角
量大的老鴇 11:47:17
業務為人而存在
偉大的progame 11:47:32
業務第一 軟件第二
量大的老鴇 11:47:48
人第一，業務第二，軟件第三
量大的老鴇 11:48:26
表認為客戶都是笨蛋，其實當你愿意教他的時候，客戶會比你想像的聰明
偉大的progame 11:48:49
你從每個人的想法出發是錯誤的 因為即使是一個客戶 在它的內部也是有大量的沖突
偉大的progame 11:49:00
操作和管理層 市場和售后服務
偉大的progame 11:49:12
他們的出發點是不同的 出來的東西是矛盾的
量大的老鴇 11:49:17
沖突是一定的，而且一定會造成矛盾的需求
偉大的progame 11:49:26
你如果精通業務 有成功案例
偉大的progame 11:49:33
那么好辦了 這時才可以指導它
量大的老鴇 11:49:50
在這個時候，可以給出一個二義性的解決方案，有何不可？
偉大的progame 11:49:58
不會因為你的軟件多么多么地靈活 多么多么地先進 你才有資格指導它
偉大的progame 11:50:23
那么你的軟件最后給他們是帶來問題
偉大的progame 11:50:27
而不是解決問題
量大的老鴇 11:50:37
解決問題的核心是解決人
專彈金屬的JJ 11:50:43
因為人本身，就是一個問題！
量大的老鴇 11:50:44
而不是事情
偉大的progame 11:50:53
精通業務 成功案例 這是順利實施的不二法門
偉大的progame 11:51:59
其它都是扯蛋 跟客戶說技術先進 負載量 可伸縮性 跨平臺 節約成本 最后都會因為流程無法順利走通而完蛋
量大的老鴇 11:52:21
我沒有做過數據庫應用，所以只能從我的經驗進行推論，未必正確，但是（我恨這個詞），一些原理也許可以通用
偉大的progame 11:52:21
老夢你做的是提供功能性的東西 功能有了 就OK了
偉大的progame 11:52:30
我做的是業務流程的東西
偉大的progame 11:52:40
流程才是最重要的
量大的老鴇 11:52:54
流程走不通，可以變通
量大的老鴇 11:53:03
變通的基點就是人
偉大的progame 11:53:16
客戶不是要你拿他來當實驗品
量大的老鴇 11:53:23
否則就不能轉化為最終實現
量大的老鴇 11:53:49
客戶是上帝，是豬，是畜生
量大的老鴇 11:54:08
當一回試驗品也沒關系
量大的老鴇 11:54:43
要敢于摸著mimi找mm
量大的老鴇 11:54:58
只要爽就可以
偉大的progame 11:55:17
所以沒辦法 只好犧牲幾個試驗品了
偉大的progame 11:55:25
代價就是被客戶罵
量大的老鴇 11:55:32
沒人敢說他的模型是萬能的，他的流程是通用的
量大的老鴇 11:56:09
如果能做到盡量靈活，也能做到無限接近正確
量大的老鴇 11:56:52
寫的再多，不如抓住核心
偉大的progame 11:57:21
我現在就是想 用底層的東西 能夠大大節省開發時間 這樣 無需開發通用產品 而是快速開發多個產品
量大的老鴇 11:58:22
也許我更粗暴，我想用進程＋靈活的接口方式，提供一勞永逸的模塊，將來的事情就是組裝
量大的老鴇 11:58:57
沒有膠合層，拒絕轉發
量大的老鴇 11:59:16
界面都可以拋棄，只有功能永存
量大的老鴇 12:00:24
所謂的框架、模型、接口，最終的目標是功能，如果帶來的附加部分遠超過實際所需，那么再先進也是廢物
量大的老鴇 12:01:05
最極端的例子就是java的那些狗屁框架，也不知道是為什么樣的腦袋而準備的
量大的老鴇 12:01:43
我只要一杯水，卻給我送上來一個凈水處理工廠
?
2006-06-29 http://www.heybrain.com 首發