閱讀-網路小說

閱讀-網路小說

有一陣子迷上了 , 一些玄幻小說

如: "飄邈之旅" ,  或者是像 "誅仙"

這些小說有出實體書 , 可以到租書店去租 .
但是除此之外 , 有些小說可以從網站上找到 , 更新的速度很快 , 幾乎每天都會有一章節的更新 ,

最多的是大陸人寫的小說 , 簡單來說有不少 YY 小說 ,

有些寫的不錯 , 有些寫的就還好 ,

看多了大陸人寫的小說 , 唯一的好處是閱讀簡體字的能力增加了 ,

除此之外 , 也觀察到了大陸人的一些特點 ,

有很多小說裡面的情節 , 以下說明是個人觀察心得 , 不是要評判大陸同胞什麼... ,

所以有看的不順眼的千萬不要來打筆仗...

(1)仍然崇尚特權(不論是白道特權 , 黑道特權 , 富豪特權) ,

反正主角總要認識個特權人士來當主角的靠山 , 雖然都要描述主角不愛特權 , 但是總會有那麼讓特權人士出場的機會 , 秀秀主角有多少靠山 , 而主角又能淡然處之 ,

表面上是不崇尚特權 , 但是實際上卻是以跟特權有關係為榮...

(2)起家的第一桶金 , 有 90% 的機會是以不法手段取得

你可以看到有不少篇小說 , 主角很有商業頭腦 , 但是他們要起家的第一桶金, 可能是靠勒索 , 可能是靠搶劫 , 反正你會看到 在主角靠不法手段取得第一桶金後 , 他們的生財大業就容易的多了...

[初次看到這些情節 , 讓我這個在台灣土生土長的人有點無法想像 , 雖然是 YY 小說 ,

如果只有一個作者這樣寫就算了 , 但是不只一個作者寫出類似

需要靠不法手段去取得第一桶金的故事 ,

那就反映出大陸的人與我們這裡的人的認知真的差很多]

(3)民族主義風強盛

有不少小說 , 都會描述到大陸的未來 , 是世界第一 , 世界第一強國 等等 , 這也沒什麼不對 ,

經濟第一 , 科技第一 , .... ,

接著就要開始仇日 , 馬來西亞 , 美國都是仇視對象 , 不過很奇怪的是韓國不在裡面 ,

韓國把 中秋節 , 端午節 , 中醫 都拿去申請世界文化遺產 , 可是卻沒有看到大陸同胞對這些事件說話

說實在話 , 有些小說 寫的還不錯 , 可是突然把民族主義硬掛上去時 , 那個小說就有點變味了 ,

上面是幾個我覺得比較特殊的地方

(4) 其他比較常見的就是 小說主角的設定強度的問題 , 比較容易看的出來可能是剛開始寫作的作者容易犯這種錯誤 ,

有些主角一開始出場就是很強 , 這樣的小說很容易成為太監文 ,

舉例來說 , 如果主角一開始的強度就是可以毀滅地球 , 接著當主角需要碰到比較強的對手時 , 對手可能就要能毀滅太陽系 , 然後如果主角可以成長並且打敗對手 ,

那麼第二個對手的強度可能就要能毀滅銀河系  ,

那個第三個對手的強度可能就要會毀滅宇宙 ,

主角在碰到三個對手後幾乎就沒的玩了 (因為宇宙都毀滅了 , 還玩個屁)...

[所以我說這類文章容易變成太監文的原因就是在此]

好歹也得像漫畫 七龍珠的悟空 一樣是逐步成長的 , 而不是一出場就是超級賽亞人3 ,

那漫畫應該很快就結束了吧...

(5) 另外像校園生活就一定要安排校園惡霸出現

惡霸可能還要跟特權掛在一起 , 例如一些高官

這些大概是比較奇怪的地方 ,

當然也有不少小說不錯

像 臭小子鬧官場  就不錯 , 是以杜撰的歷史與國家當作背景

其他的還蠻多的 ,

