同人的生活派對

Brecht 對石頭成的〈非資訊科班的程序員？〉的迴響中提到：

一般自修出師的程式設計師，容易出現的通病是學技巧而不學基礎，往往以致用為目標。尤其是 .NET 派的程式設計師，只要拉拉元件就可以完成工作，對於資料結構、演算法知之甚少也無所謂。

往基礎鑽進是費力而收效不見得明顯的 effort，我常以為這就是科班與否的差別所在，科班出身的人，通常這部份會較為紮實（當然也會有人混水摸魚啦，不過我們還是要對教育 or 考試抱持一定的信心）。

同人不知道 Brecht 此言是因為看過非資訊科班出身的編程者之基礎較科班出身者的來得薄弱，還是他「想當然耳」的臆測。不過，這倒和同人所觀察到的現象有所不同，我較認同石頭成文章中的結論中所提到的：

我一向不認為性別、科系，與程式設計能力有關。因為程式設計是種容易接觸與實證的知識。只要有一顆能思考的頭腦，加上一隻筆和一張紙，就可以寫程式。只要有台電腦，就可以實證。日起有功，不必妄自菲薄。

軟體開發的知識是築基於實務中的理論，在學校中所能夠學到的，總是比產業的腳步慢上許多。所以有志於程式設計工作的人，從學校畢業以後，他還是必須從實際的軟體開發過程中不斷地磨鍊其編程基礎及技巧。依同人實務所見，程式設計基礎與開發者是否科班出身沒有關係，但卻與開發者對程式設計的興趣及熱忱有關。
閱讀全文 →

一般人以「軟體工程」來說明軟體專案的開發過程，但對於軟體所要解決的問題不複雜、參與開發的團隊規模不大、以及開發時程不長的軟體專案而言，軟體工程卻又太複雜了。於似乎有人認為不應該拿「軟體工程」來比喻軟體專案的開發過程。例如《软件工艺 Software Craftsmanship》這本書，提出了軟體工藝的新隱喻。而我有一位學長喲哪桑也發表了他看此書之後的心得感想。

喲哪桑認為「軟體工程」雖然可以幫助我們了解與學習軟體開發，但它卻並不等於軟體開發的本體呀。學長認為「軟體工藝」可成為一個新的隱喻、新的tag，從極致的工藝技術來比擬軟體開發。如此，關鍵將落在於重視軟體開發者的技能、經驗與才華。換句話說，他認為是人的能力左右了軟體的成敗而非工具與技術。

所以，軟體開發是工藝乎？喲哪桑也不敢驟下斷言，但他認為，可以選擇少把 process compliance 掛在嘴邊，而多談 PSP 及 TSP，回歸「以人為本」的軟體開發。而獨孤木看了學長所發表的心得，也提出他對軟體開發的看法，他則認為軟體工程的大部份理論，都是導源於開發軟體時，有很多人需要一起合作，所以需要建立共同的溝通方法與管道，以及一些共用的工作紀律。所有的軟體工程理論，其實都只是在告訴你，在人數眾多時，應該要遵循什麼樣的開發方式，才可以避免或解決他們所面臨的問題。

換言之，軟體工程的目的是提供一種開發方式，讓軟體開發的工作，能做適度的分工，同時也讓開發者之間的溝通，能夠順利進行，以避免或解決在軟體開發過程中，可能會遭遇的問題。然而，站在軟體工藝的角度而言，對於軟體規模不大、參與開發的人數不多、開發工期不長，對於技藝超群的開發者而言，根本就不需要考慮分工及與其它開發者溝通的問題。只要他能夠把客戶想要的軟體做出來，一切問題都會得到解答，是嗎？
閱讀全文 →

記得在 EMBA 策略管理課程中，林維熊教授在第一堂課就跟我們討論核心價值觀的問題。他問我們一個問題，經營者決定企業的策略目標關鍵在那裡？經過學長姐們熱烈的討論後，大家得到一個結論：

企業的策略目標取決於經營者心中的核心價值觀。

