2012年2月17日 星期五

[Programming] 物件導向(2) - 名詞定義

自從在案子裡教了程式開發的教育訓練以後,就不斷在寫程式開發的文.....


有鑑於在物件導向程式設計裡,比起原先的基本程式開發的專有名詞還要再更多一點,而且根據地區性的不同還有不同的翻譯,為了避開這種語意上的混淆,我決定先整理一下物件導向程式設計裡會用到的專有名詞和其意義。

所謂的類別 (class),就是像我們上一篇所提到的Student那樣,可以把它想像成一種自己設計的特殊變數型態。就像標準C語言中的int, char....這種型態的意義是一樣的;也可以把它想像成是一種建構物件的藍圖,程式能夠以這個藍圖,產生出物件和藍圖一模一樣的物件。很多時候類別都會包含一個建構子 (constructor) ,用來定義該類別被實體化後的初始狀態。

物件 (object),就是已經用new和該類別的建構子將類別實體化後產生出來的東東。
上面這張圖是我在做專案的程式開發教材時所畫的圖,版權沒有。
如上述的圖所示,當宣告一個Guy類別,變數名稱為joe的時候,只會先產生一個叫做joe的Guy類別參考,還沒有實體記憶體可以來存資料。等到經過new以後,才會在實體記憶體裡抓一塊空格出來讓程式存東西,然後把joe這個參考指到這塊記憶體裡,這個動作稱為實體化,抓出來這塊記憶體,就稱之為物件(object),或稱之為實踐(instance)
所以,物件是真的有實體的。就像現實生活中,眼睛看到的每個東西都算是物件,而它們都有實體,而不是抽象的概念。

現實生活中的各種物件都有它自己的動作 (operation),或是被使用後產生什麼變化或結果。在物件導向程式設計裡,物件自發性的動作,我們稱之為方法 (method),以C語言的概念來說,也有人稱它為函式 (function)
像上一篇中Student類別裡的SexTransform()就是方法,做法是讓學生女變男或男變女。.....咳嗯,SexTransform(性轉換)嘛....自發性的動作...嗯。
總而言之,像鴨子會飛或是會呱呱叫,或是人會走路會跑步會跳會攻擊等等的,可以對該類別做成一個一個方法來使用,所製造出來的物件就不光只是個裝資料的容器而已,它還會動。不過有一點要注意的是,這些方法,因為是寫在類別裡面,所以是針對物件去做處理的方法,所以在還沒建一個實體之前,這些方法是不能用的。

當然,也是有一種類別或方法它是不用先把實體建構出來就可以呼叫方法的函式。這種東西,我們稱為靜態方法 (static method)。這種方法在一開始被呼叫後,就會把記憶體空一塊空間出來處理方法裡面要做的事,執行完了之後,空出來的記憶體不會被釋放掉,所以裡面的區域變數,狀態都會被存下來,不會不見。
所以,假如你的類別裡有一個靜態方法,然後程式在執行的過程用這個類別宣告了好幾個物件,這好幾個物件,都會共用同一個靜態方法,連方法裡的變數都是共用的。這個部分如果沒有掌握好,在debug的時候會把頭髮抓掉一半都不知道問題出在什麼地方。

有靜態方法,當然也有所謂的靜態類別 (static class),原理上和靜態方法是類似的:就是呼叫完之後記憶體空間不會不見。它和一般類別不一樣的地方在於:它不能被實體化,裡面也不能包含實體方法。其實這種靜態類別,通常被用於定義整個系統都會去使用,或是共用的函式集,像是存取資料表的動作、設計模式中的獨體模式 (Singleton) ...等。

以下程式碼為靜態類別和靜態方法的例子,保證不能使用,但是大致上來說就是如此而已。
static class DB
{
    private static SqlConnection sqlConn;
    private static SqlCommand sqlComm;
    private static SqlTransaction sqlTrans;
    
    public static bool Open(){
        try {
            sqlConn = new SqlConnection("");
            sqlConn.Open();

            sqlComm = new SqlCommand();
            sqlComm.Connection = sqlConn;

            sqlTrans = sqlConn.BeginTransaction();
            sqlComm.Transaction = sqlTrans;

            return true;
        }
        catch{
            return false;
        }
    }

    public static bool Update(string strSQL) {
        try
        {
            sqlComm.CommandText = strSQL;
            sqlComm.ExecuteNonQuery();
            return true;
        }
        catch {
            Close(false);
            return false;
        }
    }