另外連上大陸網站看小說要注意的是 , 很多站台有毒 , 所以要小心再小心

OOAD-導入 J2EE 質疑與解說

其實談到 OOAD 很多人的見解都不同 , 像我們公司裡面一堆 微軟派(VB + ASP)的 ,
在先前我們導 J2EE 時 , 有引用了一些Framework(Struts) 或是樣式(MVC) ,
最常碰到的質疑


質疑1: Java (J2EE)寫系統真難用 , 一個功能要分成很多個Class 跟頁面才能完成
解說:
當你將Web 系統使用MVC 觀念並且導入 Struts Framework 時 , 沒錯一個功能是要分成很多個Class 跟頁面才能完成 (但是這些增加的工作 , 有他背後的效益在 , 例如較易維護修改等等)
而質疑的人 , 常常是寫ASP的 ,寫ASP 的沒有引用所謂的MVC 觀念來開發 , 所以相關的檔案數就會比較少 , 有沒有看過把 輸入畫面 , 處理頁面 , 錯誤處理頁面 , 重導頁面通通寫在一個 asp 檔的沒有 ,
檔案數只有一個 , 可是有比較好維護嗎???
如果用ASP 開發時 也導入了 MVC 的樣式 , 那麼它的檔案數也會變的多起來 ,
這個跟你用什麼語言沒關係 , 而是你用了哪些樣式(Patterns)
可是質疑的人根本就不懂 , 他只單純的認為J2EE 就是難用...
可他不知 , MS 系列的開發 , 一旦也導入了相關的設計樣式時 , 也一樣不太好用...

質疑2: Java(J2EE) 是 OO 導向 , 很難學 , 很難用
解說: 看起來好像如此(當時 .Net Frame work 1.0 還沒推廣) , 許多玩VB 的同事質疑 ,
但是今天 .Net 2.0 已經都出來了 , 即便是VB 到了 VB.Net
你也不能以VB 的玩法去寫VB.Net  , 而且 .Net 幾乎都是 OO 導向 ,
(還要再找藉口嗎 ? 當作是自己不想要會的理由嗎 ?)
或許可以問問那些提質疑的人 , 是不是改成 .Net 他們就有把握可以做的出來???

注意: 我不是說 .Net 不好 ,  爭論 J2EE 或是 .Net 那個比較好 , 並沒有意義
(你個人喜歡用什麼就用什麼 ,
但是就企業來說 , 必須要有一個大方向在 , 用的東西太多太雜 , 只是增加維護人力罷了 ,
一個維護人力又要會 AS400 又要會 .Net 又要會 J2EE , 又要會 #X&$# , 又要會#X%$ ,
苦的是維護人員 , 出包了是整個IT 部門要負責

選 J2EE 或是 .NET 都可以 ,

但是如果有公司是兩邊都選的 , 只是苦了那些維護的人 ,
明明本職技能就差了 , 還要都摸一點 , 結果更是什麼都不會...)
我自己也熟MS的東西 也實際開發過相關的系統 , 對於MS 或是 J2EE 我都可以玩 ,
(沒有一定要偏好哪一種)

J2EE 或 Net 或是 OO 都只是他們的藉口罷了 , 不會的永遠不會...

分析_讓人銘記在心的主角_就是不斷的給他苦難

分析_讓人銘記在心的主角_就是不斷的給他苦難

忘記是哪個作家說的 , 不要對自己筆下的主角人物太好 ,

要給那個主角(男主角 , 女主角) 不斷的磨難與磨練...

根據這個法則 , 有些主角越是受到痛苦的折磨 , 越能獲得人心(讀者 / 觀眾)

所以像金庸筆下的 楊過 , 讓他身世坎坷 , 讓他受到欺凌 , 讓他斷臂 , 讓他與心愛的小龍女分離 ...

又像 喬峰 從眾人敬仰的英雄豪傑 , 變成人人喊打喊殺的異族 , 又來了一個對他傾心的阿朱 ,

有那麼一個機會可以兩人過著與世無爭的放牧生活 , 卻又為了報仇 , 親手打死了阿朱 , 又回到了孤單一人 ,  甚至到了最後 , 必須死在兩邊都不承認他的中間 , 來替自己的一生畫下句點...

而越是令人落淚的愛情故事越是如此 ,

反正呢 , 不是男主角死了 , 就是女主角死了 , 為什麼?

因為只有不完美的愛情 , 才會令人記住 , 也因為如果兩方可以順利的繼續下去,

也許接著的 , 是兩方的爭吵 , 又或者是一方受到誘惑 , 又或者是家族 , 朋友等其他因素而爭吵 ,

最後完美的愛情只留下了一堆令人嚼之無味的殘渣, ...也許就這麼畫下句點 ,

令人感動落淚的愛情故事嗎 ? 沒有 , 現實中很難存在

東京愛情故事的莉香與完治 , 或許也因為他們沒有在一起 , 他們的愛情也讓人印象深刻

還有很多吧 , ... , 看看日劇與韓劇 , 受歡迎的愛情劇 , 多多少少都有這種味道在吧...

程式設計-應用系統_多國語言_設計及注意事項01

現在的應用系統 , 因為全球化的關係 , 除了商業化套裝產品之外 , 一般大型企業內部開發的系統也會開始講求要支援多國語言的需求．

講支援多國語言其實也是一種含糊的說法，因為有很多細項可以談，這些細項逐一列出來，你就會發現為何說支援多國語言是一種含糊的說法．
首先有３個名詞要注意的，
1.語系(或者稱之為語言 Language)
2.編碼(Encoding 或 Charset)
3.字元集

(I)語系/語言/Language
以語言來看 , 你直接看一下IE的語言項目就會知道
IE 功能表-> 工具->網際網路->語言
光是中文就有分為
中文[zh]
中文(台灣) [zh-tw]
中文(中國)[zh-cn]
中文(香港特別行政區)[zh-hk]
等等．

那英文又可以分為
英文[en]
英文(美國)[en-us]
英文(英國)[en-gb]
英文(加拿大)[en-ca]
等等．

或者是日文，韓文等等．
語言選項代表的可能是詞彙的替換，也可能是編碼的配對選擇．
例如當你選擇語言為　zh-tw 時，一般來說配對的編碼會是 Big5 或是 UTF-8
又或者當你選擇語言為 zh-cn 時，一般來說可能配對的編碼會是 GB2312/GB18030/HZ  或者是 UTF-8

另外一個則是詞彙的替換 , 例如
中文(台灣)用語: 選單 , 休眠 , ...
中文(中國)用語: 菜單 , 冬眠 , ...
再來就是貨幣格式 , 日期格式 , 時間格式等的替換

講了一大段 , 還沒有講到重點  , 只講到一些很基本的項目  , 有點累先休息一下...
可能要至少要講 7 篇才有可能把東西講清楚

男人不壞 , 女人不愛?

男人不壞 , 女人不愛?

這個問題已經有很多人討論過了 , 也不是什麼新的話題了 ,
來看一個最實際的例子吧 ,
有很多女生都拼命說 , 我最討厭抽煙的人 , ....然後呢 , 可能她就找了一個會吸煙的男生當她的男朋友
是怎樣 , 你自己選擇了一個你不喜歡的 ,

同樣的 , 女生可能會選擇一個花花公子當男友 , 即便他花花的聲名在外 ,
然後呢 , 過不久 , 花花男友劈腿了 , 變心了 ,
 女生這時就會找一大群朋友(親友團)哭訴 , 那男生有多壞 , 不應該這樣對她 ,
怪誰呢 ? 這是你的選擇 , 不是別人強迫你的 ,
有些女生還屢屢專找這種男生  , 之後被玩了 , 就怪說 男生都很壞 ,
搞到後來 , 這些女生眼中就只有男生都是壞的 ,
拿好人卡的男生呢 ?在這些女生的眼中根本就是透明的 ,
-----------------------------------------------------------------------------------------------------------------------------
你不能去點一份麻辣鍋 , 然後要求說要不麻不辣 , 不麻不辣的麻辣鍋嗎 ?
那就不是麻辣鍋了!!!

同樣的 , 如果你選擇了一個花心的男人 , 然後又要他不花心 ,
不是沒機會 , 只是機率不高 ,
一個花心的男人不花心 , 那就不是一個花心的男人了....
-----------------------------------------------------------------------------------------------------------------------------
我一直在想根據進化論 , 物競天擇 的理論 ,
壞男人(花花心) 因為花心 , 所以他的練習機會就多 (你看如果一個男人 , 他玩過的女人可能是拿好人卡男人的 100 倍 , 也就是說 , 壞男人比好男人多練習過100次 , 包含要去哪裡吃飯 , 會去哪裡玩會有情調 , 如何做會讓女孩子感動等等 , 包含肉體上的技巧等等 , )
你說 女孩子會選誰 ?
 知道如何取悅自己的壞男人還是只有一片真心沒有技巧不知如何取悅自己的好人卡男人 ?
這時男人的忠實不變心 , 突然就變成了笑話 ...
女孩子還是會選擇花心的 , 所以呢? 男人要不要學習與改變 ?


鳥的嘞 , 說說罷了 , 我還是沒種做壞事....

除錯心法４

除錯心法9:
當系統發生錯誤時，請檢查你的輸入內容是否有錯誤．

錯誤這個用詞有時被拿來濫用了，大家都知道電腦軟體是垃圾進，垃圾出．

舉例來說，你如果使用Outlook 來發信給你的朋友時，你的朋友一直收不到信，
這時就有可能有人說這是Outlook的錯，但是有可能是你自己輸入的Email 根本就不是你的朋友的Email ．

所以這個叫錯誤嗎？　

自己輸入錯誤的資料，系統只是忠實的根據你輸入的資料去產生輸出而已．


這種事發生的機率也不少．

除錯心法３

心法8：詳細的閱讀回報的錯誤訊息以及log file
發現有很多人對於系統回報的錯誤訊息內容視若無睹 , 然後拼命要找人幫她解決問題


舉例來說:
今天在協助別人除錯某個報表時 , 發現報表程序有被執行 ,但是沒有如預期的送出報表 email
試了幾次 , (沒錯 我自己也會耍白痴 , 對於該檢查的錯誤訊息略過 ,
不過我略過的原因是因為一開始我去協助除錯的時候 , 負責的人就告訴我 有錯誤產生是那個報表程序本來就會有的)


再看一次錯誤訊息 , 發現錯誤訊息中有一個項目是說: 報表程序找不到某一個目錄下的某個附件檔案
(這個報表程序是會發出Email 並且將特定檔案當作附件送出) ,


我去檢查了一下那個目錄 , 發現沒有那個檔 ,
然後我想辦法 造了一個 報表程序要的檔案 , 重跑了一次報表程序 就有正常的產出了



我協助除錯的範圍還滿廣的 , 系統的設定 , 程式的內容 , 一些阿貓阿狗的問題
都會丟到我這裡來 ,
也算是同事長官們看的起我 , 給我機會 ,


我想說的是 在外人眼裡 , 我除錯可能就跟喝水一下 , 幾乎都能解掉 ,
就算不能解掉 , 也都找出問題的癥結 ,


我可以跟大家說 , 那些問題其他人 100% 也都能解的出來 , 只是時間可能花的比較長 ,


很多人告訴我  , bug 解不出來 ,
我實在不好意思告訴她們:
如果你願意當個傻子 , 不斷的嘗試 ,
將所有可能的變數 , 排列組合都測試一遍 , 你一定可以解的出來的 ,


可惜很少有人願意當傻子 , 傻傻的在自己的位子上 , 試著數種 , 幾十種 可能的解法
發現這個解不出來 , 就動腦想自己 還有哪裡忽略了  , ...
是不是漏了什麼沒有注意到 , ... , 動腦之外 , 要動手去測試 , ...
很多人可能在第二種解法解不出來時就放棄了...


如果你知道一個被別人號稱是"大師"的傻子
在別人面前可能三兩下就可以把別人困擾數個人月的問題 解決掉 ,
但是實際上在面對各式各樣的除錯歷程 卻是堅持奮戰 , 屢敗屢戰 , 直到把問題解決為止


被人稱"大師" 只是口惠而實不惠 , 調整工作職等時 沒有自己的份 ,
協助除錯 , 並不是自己份內規定要去做的 , 協助除錯也是需要佔用到自己正常的工作時間的


想除錯 沒有那麼難
不想用心 , 就解不開

除錯心法２

心法４：有時除錯不是只有靠技術，要靠正確的觀念跟概念．
心法５：比對法，找出異動點．
心法６：先畫出部署的架構圖（概念或是實際的）
解說：
那一個最近幾個月發生的除錯案例來解說好了，在部門內部會議中，有其他同仁反映了一個問題他們已經弄了一個多月還沒有搞定的問題．
他們使用ETL工具在對AS400與AIX進行轉檔，同時也會對MS SQL進行轉檔．
那個ETL工具是在執行在AIX上面，使用的是AIX上面的ODBC設定去對DB2或是Wiindows 上的MS SQL 做存取．
他們發現對MS SQL 一直無法正確存取並且寫入資料

其中的一位處理的同仁D在白板上說明了他的觀點 , 他認為是 MS SQL Server上面的ODBC 版本不對 ,
他認為要更新 MS SQL Server上的 MDAC 套件...

我當場聽了就有點昏去 , 那位同仁D據稱是DB高手 , 可能是我的表情太不好看了 , 老闆當場就將這個問題指派給我處理

隔天早上 , 我去找了相關同仁詢問必要的資訊 , (心法２：聆聽報案者的解說)
其中一個負責的同仁J告訴我 , "他們的作業原來是可以的" , ［表示不是他們的程式或是設定錯誤］
我又去問了另外一位同仁B , 他說他們存取的MS SQL Server資料庫的機器並不是放在機房中, 而是擺在 IT 同仁的腳下，最近大家剛剛換了位子．［解說：我們一般的個人腳下的機器都是使用DHCP而不是固定IP］＜－心法５，找出異動點．這裡發現有一個異動點
我又回過頭去請同仁Ｊ幫我在AIX上面叫出ETL使用的ODBC設定檔．
這麼一檢查，發現他們所使用的連到那台MS SQL 的設定是使用IP 而不是使用 Hostname 設定．
於是我請同仁J修改設定將原先的IP改成那台MS SQL 機器上的新的IP．並且將這個ODBC設定儲存.
然後再請網路管理的同仁Ｋ開放防火牆，讓AIX可以連到那個MS SQL機器(當然是設定成新的IP)

就做了這麼幾件事, 接著請同仁J再去測試 , 馬上就成功了．
一個困擾他們至少一個多月的問題，在半個早上就被我解決了．

這中間，所有的作業都是其他同仁進行的，我只有出一張嘴而已．
ETL 我不熟 , AIX 上的ODBC 設定檔的叫出 ,我也不會，防火牆的設定修改，我也不會．
那我憑什麼可以把問題解決？我靠正確的觀念與概念．

首先
同事Ｄ提到的MDAC 那個是DB Client 端的存取元件 , 但是在這個問題中 , 我們的DB Client (ETL)是在AIX 上面, 不是在 Windows 上 , 更何況是要把 MDAC 裝到 DB Server端去, 所以這個根本就是個錯誤的解法．
（心法６畫出架構圖，我在一開始的會議中就把圖畫出來，並且分出誰是DB Client 誰是DB Server的腳色，我才能快速的去確認問題的真正的癥結點在哪一部分，不然按照同事D的建議解法,可能到今天還在找問題出在哪裡!!!）

以上案例是我碰到的並解決的真實案例．我無意拿這個案例去攻擊或者是貶低任何人．只是拿來作為除錯心法的解說案例之一．
所以你不會看到內文中提到我們公司的名稱或是部門名稱或是同仁的姓名．

如果有其他同仁看到了，你會知道我是誰．但是我只是拿出來做解說，並且作為自己的除錯心法中的一個案例．

心法７：除錯有時需要一點運氣．
是的，有很多問題我相信別人也能解，但是我常常都能在別人解了很久解不出來的狀況下，把問題給找出來並且處理掉．
有時要靠一點運氣．但是人不會一直都有好運氣，所以我還是要靠正確的觀念與知識去除錯．

除錯心法-1

身為 IT 的技術人員 , 有時要處理的問題不是只有不懂電腦的End User，有時連IT 內部的人員或者是程式設計師也都會碰到各式奇奇怪怪的問題．

我勉強算是個中上等級的技術人員，所以常常會有其他人處理過但是仍然無解的問題，丟到我這裡，希望我能夠將這些問題解決．

就經驗來說，我大概有90%都能夠把問題解決．
所以來說說的我除錯心法吧！　都是有點零散的片段，必要時我會挑出一些案例來解說．可能會發成多個片段


心法１：重現犯案現場
解說：如果有人告訴我，他的程式或是系統出現了什麼錯誤．我會希望他能夠讓錯誤重現．也就是說在什麼樣的步驟下或是程序下，照著做一遍就會出現相同的錯誤．
如果不能重現，那麼錯誤幾乎就很難抓到．

心法２：聆聽報案者的解說
解說：有時候來報案求助的人可能是個電腦白痴，但是也有可能是個與某個問題奮戰了很久的程式設計師．有時候她們已經快要找到問題的關鍵了，只是沒有意識到．

心法３：不要完全聽從報案者的解說
解說：此點好像與心法２互斥．但是它很重要．
說了來報案者有可能是電腦白痴也有可能是個糊塗蛋，可能完全一問三不知，或者是胡說八道一通．如果你照著他們的說法去除錯，可能永遠也查不到問題．

OOAD-可怕的OOAD與Design Patterns應用方式-2

OOAD-可怕的OOAD與Design Patterns應用方式-2

因為這些人根本就不會寫程式碼 , 所以她們畫出來的UML設計圖 , 連她們都不知道對不對,
根據上面的問題衍生出來的下一個問題就是:
她們常常希望來個OOAD大師(不過一定要是外面花大錢請來的那種)
如果是內部的人員 , 又是免費的 , 絕對稱不上是大師 ,

有句成語: 眼高手低 大概是形容這些人的現況
她們常常期望找本高深的書 , 找個高等的老師 , 找個高貴的大師就能教會她們 , 如何成為 OOAD中手 , 但是常常沒辦法達成心願 , 為什麼?
這麼比喻吧 , 你找了個諾貝爾物理學獎的得主來教一個幼稚園的小朋友 , 你覺得這個幼稚園的小朋友在學了一年後就可有大學程度的物理學知識嗎?
她們仍然沒有自覺 , 仍然以為找個大師過來就可以讓她們瞬間提升 ,
我只能說要聽懂大師或看懂大師的著作或教學 , 你絕對不能是個完全不會的人 ,
舉例來說 當大師提到 某某系統使用了 Bridge 或是Adapter 樣式 , 這樣用如何如何時, 如果你完全都不會沒有基礎 , 那接下來大師的講解 , 你會聽懂才有 X

我憑什麼這樣說? 老話一句 , 她們不會寫程式碼(再解釋一遍是PC端的程式碼 , 且是物件導向 , 與Web應用程式方面的 )

所以當你(或是外面來的顧問)再跟她們談最基礎的程式語法例如某些寫法是不對的 , 某些寫法會造成記憶體漏失 , 某些寫法會造成效能不好 , 而這些寫法是因為設計不良造成的, 我可以跟你掛保證 , 她們絕對聽過就忘記 , 為什麼?   老話一句 , 她們不會寫程式碼