由於經營者選擇不同的核心價值觀，讓他看到的世界也有所不同；有些經營者認為成本是最重要的，這樣可以取得價格優勢，於是乎在這樣的經營觀點下，企業活動的價值在於不斷地投注資源來獲取規模經濟的好處；然而，也有一些經營者認為創新才能獲取競爭優勢，藉著差異化的手法來提昇附加價值及品質優勢才是永續經營之道，在這樣的經營觀點下，企業活動的價值並不在於企業生產了多少產品，而是創造了多少知識，而這些知識將會成為使企業立於不敗之地之立基。

其實，選擇沒有所謂對錯問題，而只是有所不同。林教授告訴我們，他非常不認同某位經營者用小便顏色來衡量員工的工作態度，因為在「為達目的，不擇手段」的管理心態下，經營者不可能會去真心地關懷員工，員工也沒有必要為經營者「躹躬盡瘁，死而後已」。那麼經營者與員工的關係就會是一種因利益而結合的相互利用關係，而不是基於為共同目標而建立的相互信任的夥伴關係。所以，林教授認為那位經營者的這種心態，其實是非常不健康的。

同人在看了喲哪桑學長的〈工作時間的問題，是工作態度的問題〉後，讓我想起了以上策略管理所學內容。其實，同人認為學長只說對了一半： 閱讀全文 →

同人曾為一個軟體專案設計及建構服務導向架構。為了在軟體開發過程中，便於開發及測試，所以在架構上的設計上，在前端程式呼叫 Services 方面，是透過組態設定來決定直接連接後端的應用系統或間接透過如 Web Services 的遠端程序呼叫調用後端應用系統[ref]前端程式直接連接後端應用系統是為了開發階段測試方便，而正式上線後為了軟體配置考量則需要透過間接遠端程序呼叫調用後端應用系統。[/ref]，透過組態設定的好處是不會因為軟體運作環境的不同配置而更動程式，並且可以巧妙地隔開各元件的相互耦合而達到獨立測試的好處，開發者也可以更專注在其專業領域上來開發系統。

這樣的架構可以做到為維護而設計，可是，這樣設計不可避免地會面臨到一個問題：物件要怎麼做到遠端傳送呢？對於每個領域物件，我們不希望另外寫 Value Objects/DTOs，我們希望用簡單樸實的 POJOs，有關領域物件的傳送，一個可能的做法便是：先將領域物件序列化成 Xml 格式，再傳送到遠端的目的地後再將 Xml 格式反序列化成領域物件。依據這樣的設計思路，我們找到了 XStream 這個 framework，它實作了各種 Java 物件的 Converters，可以把任何 Java 物件序列化成 Xml 格式及將 Xml 格式反序列化回 Java 物件，而且，它的 Xml 物件格式非常的簡單且直覺，對於複雜的物件，它甚至還提供自訂 Converter 的機制讓開發者能自定處理複雜物件的序列化／反序列化。

我遇到過最複雜的領域物件，使得 XStream 無法以預設的 Converters 來序列化／反序列化，應該就非 POI 的 HSSFWorkbook 莫屬了，那是一個 Excel 的 workbook 物件，我的解法是利用 XStream 的自訂 Converters 機制，在序列化時將 HSSFWorkbook 物件轉成檔案串列流，反序列化則將檔案串列流轉成 Excel 的 workbook 物件。

不過，最近同事跑來找我求助，他發現在配置軟體系統的時候有錯誤發生，應用程式伺服器日誌顯示有物件無法從前端傳回來。從發生問題的程式片斷來研判，我猜測大概是 XStream 反序列化某個物件的時候出問題，為了確認問題所在，我寫了測試程式來確認它，結果不出所料，看起來那個物件太複雜了，應該要為它再寫 Converter 嗎？

慢著，這樣做好像不是有效的解決問題之道。因為，那個物件明明是只有後端程式才會用到的控制程式，為什麼需要傳到前端呢？程式這樣寫，其實是違反了 GRASP 的設計理念－不跟陌生人打交道的設計原則[ref]參考趙光正譯（2002），《UML與樣式徹底研究》，臺灣培生教育出版股份有限公司。[/ref]：

將責任委派給前端程式的直接對象，讓這個直接對象與後端的間接對象協同運作，這樣前端程式就無需知道後端的間接對象的存在。

閱讀全文 →