因為這些人根本就不會寫程式碼 , 所以她們畫出來的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大師(不過一定要是外面花大錢請來的那種)
如果是內部的人員 , 又是免費的 , 絕對稱不上是大師 ,
有句成語: 眼高手低 大概是形容這些人的現況
她們常常期望找本高深的書 , 找個高等的老師 , 找個高貴的大師就能教會她們 , 如何成為 OOAD中手 , 但是常常沒辦法達成心願 , 為什麼?
這麼比喻吧 , 你找了個諾貝爾物理學獎的得主來教一個幼稚園的小朋友 , 你覺得這個幼稚園的小朋友在學了一年後就可有大學程度的物理學知識嗎?
她們仍然沒有自覺 , 仍然以為找個大師過來就可以讓她們瞬間提升 ,
我只能說要聽懂大師或看懂大師的著作或教學 , 你絕對不能是個完全不會的人 ,
舉例來說 當大師提到 某某系統使用了 Bridge 或是Adapter 樣式 , 這樣用如何如何時, 如果你完全都不會沒有基礎 , 那接下來大師的講解 , 你會聽懂才有 X
我憑什麼這樣說? 老話一句 , 她們不會寫程式碼(再解釋一遍是PC端的程式碼 , 且是物件導向 , 與Web應用程式方面的 )
所以當你(或是外面來的顧問)再跟她們談最基礎的程式語法例如某些寫法是不對的 , 某些寫法會造成記憶體漏失 , 某些寫法會造成效能不好 , 而這些寫法是因為設計不良造成的, 我可以跟你掛保證 , 她們絕對聽過就忘記 , 為什麼? 老話一句 , 她們不會寫程式碼
至今仍然有不少人以為去外面學了OOAD/UML的課回來就可以當起 SA/SD...
我只能說 , 不會寫程式碼的人開出來的 SD 規格文件 , 你覺得會如何?
接著開發過程中 , 一個問題又一個問題不斷的出現 , 有些問題的出現完全是在於這些相關人等自身的問題 , 幾乎是問題的源頭: 她 們不會寫程式碼(我指的是PC端的程式碼 , 且是物件導向 , 與Web應用程式方面的)
哪些問題?
例如: 測試 , 她們就會問 : 要測哪些 , 如何測 , 測什麼 , 怎麼測?
例如:封裝 , 打包 , 部署 , 她們通通都一定會問 ,(如果她們有實作過 , 根本就連問都不會問)
這些問題 , 不是我看不起人 , 而是真的因為問題的源頭是
這些人都不會寫程式碼
不要再讓不會寫程式碼的人去負責 SA/SD 然後去做分析設計文件
再打個比喻好了
有一個不會騎腳踏車的人 , 不斷的追問人 , 要如何騎腳踏車?
你會告訴他 , 你先坐在腳踏車上 , 然後他會接著問 , 要如何坐在腳踏車上 , 腳架要不要放下來?
<這個比喻很愚蠢吧 , 真的會有人這麼愚蠢嗎? 會騎腳踏車的人絕對不會問這些...
但是就跟那些不會寫程式碼的人卻在上過 OOAD的課程後 , 回來衍生的問題一樣 , 她們會問一些你很難好好教她們的問題 , 當然她們也不會讓你教 , 因為只有她們老師講的是對的>
至今這種可怕的方式 仍然存在...
OOAD 之道 , 開始於 Coding
要記住 OOAD 存在的目的是為了完成系統 , 是為了寫出可工作的程式碼
不會寫Code的人 , 千萬不要來談 OOAD 如何 , Design Patterns 如何如何?
這些對於不會寫 Code的人只是空談
