Ruddy Lee 分享空間

Emergent Design 演化設計

架構實在有夠多,左兜右抄就 … 做完了!

with one comment

來談談太多架構所帶來的有趣現象,那就是…

Minimizing understanding Is the ways to maximize functionality.

意思就是說;淺層的理解才能產出更多功能。
(淺層的理解 Cluelessness語出Martin Rinard 2006在OPPSLA的演講;全文可以在這裡找到http://wiki.apidesign.org/wiki/Image:RinardOOPSLA06.pdf,談的也就是時下流行的兜兜理論,說得簡單一點就是用copy/paste寫程式)

有人這麼說,WCF是最典型的過度包裝架構

話說;明明就是ㄧ個再簡單不過的rest API,也不過就是一行URL,都能夠被WCF拿來大作文章,還因此創新了一個Odata的協定,好扯! 但你説它沒用嘛;卻還真是可以幫你減輕不少工作。

==> 加入WCF參考: using System.Data.Servies; 一切就搞定了,用不著弄清楚反正可以用了。

只是這樣作會不會畫蛇添足了呢?!對程式設計人員運用起來確實是輕鬆許多,但卻也更看不到真正的來籠去脈,因此對整個程式的掌握度就更脆弱了許多,無形中損失了優美程式的精簡和明確(當然真理也被隱藏了…),整個程式變的醜陋而缺乏生氣,可是它workㄚ! 或許還能在它有限的生命週期內,work得很好呢!你説這是對還是錯?好還是不好?

老實說: 從物件到架構,不就是為了隱藏複雜度,進而加快產能嗎!所以這麼作是對的。

但我想說的是;至少請保留優雅而簡潔的 API 吧!

最近在coding 的過程,總是畫好架構後就開始想盡方法,幾乎極致的運用google到處搜尋可以參考的範例或架構程式,有時我都搞不清楚,這是在寫程式嗎?!曾幾何時;寫程式都在靠搜尋的(還真是有效率),但這對程式員而言,好像越來越不需要懂太多或可以說是沒必要太深入了解基礎知識了!(相對於深度理解應該是淺度理解吧,令人感慨的正是如此,老一派的學者會說成:不求甚解…)這種作法方式是成立的,而且至少它是一種可以迅速完成工作的方式,只是程式模組與模組之間的介面卻成了我們唯一在意的部份了,這裡想推薦一本API的巨著(描述的太誇張,其實設計API就是要快寫快改,踏實而簡潔的前進,沒有太多訣竅的,過去我都習慣用XML or JSON 格式先做Simulation, 但這一招現在的年輕人已經不用了,直接copy來用不就成了)。

想對抗淺度理解,我也沒有方法,只能繼續推廣大家多多閱讀囉!
Practical API Design by: Jaroslav Tulach著。沒錯正是NeatBeans的創始人的得意作品。

它分成二部份,第二部份才是談API設計的,前面的一部份較多感觸跟玩味,哈!其實我比較喜歡他寫得亂七八蹧的第一部份,看人囉~(老狗說太亂)

by: Jaroslav Tulach著。

沒錯正是NeatBeans的創始人的得意作品。

補述一下: 不求甚解的結果;就是越來越缺乏創造力,動不動就會經常卡住,久而久之則淪於工匠之流。還是開卷有益! 請多讀書吧!
要想做好一件事情,首先;我們應該要先了解它。 這是我們在學習設計模式時的箴言,只有真正了解了模式的意義才可能有良好的運用及產出。
祝 你(妳)閱讀愉快!

Written by ruddyllee

2011 年 09 月 17 日 於 21:49:58

張貼於未分類

Tagged with

一個回應

Subscribe to comments with RSS.

  1. 頗有同感

    Jacky

    2011 年 09 月 18 日 at 11:45:58


發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: