JOOP 文章的洞見如何促進了後續的發展
2025/09/13 01:42
瀏覽275
迴響0
推薦1
引用0
前一篇 < 做得很不錯的 IDE ── Code:: Bocks > 當中提到 JOOP 幾篇具有洞見的文章，筆者就延續這個話題扼要分享個人看法。
1990 ～ 1994 年間，OOP 非常火紅，因此眾多 Software Experts and Devlopers 是熱烈擁抱 OOP 的 Inheritance 與 Polymorphism 等新觀念，甚少人提出具體的例子來指出其中的不足與過度擁抱的錯誤，30 多年後回頭來看這件事情， James J. Odell 的文章 < Dynamic and Multiple Classification > 很明顯地正是當頭棒喝的代表作之一，而且影響深遠，它促成了 Composition over Inheritance、Interface-Based Design、Role-Based Modeling 的發展，而 Domain-Driven Design 也有受它啟發而發展出來的概念 (他在文章中所舉的例子，就是 Composition over Inheritance 的實例之一，只是當時還沒有 "Composition over Inheritance" 這個術語；更精確地說，他所舉的例子是 Dynamic Composition over Time)。
1990 ～ 1994 年間，OOP 非常火紅，因此眾多 Software Experts and Devlopers 是熱烈擁抱 OOP 的 Inheritance 與 Polymorphism 等新觀念，甚少人提出具體的例子來指出其中的不足與過度擁抱的錯誤，30 多年後回頭來看這件事情， James J. Odell 的文章 < Dynamic and Multiple Classification > 很明顯地正是當頭棒喝的代表作之一，而且影響深遠，它促成了 Composition over Inheritance、Interface-Based Design、Role-Based Modeling 的發展，而 Domain-Driven Design 也有受它啟發而發展出來的概念 (他在文章中所舉的例子，就是 Composition over Inheritance 的實例之一，只是當時還沒有 "Composition over Inheritance" 這個術語；更精確地說，他所舉的例子是 Dynamic Composition over Time)。
具有洞見是一種相當難能可貴的能力，一般人需要閱歷、知識、以及智慧的累積，才能看得出它的珍貴之處，筆者也是年紀大了才看出這幾篇文章的可貴之處。
年輕的時候，尤其是學生與剛進職場之際的新鮮人，對技術非常著迷，總是想要精通某些最新的技術與新知來展現自己的 Technical Prowess；過了幾年，有些人開始領悟到，能夠基於客戶的要求，搭配 Domain Knowledge 將 Data Structure & Algorithm 做些調整與適應(變形)，讓自家的 Domain Product 更符合客戶的需要、或提升自家 Domain Product 的效率與能力等等，是更為重要的事情；再經過幾年，照理說應該要開始看到與學到 Software Architecture、Software Modeling，以及公司裡應該要有個職位是在做這些事情，但遺憾的是，這樣的職位需求，在台灣的公司並不受重視，而另一個也可以稍為看到整體架構的職位，例如 Project Director (Project Manager 其實還看不太到)，通常會由不太懂或甚是不懂軟體的 Domain Expert 來擔任，如果是由完全不懂軟體的 Domain Expert 來擔任 Project Director，通常與 Software Developer 的溝通就很有可能會出現如下的對話：
啊這些新功能不是程式寫一寫就做出來了嗎？有那麼難嗎？
不懂軟體的人，無法體會「軟體研發就像是在蓋房子」，已經蓋到了第十樓，然後突然說第五樓要增加多少建坪的樓地板面積、第三樓要增設一座電影院、第七樓要改建成籃球場以及羽毛球場等等，而這些在當初的規劃裡是全部都沒有，根本沒有寫入規格書當中，講完新功能的要求後，臨走前還丟下這麼一句話：
啊這些新功能不是程式寫一寫就做出來了嗎？有那麼難嗎？
相信在台灣的軟體工程師，在生涯當中或多或少都有聽過這樣的話；真正困難的當然不是單純的寫程式，而是長期累積下來的軟體結構與設計，遇到某些當初沒有考慮到的新功能與需求 (某些，不是全部；有些當初沒有考慮到但還是能做得出來)，要做出來是會遇到相當的困難或根本做不到，如果不以蓋房子來做比喻，不懂軟體的人是幾乎無法理解與想像軟體的複雜度。筆者任職 EDA Sector 時的一位同事，他是清華電機系與所畢業的，是公司 Layout Tool Laker 的研發工程師之一，他後來轉職到台積電，也是負責撰寫一些程式，他曾經跟筆者分享過他的台積電主管跟他講過的一句話，他說他的直屬主管要他寫一些程式提供一些功能，講完後竟然順口說：
啊不就是 printf() printf() 一直 printf() 就做出來了嗎？
實際情形當然不是如此，如果只是一直 printf() 就做出來了，那就請一個外籍移工來做就可以，何必聘請一位清華電機系與所畢業的工程師來做這些事情？這名主管只是想表達「對寫程式與軟體研發的輕蔑」罷了！
So，這就是在台灣當軟體工程師在職場上所須面對的現實。
雖然講這些是有點晚了，但筆者還是跟目前還很年輕的人分享一下：
你如果很喜歡做軟體，那你就要到軟體的搖滾區去工作。
軟體的搖滾區是什麼意思？
What I mean is, 到美國去求發展，美國才是軟體的搖滾天堂！
儘管 AI 的興起讓初階入門的軟體工作機會少了許多，但美國仍是軟體的搖滾天堂！
Domain-Driven Design 這個 Methodolgy 為何是在美國孕育與發展出來的，而不是其它國家？答案已經很清楚了── 軟體職場重視軟體開發議題與美國本土的軟體市場夠大、以及全球頂尖的軟體公司與人才大部分都聚集在美國；據此，如果你現在還年輕，也沒有家累，而且你非常喜歡做軟體研發的工作，那麼：
到美國去求學並留在美國工作吧！美國才是軟體的搖滾天堂！
美國的軟體公司有較多機會可以實際學到層次較高的 Modeling 與 Architecture Design，但要從基層往上爬到夠高的職位就是(指實際產品線的 Software Modeling and Architecture Design, 非指學術研讀與討論)；此外，累積一定的經歷之後，找幾個人一起創業也行。
雖然這篇文章寫到最後有點歪樓，但筆者所陳述的是事實，需要做決定時可以做為參考。
Wow！沒想到寫著寫著就寫到深夜了，最後跟大家說聲：
晚安！
年輕的時候，尤其是學生與剛進職場之際的新鮮人，對技術非常著迷，總是想要精通某些最新的技術與新知來展現自己的 Technical Prowess；過了幾年，有些人開始領悟到，能夠基於客戶的要求，搭配 Domain Knowledge 將 Data Structure & Algorithm 做些調整與適應(變形)，讓自家的 Domain Product 更符合客戶的需要、或提升自家 Domain Product 的效率與能力等等，是更為重要的事情；再經過幾年，照理說應該要開始看到與學到 Software Architecture、Software Modeling，以及公司裡應該要有個職位是在做這些事情，但遺憾的是，這樣的職位需求，在台灣的公司並不受重視，而另一個也可以稍為看到整體架構的職位，例如 Project Director (Project Manager 其實還看不太到)，通常會由不太懂或甚是不懂軟體的 Domain Expert 來擔任，如果是由完全不懂軟體的 Domain Expert 來擔任 Project Director，通常與 Software Developer 的溝通就很有可能會出現如下的對話：
啊這些新功能不是程式寫一寫就做出來了嗎？有那麼難嗎？
不懂軟體的人，無法體會「軟體研發就像是在蓋房子」，已經蓋到了第十樓，然後突然說第五樓要增加多少建坪的樓地板面積、第三樓要增設一座電影院、第七樓要改建成籃球場以及羽毛球場等等，而這些在當初的規劃裡是全部都沒有，根本沒有寫入規格書當中，講完新功能的要求後，臨走前還丟下這麼一句話：
啊這些新功能不是程式寫一寫就做出來了嗎？有那麼難嗎？
相信在台灣的軟體工程師，在生涯當中或多或少都有聽過這樣的話；真正困難的當然不是單純的寫程式，而是長期累積下來的軟體結構與設計，遇到某些當初沒有考慮到的新功能與需求 (某些，不是全部；有些當初沒有考慮到但還是能做得出來)，要做出來是會遇到相當的困難或根本做不到，如果不以蓋房子來做比喻，不懂軟體的人是幾乎無法理解與想像軟體的複雜度。筆者任職 EDA Sector 時的一位同事，他是清華電機系與所畢業的，是公司 Layout Tool Laker 的研發工程師之一，他後來轉職到台積電，也是負責撰寫一些程式，他曾經跟筆者分享過他的台積電主管跟他講過的一句話，他說他的直屬主管要他寫一些程式提供一些功能，講完後竟然順口說：
啊不就是 printf() printf() 一直 printf() 就做出來了嗎？
實際情形當然不是如此，如果只是一直 printf() 就做出來了，那就請一個外籍移工來做就可以，何必聘請一位清華電機系與所畢業的工程師來做這些事情？這名主管只是想表達「對寫程式與軟體研發的輕蔑」罷了！
So，這就是在台灣當軟體工程師在職場上所須面對的現實。
雖然講這些是有點晚了，但筆者還是跟目前還很年輕的人分享一下：
你如果很喜歡做軟體，那你就要到軟體的搖滾區去工作。
軟體的搖滾區是什麼意思？
What I mean is, 到美國去求發展，美國才是軟體的搖滾天堂！
儘管 AI 的興起讓初階入門的軟體工作機會少了許多，但美國仍是軟體的搖滾天堂！
Domain-Driven Design 這個 Methodolgy 為何是在美國孕育與發展出來的，而不是其它國家？答案已經很清楚了── 軟體職場重視軟體開發議題與美國本土的軟體市場夠大、以及全球頂尖的軟體公司與人才大部分都聚集在美國；據此，如果你現在還年輕，也沒有家累，而且你非常喜歡做軟體研發的工作，那麼：
到美國去求學並留在美國工作吧！美國才是軟體的搖滾天堂！
美國的軟體公司有較多機會可以實際學到層次較高的 Modeling 與 Architecture Design，但要從基層往上爬到夠高的職位就是(指實際產品線的 Software Modeling and Architecture Design, 非指學術研讀與討論)；此外，累積一定的經歷之後，找幾個人一起創業也行。
雖然這篇文章寫到最後有點歪樓，但筆者所陳述的是事實，需要做決定時可以做為參考。
Wow！沒想到寫著寫著就寫到深夜了，最後跟大家說聲：
晚安！
你可能會有興趣的文章：