    public static void Close() {
        Close(true);
    }

    private static void Close(bool succeed) {
        if (succeed)
        {
            sqlTrans.Commit();
        }
        else {
            sqlTrans.Rollback();
        }
        sqlConn.Close();
    }
}


ref:
[1] 網站製作學習誌
[2] 程式設計筆記byChris

2012年2月15日 星期三

[Programming] 物件導向(1)


不妨仔細想想,為什麼要用OOP?使用OOP有什麼好處?沒有它難道就會死人嗎?

C語言以前是以程序導向的方式做資料的交換和運算,並沒有什麼模組化、結構化的概念在裡面(其實還是有struct可以用,但是功能不強)。日子久了,同一隻程式不斷被維護、修改,或是又再增加新的需求,只會讓程式變得越來越難懂,越來越難維護,時間久了程式就沒辦法再持續維護下去了,程式就壞掉了。
這種程式呈現出來的樣子,就很像把三百五十種水果一起放到果汁機裡面打成汁再喝下去,你沒辦法知道讓你拉肚子 (bug) 的原因是哪一種水果,或是哪些水果的組合。

而OOP,能夠較容易將現實生活中的一切把它mapping成程式物件,進而描述物件和物件之間的關係,使程式容易和現實業務背景相結合,如此一來,就程式撰寫、閱讀上比較能夠容易被理解。所以,物件不光只是一個可以裝有客製化變數類型的"容器"而已,還有很多更近一步的關係可以建立及使用,以達到提高可維護性和「one rule, one place」的目的。
簡單來說:物件導向程式設計,能夠讓程式較容易被理解,也容易將其模組化

當然,一切都是以「能夠設計出適合的物件關係為前提」。



物件導向程式設計(Object-oriented programming, OOP)已經存在好長一段時間了,十多年前開始接觸VB的時候應該就有這種程式設計概念了,讓寫程式不光是用複雜(或不怎麼複雜)的程式指令來控制變數、計算和輸入輸出,更能讓現實生活中的實體概念直接對應到程式物件裡來,使程式更容易維護和撰寫。

要寫一個物件導向的程式其實沒有很難。就像在現實生活中,看得見的或看不見的實體,都可以把它想像成是一個個的物件,物件中有屬性,然後由外力來控制物件。寫該類程式也是如此。最基本的做法就是把要用程式表達出來的東西寫成類別(class),然後在需要使用到它的時候再宣告成一個(或多個)物件(object)。
一個超級老掉牙的例子:一個學生的類別,要記錄該生的姓名、性別和成績。
這個例子我完全不知道性別和成績之間的關係,但是管它的,反正需求就是這樣開....

class Student{
 private String name;
 private boolean sex;
 private int grade;

 //Constructor
 public Student(String name, boolean sex, int grade){
  this.name = name;
  this.sex = sex;
  this.grade = grade;
 }

 public String getName(){ return name; }
 public int getGrade(){ return grade; }
 public void SexTransform(){ sex = !sex; }
}

這樣寫,Student就非常簡單、草率、無用地完成了(請不要問我一個學生幹嘛要SexTransform()方法,我只能說這很宅)。
然而,如果OO概念只能達到這種程度的功能,那它不會流傳數十年,至今仍被人大量使用(應該吧?)。


つづく......

ref:
[1] 搞笑談軟工

2012年2月9日 星期四

[未來日記] 謹此紀念一名勇士: 戰場馬克(7th.)

雖然你的髮型真的很醜,但是你是個真男人。

戰場馬克:讓我們重新自我介紹一下!我們是7th.,戰場馬克!
美神愛:同為7th.,美神愛。
Both:這就是我們的日記,交換日記!
夫妻倆的華麗登場。

馬克:吶~1st. 你相信愛的力量嗎?我的日記是為了保護愛,一直持續觀察著愛的love日記。
:我的日記是為了保護馬克,一直持續觀察著馬克的love日記。
Both:也就是說,所謂交換日記,就是將這兩個合起來的love love日記~(小花)
其實這畫面滿搞笑的XD

單挑來說,愛不是我妻的對手,我妻居然可以用匕首格擋飛刀....太作弊了吧!?於是兩人決定先徹退,讓後勤部隊把房子燒了。

讓我真正對這對夫妻留意的是....火燒房子之前,還把中間的受害路人救起來,拖出房子外,還加以療傷....應該是個寧願光明正大戰鬥也不願連累無關路人的熱血笨蛋吧?比起我妻那種可以隨便犧牲別人來換取一時的脫逃,夫妻倆相對來說可是善良多了。 




於是再兩人再重回火場,義無反顧地用背影回答.....
馬克:當然是做個了斷,那些傢伙的love根本不是愛!


同樣不是外掛仔2nd. 我妻由乃的對手。但是因為兩個人都願意以自身性命保護對方,所以還是外掛我妻還是在大火中被逆推推掉了。


這時候,1st. 廢雪也語出驚人地講出一句不該是由主角口中講出來的話.....
馬克:你為什麼不救你的女人?女人陷入危險的時候即使是火海也要跳進去!這才是男人!這是不關乎愛的原則問題啊!(怒)
廢雪:由乃說了,說我依賴她就行了....
馬克:你到底是有多差勁....
廢雪:我也沒辦法啊!我也知道我很差勁啊!可是.....我真的很弱啊......(泣)
馬克:...........(青筋) 去死吧!

劇情演到這裡,我就徹底對廢雪絕望了。就算他有神愛世人的溫柔,就算聽說他以後外掛開得比我妻還兇,我還是無法喜歡他。
更何況他是個只想到自己的安全,利用著喜歡自己的女人的人渣。


在那之後,廢雪和我妻雙雙住院。廢雪還在住院的時候得到哥德式炸彈妹的幫助,管他去死。
而馬克正利用從廢雪和我妻的未來日記得到他們的現況,並且用計把他們拐出來,再教訓一頓。而且,就在這時候,他們決定結婚了!

愛:這是怎麼回事?(陰沉)
馬克:啊?
愛:[馬克和神祕女人幽會還樂呵呵的聊著天]
馬克:蛤? (汗)
愛:這女人是誰?(陰沉)
馬克:我哪知道啊......
愛:少裝傻,日記上寫得一清二楚
馬克:等等....那是....(汗)
愛:[馬克興高采烈的收下女人的禮物].....難以置信,我被拋棄了嗎....(闇)
馬克:我....我怎麼可能這麼做....我可是對愛妳...
愛:好過份!我那麼信任你,你說過會永遠愛我!Q口Q(哭)
馬克OS:這....這到底是怎麼回事.....我不可能會背叛愛的....
愛:[馬克看著收到的禮物心花怒放得下巴都要掉下來了]
愛:[馬克叫我出來說有話要談]....一定是要提分手!Q口Q
馬克:不可能啦!
愛:我被欺騙了嗎?Q▽Q.....(淚)
馬克:這絕對是誤會啦!
愛:[馬克把那個小盒子給了我 打開一看 裡面是一枚漂亮的戒指].........馬克...這是....?
馬克:啊.....那個~我想差不多是時候了...是有這個打算...
愛:馬克!O▽Q(飛撲) 果然馬克是我的darling!
馬克OS:去買戒指吧!(笑)

這一段我笑好久XD,而且好甜蜜啊~

劇情發展到這裡,簡單來說就是馬克看不爽廢雪的無能懦弱,決定用人質、未來日記、戰鬥來激發他。
又是一次戰鬥,馬克要求廢雪出來單挑,當然是被打臉,但是就氣魄上來說,是有長進一點。但是單挑到一半,這座塔就被爆破了.....



畫面回到馬克和愛邂逅的那一天.......
「我們很快就回來哦~在這邊乖乖等著哦~」

「我們很快就回來哦~在這邊乖乖等著哦~」
「我們很快就回來哦~在這邊乖乖等著哦~」
「 很快就回來 ~」
「 很快就回來 ~」
....
那是十四年前,愛被雙親拋棄的那天
愛:「.....差勁透頂!」(淚)
馬克:「這是好事啊~今天差勁透頂,就表示明天一定會比今天美好!對吧?」
那是十四年前,愛被馬克撿回孤兒院的那天(馬克也是孤兒)
那是高中剛入學時.......
馬克:「喂....為什麼跟著我啊?」
愛:「 為什麼.... 」
馬克:「 一年級的教室在樓下吧? 」
愛:「 是.... 」
馬克:「 別跟著我了....趕緊學會自立吧! 」
愛:「......」(垂頭, 不安)
馬克:「 .......啊啊~真拿你沒辦法 」
愛:「^__^」
來到櫻見塔,也是起點......
愛:「我....想在這裡舉行婚禮。馬克說的沒錯,馬克把我從差勁透頂的人生變得美好....」
愛:「我就喜歡這裡....」



