這是從某人就職的公司聽到的 ,
V是負責規劃 SOA & WebService & XML 的人員
只不過某V 完全沒有設計及使用 XML 的經驗
也沒有寫過WebService , 也沒有寫過WebService的Client端的經驗 ,
SOA就更不用談了...
連拿到有問題的XML都不了解錯在哪裡或是如何改正,
但是這樣的人選就是要負責規劃公司未來使用的XML , WebService , SOA...
千萬別問我
為何不找曾經有設計過XML內容 , 有在系統中實際應用過 XML 內容的同仁負責
或者是有程式設計經驗的同仁來負責
[現在的潮流是 任何一個阿貓阿狗
只要看過了
"深入淺出物件導向分析與設計"
或者是
XXXX Cook book
或者是
XXX 設計樣式
之類的 , 沒有寫過半行程式碼 , 不會任何程式語言的 都可以出來侃侃而談 系統架構的設計 , 哪裡對 , 哪裡不對
<這些書沒有什麼不對的 , 都很好也都很經典 ,
只是一些人的心態上有問題 , 一票阿貓阿狗因為沒有寫程式的經驗 , 就在當 SA ,SD 甚至是 Architect , 然後看到書上提到 "XXX 設計樣式" 或者是 "XXX Cookbook" 完全沒理解那些內容的適用處與適用範圍 , 就胡搞瞎搞的套用到 公司的系統上面去 ,
結果自然是亂七八糟 , 慘不忍睹 ,
然後那些人可能還會跳出來說： XXX 設計樣式一點用都沒有 , 是垃圾....之類的 ,
為了這些胡搞瞎搞 , 沒有實際程式寫作經驗的人 ,
某些大師只好出來寫
"XXX反樣式"
來明確的告訴你 , 哪些情況下 , 不適用哪些樣式....
IT 有一種很奇怪的階級情節 , 就是 Programmer 是最低下的 , 往上升級然後是 SD , SA , Architect
水往地處流 , 人往高處爬 , 是沒有太大的錯誤 ,
錯的是在於 , 一堆高處職階的 , SD ,SA , Architect 竟然是使用沒有程式寫作經驗的人去擔任 ,
因為連程式都寫不好 , 所以讓他們去做 SD , SA , Architect ???
>
]
回到正題 , 完全沒有經驗的沒有基礎的人 要來帶領大家如何開發 SOA系統 , WebService , XML ,
方向會不會有偏差呢? 差了多少呢? 誰知道呢? 誰負責呢?
{某公司內WebService的應用 , 在某些的人的錯誤領導下 , 正朝向濫用錯用的狀況
大家都知道 , 程式語言的 API 呼叫是最直接也最快速的 , 不論是效能或是資源都耗用都是最直接的 ,
但是如果是那類完全不會寫程式不了解狀況的人來帶領 , 就會變成 , 什麼都會變成是 WebService ,
可以會出現的後果是什麼 , 就是這些人講不上來的地方 ,
會有什麼後果嗎?
首先:
當你使用 WebService 時 , 你必須定義對應的 XML Schema ,
將資料的傳入傳出都必須要轉換為是 XML 的內容格式 ,
當然 Client 跟 Server端也都要進行額外的XML驗證與解析 , 之後才是真正的處理...
意思是 當你呼叫 x.helloWorld("say Hi") 這樣的 API 時 , 換成 WebService 他的資料量(XML)
會由可能是幾十個 byte 變成幾百個 byte , 甚至是幾千個 byte (看你的資料嚴謹度與套用的物件多寡) 在網路上傳輸 , 也會在 client & Server端的記憶體存在
這樣的影響是 ,
(1)網路之間的傳輸量會變大 , 需要比原來大 10 或者 數十倍的傳輸頻寬
(2)系統在收到資料時需要先進行XML驗證與解析 , 原來使用的記憶體可能是也比原來大 10 或者 數十倍的記憶體大小
(3)因為要額外進行XML驗證與解析 , 所以也需要額外的CPU使用量
因為這些額外的需要 , 要問的是 企業內部是否做好了因應的準備 , 換了更快 CPU , 更多數十倍記憶體 , 更多數十倍網路頻寬的Server與網路架構 ? 如果都沒有 ?
系統會發生什麼事??? 三不五時 , 系統會出現 Out of memory 或者是 CPU 滿載 , 或者是網路塞爆
要說明的不是 WebService 不能使用 , 而是要用之前 , 因應的配套措施做好了沒???
是不是用在適用的範圍內？
如果有 Native API 可以使用 , 然後系統不是跨程式語言 , 也不是跨平台的情況下 , 卻仍然有人堅持一定要使用 WebService 去做到 Native API 可以達到的事 ,
那就要看那間公司是不是有買了換了更快 CPU , 更多數十倍記憶體 , 更多數十倍網路頻寬的Server與網路架構 ? 如果都沒有 ?
那就會出現對比於公司的業務量的成長, 出現不成比例的需求： 機器永遠不夠快 , 記憶體不夠用 , 網路不夠寬 , 這樣的需求出來．．．
}
V是負責規劃 SOA & WebService & XML 的人員
只不過某V 完全沒有設計及使用 XML 的經驗
也沒有寫過WebService , 也沒有寫過WebService的Client端的經驗 ,
SOA就更不用談了...
連拿到有問題的XML都不了解錯在哪裡或是如何改正,
但是這樣的人選就是要負責規劃公司未來使用的XML , WebService , SOA...
千萬別問我
為何不找曾經有設計過XML內容 , 有在系統中實際應用過 XML 內容的同仁負責
或者是有程式設計經驗的同仁來負責
[現在的潮流是 任何一個阿貓阿狗
只要看過了
"深入淺出物件導向分析與設計"
或者是
XXXX Cook book
或者是
XXX 設計樣式
之類的 , 沒有寫過半行程式碼 , 不會任何程式語言的 都可以出來侃侃而談 系統架構的設計 , 哪裡對 , 哪裡不對
<這些書沒有什麼不對的 , 都很好也都很經典 ,
只是一些人的心態上有問題 , 一票阿貓阿狗因為沒有寫程式的經驗 , 就在當 SA ,SD 甚至是 Architect , 然後看到書上提到 "XXX 設計樣式" 或者是 "XXX Cookbook" 完全沒理解那些內容的適用處與適用範圍 , 就胡搞瞎搞的套用到 公司的系統上面去 ,
結果自然是亂七八糟 , 慘不忍睹 ,
然後那些人可能還會跳出來說： XXX 設計樣式一點用都沒有 , 是垃圾....之類的 ,
為了這些胡搞瞎搞 , 沒有實際程式寫作經驗的人 ,
某些大師只好出來寫
"XXX反樣式"
來明確的告訴你 , 哪些情況下 , 不適用哪些樣式....
IT 有一種很奇怪的階級情節 , 就是 Programmer 是最低下的 , 往上升級然後是 SD , SA , Architect
水往地處流 , 人往高處爬 , 是沒有太大的錯誤 ,
錯的是在於 , 一堆高處職階的 , SD ,SA , Architect 竟然是使用沒有程式寫作經驗的人去擔任 ,
因為連程式都寫不好 , 所以讓他們去做 SD , SA , Architect ???
>
]
回到正題 , 完全沒有經驗的沒有基礎的人 要來帶領大家如何開發 SOA系統 , WebService , XML ,
方向會不會有偏差呢? 差了多少呢? 誰知道呢? 誰負責呢?
{某公司內WebService的應用 , 在某些的人的錯誤領導下 , 正朝向濫用錯用的狀況
大家都知道 , 程式語言的 API 呼叫是最直接也最快速的 , 不論是效能或是資源都耗用都是最直接的 ,
但是如果是那類完全不會寫程式不了解狀況的人來帶領 , 就會變成 , 什麼都會變成是 WebService ,
可以會出現的後果是什麼 , 就是這些人講不上來的地方 ,
會有什麼後果嗎?
首先:
當你使用 WebService 時 , 你必須定義對應的 XML Schema ,
將資料的傳入傳出都必須要轉換為是 XML 的內容格式 ,
當然 Client 跟 Server端也都要進行額外的XML驗證與解析 , 之後才是真正的處理...
意思是 當你呼叫 x.helloWorld("say Hi") 這樣的 API 時 , 換成 WebService 他的資料量(XML)
會由可能是幾十個 byte 變成幾百個 byte , 甚至是幾千個 byte (看你的資料嚴謹度與套用的物件多寡) 在網路上傳輸 , 也會在 client & Server端的記憶體存在
這樣的影響是 ,
(1)網路之間的傳輸量會變大 , 需要比原來大 10 或者 數十倍的傳輸頻寬
(2)系統在收到資料時需要先進行XML驗證與解析 , 原來使用的記憶體可能是也比原來大 10 或者 數十倍的記憶體大小
(3)因為要額外進行XML驗證與解析 , 所以也需要額外的CPU使用量
因為這些額外的需要 , 要問的是 企業內部是否做好了因應的準備 , 換了更快 CPU , 更多數十倍記憶體 , 更多數十倍網路頻寬的Server與網路架構 ? 如果都沒有 ?
系統會發生什麼事??? 三不五時 , 系統會出現 Out of memory 或者是 CPU 滿載 , 或者是網路塞爆
要說明的不是 WebService 不能使用 , 而是要用之前 , 因應的配套措施做好了沒???
是不是用在適用的範圍內？
如果有 Native API 可以使用 , 然後系統不是跨程式語言 , 也不是跨平台的情況下 , 卻仍然有人堅持一定要使用 WebService 去做到 Native API 可以達到的事 ,
那就要看那間公司是不是有買了換了更快 CPU , 更多數十倍記憶體 , 更多數十倍網路頻寬的Server與網路架構 ? 如果都沒有 ?
那就會出現對比於公司的業務量的成長, 出現不成比例的需求： 機器永遠不夠快 , 記憶體不夠用 , 網路不夠寬 , 這樣的需求出來．．．
}