至今仍然有不少人以為去外面學了OOAD/UML的課回來就可以當起 SA/SD...
我只能說 , 不會寫程式碼的人開出來的 SD 規格文件 , 你覺得會如何?

接著開發過程中 , 一個問題又一個問題不斷的出現 , 有些問題的出現完全是在於這些相關人等自身的問題 , 幾乎是問題的源頭: 她 們不會寫程式碼(我指的是PC端的程式碼 , 且是物件導向 , 與Web應用程式方面的)
哪些問題?
例如: 測試 , 她們就會問 : 要測哪些 , 如何測 , 測什麼 , 怎麼測?
例如:封裝 , 打包 , 部署 , 她們通通都一定會問 ,(如果她們有實作過 , 根本就連問都不會問)
這些問題 , 不是我看不起人 , 而是真的因為問題的源頭是
這些人都不會寫程式碼
不要再讓不會寫程式碼的人去負責 SA/SD 然後去做分析設計文件
再打個比喻好了
有一個不會騎腳踏車的人 , 不斷的追問人 , 要如何騎腳踏車?
你會告訴他 , 你先坐在腳踏車上 , 然後他會接著問 , 要如何坐在腳踏車上 , 腳架要不要放下來?
<這個比喻很愚蠢吧 , 真的會有人這麼愚蠢嗎? 會騎腳踏車的人絕對不會問這些...
但是就跟那些不會寫程式碼的人卻在上過 OOAD的課程後 , 回來衍生的問題一樣 , 她們會問一些你很難好好教她們的問題 , 當然她們也不會讓你教 , 因為只有她們老師講的是對的>
至今這種可怕的方式 仍然存在...

OOAD 之道 , 開始於 Coding
要記住 OOAD 存在的目的是為了完成系統 , 是為了寫出可工作的程式碼
不會寫Code的人 , 千萬不要來談 OOAD 如何 , Design Patterns 如何如何?
這些對於不會寫 Code的人只是空談

可怕的OOAD與Design Patterns應用方式-1

可怕的OOAD與Design Patterns應用方式
因為工作的關係 , 接觸到了 OOAD．然後又因為OOAD摸到了Design Patterns
但是發現週遭有不少人用可怕的方式在想像與應用OOAD與Design Patterns

可怕的是主管找了一些不會寫 PC端程式 , 不會寫 Web程式的人去外面上了OOAD的課程之後
回來做專案 , 要當專案的 SA , SD
這些人去外面上了課 , 回來的第一個症狀就是他們上課的老師不錯 ,
接著就是當你在專案與這些人討論時 , 她們會告訴你 , 你說的跟她們老師說的不一樣
因為她們老師不錯 , 所以你說的不對...
碰到這些人我以前會好好的教 , 好好的講 ,
現在真的年紀大了沒力了 , 不想說 , 就讓她們去玩

說了半天還是沒有說到重點 , 為何我說她們的用法與想法很可怕
OOAD 是某些有先見的前輩針對使用物件導向的軟體開發與維護(請注意維護這兩個字)大家慢慢不斷的補充與改進其流程與設計方式
舉例來說 OOAD 搭配的表示語言就是 UML
它是圖示語言 , 是系統的設計圖 ,
但是你可以看到某些完全不會寫程式的人去上完課後 , 回來跟你辯說她們的圖如何如何
你的圖又如何如何 , 完全不聽人說 , 這些人以為去上完課回來就會了 UML就懂了 OOAD ,
完全忘了 UML 是OOAD的一部分而已 , 它的存在是為了開發系統而產出的分析設計文件
如果沒有了實做 , 這些圖根本就是個笑話...
你可以試著拿著那些不會寫程式的人畫出來的UML設計圖 , 去問她們根據這張圖寫出來的程式碼會是如何? 如何才是正確的?
因為這些人根本就不會寫程式碼 , 所以她們畫出來的UML設計圖 , 連她們都不知道對不對,

根據上面的問題衍生出來的下一個問題就是:
她們常常希望來個OOAD大師(不過一定要是外面花大錢請來的那種)