那是,兩人為彼此立下誓言的那天
愛被同學以馬克的名字誘騙到廢工廠,被輪姦。等馬克急忙趕到現場的時候,一切正在進行式,於是,理智線斷裂、瞳孔放大....

馬克:「對不起.....」
馬克:「如果我在你身邊.....」
馬克:「妳就不會.....」
馬克:「怎麼會變成這樣.....」 (看著手上染血的蝴蝶刀)
馬克:「我已經完了....發生了這種事,已經無法挽回了.....」 (舉刀)
愛:「不要!」
愛:「不要啊.....馬克痛苦的時候我來保護你.....難過的時候我陪你一起哭......」
愛:「所以.....所以不要丟下我一個人......」
馬克:「.....我不會丟下妳的.....我會保護妳,直到世界的終結.......愛..」
那是,兩人發誓,永遠在一起的那一天。

未來日記動畫第17集在撥OP之前花了將近七分鐘的時候交待他們的過去。



回到爆破的場景,我也懶得多說明戰鬥的內容,反正就是.....
馬克的戰鬥能力比我妻更勝一籌,最後還是被用計婊掉了。
最後馬克被支開,我妻直接轉身割開愛的喉嚨。這時候,天花板崩塌,把廢雪、我妻、愛三人困住。
此時....我妻以重傷的愛為人質,要求自由之身的馬克把石頭挖開。
馬克:「等著我!愛!我馬上就救妳出去!我們不是要一起成為神,永遠在一起的嗎!不管發生什麼事我都要保護妳!」
愛:「不要....馬克....反正我都要死了....」
我妻:「不,這樣很好,繼續下去。這個女人是人質!」
廢雪:「夠了,由乃.....」
馬克:「這不是讓他住手的問題吧!1st!明明不弄髒自己的手,只會讓2nd保護你,還說什麼要人道的話,你說的話還真是不要臉啊!」
廢雪:「........」
馬克:「你在幹什麼!你給我在下面推一下啊!1st!」
廢雪:「但是....這不就正中由乃的下懷了嗎?」
馬克:「是誰在不斷保護你,殺死敵人,你只是想把髒活累活全推到2nd身上吧.....」
廢雪:「......」
馬克:「不行了.....喂!2nd!你也來幫忙!」
我妻:「少對我發號施令!」
馬克:「你也是一樣!說什麼要保護1st,卻任意地扭曲1st的想法,這根本不算是協助,這是自私!」
我妻:「你給我適可....」
馬克:「該適可而止的是你啊!你這臭小鬼!你認為我是受到威脅才做這些的嗎?不要小看我,我一開始就沒有打算要逃走!」
愛:「馬克,住手.....已經夠了,我馬上就要.....」
馬克:「就快要死了?跟我沒有關係!那種東西給老子滾一邊去!別把我們的愛跟你們的愛相提並論啊!」
撐開石頭之後,眾人發現馬克的腹部被銅管刺穿。
愛:「馬克.....」
馬克:「抱歉啊.....我也中槍了....」

馬克:「我....又沒有趕上呢....」
馬克:「成為神,兩人永遠在一起的計畫,失敗了呢。」
未來日記:馬克來救我了,果然還是馬克最好了。7th DEAD END。
馬克:「但是啊....這,也算是永遠吧。」




櫻見塔倒塌。



年紀越大,對這種東西越沒有抵抗力。
看第一次就流淚了,記錄這篇又流一次淚。

2012年2月7日 星期二

[軟體工程] 製造業 vs 軟體業

本人不學無術,只有看過一些文章,上過幾次課而已。本文是根據作者以稀少的親身體驗和think too much的哲學性思考,所得到的一些想法。感謝我的摯愛提供大量background。



製造業,就我所了解,是一種「別人叫你做什麼就做什麼」的行業 (話說回來,大多行業都是如此吧)。別人提出需求、下訂單,然後廠商就按照需求,經過設計、製造,把東西做出來,有必要的話,最後會量產批發。似乎產製任何東西都可以套用這套流程,畢竟它會經過計畫以後再進行,小心翼翼地做事比較不會老馬。一切都很合乎邏輯,非常直覺~

那麼,這種製造方法,適不適合用來做軟體呢?

「有什麼好不可以的?先知道要做什麼,再進一步分析設計開發測試,哪裡有什麼問題?」
沒錯!先做好計畫再進一步動手工作確實是很正常、很正規、很傳統的流程,而這套流程模型,在軟體工程當中有一個聽起來很專業,背後意義卻很簡單的專有名詞,為「瀑布式模型」。
瀑布式模型 (waterfall model) 是至少20年前的東西了,但是現在還是非常普遍地在使用,原因無它,就是因為它的理念很簡單:先明白需求、再經過分析、設計,再進行開發,最後再測試和上線。流程上非常的合理,就像製造業在產出任何一樣東西,也是先要知道要達到什麼目的,才會去設計它、量產它。而且有經過精心的分析和設計,所以對產品的品質有一定程度的保證。
流行二十年的東西,代表它有一定存在的價值,就像BBS一樣,早期的技術到現在還在用。


事情真的這麼簡單的話,我就不用在這裡靠夭了。


試想,你是一個使用者,而今天需要開發一套系統來讓你的工作更為順利,你能夠很明確地告訴系統分析師或是跟你訪談的那個人說「你需要什麼」嗎?不要覺得這很簡單,其實這是有難度的。這中間往往會發生你覺得你已經講得很清楚了,分析師還是聽得一蹋糊塗(這不能怪他!全世界熟悉你的工作的人只有你自己,對他來說那都是新的東西),或者是你根本就沒講清楚,然後軟體寫好了以後才發現根本幫不上你什麼忙,一切都是白搭。更不要說,從敲定需求以後到開發完這段時間,需求又在不斷變化。最後怎麼辦?要不是做出來的東西根本幫不了用戶,就是讓開發程式的人改到死。

因此,瀑布式模型可能會適合一開始就需求很明確的專案,然後經由嚴謹的流程來保證產品的品質;但是絕對不適用於連使用者都不是很清楚他自己想要什麼東西的情況。
微妙的是,大部分的軟體開發專案,使用者都不知道想要什麼,而且瀑布式模型用得非常開心。據說,十年前的作業方式就已經是這樣了,而且現在還沒有什麼改變。(前途真堪慮)

事實上,實際在操作開發方法時,有時候還會再加入一些額外的小機制,來降低需求浮動的風險,像是利用雛型來挖使用者的需求、分割子系統、加入風險管理機制.....等,而科學最厲害的地方是,只要一點點不一樣,就可以把它講成是很不一樣的東西。只是,它們都還是一些waterfall-based的開發模型,本質上並沒有多大的改變,問題根本不會解決。

而製造業和軟體業產出來的產品,差別在於:製造業者如果夠不要臉,他大可以說「我東西都做好了,不爽不要用,要改就要拿錢來,你沒看到這個成品的成本要花多少錢嗎?」;而軟體業沒有「實體」,所以看起來好像不需要成本,只要和神(ㄒㄧˋ)燈(ㄊㄨㄥˇ)巨(ㄔㄤˇ)人(ㄕㄤ)許個願,就可以把一個九九乘法表程式變成Excel引擎。(請原諒我用很酸的方式來陳述這件事,因為我真的很酸)
如果你是寫程式的人,你聽到使用者這樣講,不會覺得很逼機嗎?尤其是每當他們要改什麼東西的時候就說「只是變成OOXX而已,要修改應該很快吧!」

好了。現在我們知道:做軟體的,不能把需求看作是一個不會變化的常數,而要看作是一個會變化變數,而且變動幅度可大可小,端看推動專案的技術和手腕。那麼,這應該怎麼去操作呢?



這種問題在十幾年前就已經被發現了,當時也提出了一些方法來改善這個問題,像是演進式策略 (Evolutionary Development Strategy)、拋棄式策略 (ThrowAway Strategy).....等。演進式策略,簡單來說就是由已經確定不會再變化的地方開始先行開發,再慢慢一個階段一個階段地完成細部設計和開發,以完成系統。這方式同樣也很容易理解,但是容不容易做到又是另一回事,假如SA/SD功力不夠渾厚,辟邪劍法練之前沒先自宮,沒辦法分辦哪些東西是可以先開發,哪些東西是還不明確的,這樣的作業方式風險更大,而且,需求可能是一個階段一個階段累加上去的,所以恐怕會有系統難以維護之虞;而拋棄式策略則相反,先用很簡單、粗糙的方式快速開發出需求還不明確的地方,再和使用者做進一步的溝通,反正那也只是做確認用,用完就丟掉了,但是呢....開發拋棄式軟體一樣要時間要人力,意味著這些東西成本,做出來的軟體都是產物,然後用完就丟掉,等於在成本上是一種浪費。

既然上面這兩種方法都還有這麼明顯的缺點,那我提它幹嘛?
在距今十多年的時空,Kent Beck提出了極限編程 (eXtreme Programming, XP) ,它的概念就有點類似演進式策略,但是卻又更加的積極去面對需求的變化。其實它的立場,並不會去壓抑需求的變化,反而是將它視為理所當然,而且是一定會需要面對的一環。無法逃避、不能退縮!
而極限編程強調一點:要求團隊在開發的過程必須朝正確的方向前進,在一次又一次短暫的階段循環當中不斷地修正策略,每個階段開始之前要先有個簡單的計畫、每一個階段開發少量、且確定是使用者需求的量,讓程式有效利用的程度最大化,並且仔細看寫完的程式是否能夠模組化、是否能夠更加精簡化,如果能夠精簡化,是必須要有改掉重修的覺悟和勇氣的,使開發和維護一次到位,一切從簡,不需要太複雜的設計。

還有一點是很特別的:Kent Beck認為開發程式不需要太多浪費許多時間產出的文件,只要有 C4 測試案例就搞定了!
「開始寫程式之前,先把自動化程式的測試案例先寫好再說!」
藉由撰寫自動化測試的程式,讓程式設計師來省視自己對需求的了解情況,待許多自動化測試的案例完成以後,才開始開發程式的主題。一隻程式寫完以後,需經過自動化測試來檢查程式的正確性;許多程式寫完並整合再一起以後,需經過自動化測試來觀察整合的情況。總之,開發程式的過程就是不斷的測試開發測試開發測試開發測試開發測試開發測試開發....
至於文件,Mr. Beck是認為不太需要,有大量的測試案例,中間還有許多會議中要呈現想法的UML圖,就足以表達需求、設計或演算法的內容,而且寫文件容易流於形式,搞到最後花了一大堆時間去寫,到最後對軟體開發的過程一點幫助也沒有。
極限編程的要點大致上就是如此。設法讓工作量最小、滿足最大量的需求,並且透過大量的自動化測試案例來維持程式的品質,再更詳細的內容,擇日,了解更深入的極限編程技術後再與大家分享。

如此的作業方式,就需求變不變化就不是問題了,那根本不是問題,而是一定會發生的事。需求一定會隨著時間有所變化,正視這些變化,而並非壓抑它,讓產出來的程式能夠精準有效地滿足客戶的需求。系統在開發的過程隨時保持高度的彈性,以利於軟體擴充及維護,所以被視為敏捷式開發 (Agile software development) 的一種類型。

兩大種方法
如果你是客戶,你希望得到怎樣的服務?
如果你是開發商,你希望你的客戶得到怎樣的服務?
如果你是程式人員,你希望你的作業方式是哪一套?



這個概念被提出至今,已過了十多年的時間了,這段時間,Kent Beck仍然設法不斷簡化流程。這套方法在國外已陸陸續續被使用且接受;而國內,就我目前所看到,雖然有些勤奮不懈的小人物大英雄們在默默宣導推動著,但是還是使用傳統開發方法居多。原因嘛....除了無能、沒有遠見、沒有勇氣等,可能還有一些華人的教育、人性因素、環境因素等在裡面作祟。

回到主題「製造業 vs 軟體業」,我聽說這陣子的成衣業有一種很新潮的製造方式:設計衣服的廠商會先做出各種不同的板型,然後釋放出來,再統計看看哪些板型的衣服,因為哪些原因而賣得比較好,再把這些很夯的因素加進板型上,再大量釋出版售。
這個做法,和extreme programming的概念有些類似。時代的演進當中,製造業的作業方式也在不斷在進步,為了生存而研發、實務了一套適用於這個時代,滿足廣大需求的推動方式。
以高科技產業自居的軟體業,卻仍抱著二十年前的作業流程不放。要是給外國人還是外星人知道,大概會被笑到把台灣倒插在海底吧....

哪個傳奇英雄來改變一下台灣的軟體科技業吧!