文/iThome (記者) 2008-06-17
過去大家想都沒想過的「石油因素」對於電子商務的影響，可能高過我們多數人的預期與想像。油價漲，勢必要帶動水、電、裝潢、人工、店租等等的成本跟著上漲，而這些也都將拉大傳統交易模式和電子商務間的價格距離。
在過去，電子商務能否成為我們的社會商品交易的主流模式，一般認為主要的關鍵問題，會是在於頻寬的供給、消費者的使用習慣、物流體系的建立、購物介面與流程的改善等等這些相當貼近電子商務實務面向的因素。
在我看來，這些層面固然重要，解決這些問題或許能讓網路成為「很受歡迎」的購物方式，但是卻還不足以使線上購物取代實體通路，晉身成為普羅大眾最主要的商品消費模式。原因在於，電子商務雖然有許多的優勢可以提供我們眾多「小利」、「小惠」，像是價格低一點點、資訊多一點點，但是我們別忘了，實體世界的交易模式也是持續不斷在改善經營效率、提升服務品質當中，光是小利和小惠，尚不足以讓所有的人一心轉向電子商務的懷抱。
過去大家想都沒想過的「石油因素」對於電子商務的影響，可能高過我們多數人的預期與想像。
汽油價格漲很多，坐在家裡等商品寄過來和自己開車出門去買的差距便會加大，這道理和油價上漲時使用大眾交通工具的人就會增加是一樣的。宅配到家的服務並不是不用成本，但是等於是「最後一哩」的成本也由消費者共同負擔。相對地，開車出門所耗費的油錢，其實也應該附加在購物的成本上，只是過去我們可能「沒感覺」，但是現在要渾然不覺則是越來越困難。
「跑單幫」、「出國代購」這種傳統的經營模式，將很快會被跨國電子商務所取代。過去，到日本、香港這些臺灣人的海外購物重鎮的機票只在數千元之譜，中間人代買幾樣高單價的貨品就可能具備獲利的空間。反觀現在除了機票持續看漲，航空公司對行李限重的規定也越來越嚴格，有些航空公司甚至連旅客的第一件行李也要收費，代買業者的獲利空間已被高度壓縮。
油價漲，勢必要帶動水、電、裝潢、人工、店租等等的成本跟著上漲，而這些也都將拉大傳統交易模式和電子商務間的價格距離。
過去傳統實體商務透過物流運籌體系的建立、擴大連鎖店規模以提高對上游的議價能力等等的方法，來降低營運成本的技術，但對於石油、原物料價格上漲的根本問題，卻是毫無招架之力。
過去單價過低的貨品在網路上不容易賣，因為郵寄成本會讓低單價的商品變得不便宜，但是如果油價持續上漲到200美元、500美元，只要不出門就能入手的東西，我們可能都會覺得很便宜。
過去我們判斷電子商務的發展能否起飛的主要關鍵，在於能否有效地降低電子交易的交易成本，交易成本的下降幅度必須夠顯著，才能夠吸引消費者改變他們的消費習慣，移轉陣地到虛擬的交易世界裡來。出乎所有人意外的，實體交易市場的交易成本攀升，對比之下讓虛擬世界的交易成本即使原地不動也顯得低廉許多，這種現象非常有可能成為未來電子商務躍居主流地位的重要推力。
不久的將來，我們可能面對的是網購宅男、宅女逐年倍數增加的時代，而這樣的時代，將會是電子商務的大時代。
作者簡介：
王盈勛─iThome電腦報總主筆
曾在科技財經雜誌任職，擔任過鄉下第四臺的節目部經理，現為淡江大學資訊傳播系助理教授，擁有政治大學科技管理博士、英國Brunel大學傳播與科技碩士學位，著作包括《世界是斜的》、《微軟生存之戰》及《白話數位經濟》等書。
2008年6月8日 星期日
Webservice - Electronic Business
電子商務時代
Security - DDoS
舒緩DDoS攻擊的方式
Security - Digital Rights
MySpace新技術 避免版權糾紛
Security - Game
通訊安全鎖
Software Engineering
XP (eXtreme Programming，極限編程)
電子商務時代
Security - DDoS
舒緩DDoS攻擊的方式
Security - Digital Rights
MySpace新技術 避免版權糾紛
Security - Game
通訊安全鎖
Software Engineering
XP (eXtreme Programming，極限編程)
XP（eXtreme Programming，極限編程）
師徒制開發模式，迅速提升菜鳥能力
文/李延華 (記者) 2008-06-06
近年來，XP方法論在軟體工程上受到矚目，力可科技資深軟體架構師陳彥任認為最難落實的是搭檔編程與測試先行，但效益也最大，企業若想嘗試可以先從小專案開始。
你對XP（eXtreme Programming，極限編程）的認識有多少呢？許多程式人對於XP的認知仍處於理論階段，而在臺灣有勇氣落實的開發團隊更是不多見。
目前任職於力可科技的資深軟體架構師陳彥任，因為曾在中研院參與過以XP開發的專案，在學術單位注重方法論的薰陶下，成為XP與TDD（Test Driven Development，測試驅動開發）的擁護者。
之所以堅持軟體品質的理念，陳彥任表示是因為對程式開發有興趣，朋友都說他是一名技客（Geek），他強調：「如果在國外，我會寫程式到60歲。」
使用者在隔壁，簡單搞定客戶駐廠的要求
中研院生醫所在陳彥任加入之前，是採用RUP（Rational Unified Process）方法論，產出了大量的文件，但效益不彰，於是決定轉向嘗試XP。
落實XP方法論，包括客戶駐廠、系統隱喻、通盤規畫、小階段發行、簡單設計、測試先行、編程標準化、重構、搭檔編程、共同維護、持續整合及每周40工時等12個方法。
雖然不需要同時落實12個方法才算XP，不過陳彥任回顧中研院生醫所的專案，除了共同維護之外，其他方法幾乎都有不同程度的實踐。
他們的「客戶」，是近在隔壁的基因體鑑定中心，因此XP的12項方法中最難突破的「用戶駐廠」，在一開始就搞定。
陳彥任回憶：「第一階段畫面雛形完成後，請使用者來看時，意見可多了。」在使用者回饋的過程中，會發現雙方的認知，很多時候是完全不一樣的。客戶駐廠的用意就是傾聽使用者的聲音，才有機會及早修正。
談到系統隱喻，陳彥任認為最重要的就是要跟使用者建立共同語言。以他們的案例來看，雖然主管在面試時，特意挑選了一位有生物背景的開發者加入團隊，但對多數成員而言，面對生物領域仍然有許多挑戰。因為基因鑑定不但有一大堆專業術語，而且同一種東西、同一件事情，可能出現好幾種表達方式。於是必須持續要求使用者統一用語。
搭檔編程造成箝制效果，開發效率高
陳彥任認為XP的方法中，最不容易實踐的是「搭檔編程（Pair Programming）」和「測試先行（Code The Unit Test First）」。
許多人對搭檔編程有誤解，認為兩個人寫一隻程式，產能降一半。
陳彥任以自身的經驗分析，認為情況剛好相反，兩個人一起工作會造成相互制衡的效果，他和搭檔一起工作時，不曾傳送MSN或回覆郵件，工作效率反而高。
陳彥任解釋合作開發的兩人，坐在後面指揮的一方叫做領航者（Navigator），而在鍵盤前打字的則稱為操作者（Operator）；操作者只是負責輸入語法，而領航者則是看程式上中下三層的大方向，工作的過程中，兩者互相搭配。
在兩人合作的開發模式下，陳彥任表示：「常常坐下來就持續專注討論和寫程式，直到一個階段完成，才發現3個小時過去了。」
共同維護類似共產主義，將剝奪成就感
在XP中另一個與搭檔編程有關的方法是「共同維護」，強調頻繁地替換搭檔（Switch Pair），然而這也是中研院唯一沒有落實的方法。
陳彥任解釋，根據XP的定義，搭檔開發的功能要在1～2天之內完成，之後成員就替換，所以如果功能必須兩天以上才能完成，就要切得更細。
如此一來，開發者每次只處理系統的一小塊，而持續替換的結果，使得每個人都清楚整套系統的設計與機制，也就達到共同維護的目的。然而衍生的缺點，是開發者像是生產線上的工人。
程式開發有一部分動機是追求成就感，如果工作一直換的話，就類似共產主義，使得開發者無法擁有任何東西。
陳彥任舉例：「共同維護就是以切碎系統，剝奪成就感，如同要求雕刻家只負責刻眼睛，無法獨立完成一個藝術品。」所以，他們的作法是以6個人為一個單位，兩兩為一組，只在整個模組做完之後，才來一次大風吹重新編組。
身兼傳教士，推廣TDD的好處
針對測試先行這一項要求，陳彥任坦承：「一開始要用逼的！」而中研院的作法是由「重度」TDD的信仰者陳彥任擔任「傳教士」，負責宣導測試的重要與好處，並教所有成員如何寫單元測試（Unit Test）。
正規的「測試先行」是先寫測試程式，再寫程式，但對於多數開發者而言，在沒有寫程式之前，先寫測試是難以想像的事情。
這方面陳彥任的作法，是比較好想像的計算類功能，就先寫測試；但網頁和介面互動的部分，未實作前的確難以想像，就採後寫的方式。
中研院要求測試的覆蓋率要到90%以上，陳彥任表示：「如果測試程式要達到高覆蓋率，就要想辦法移除測試的門檻。」把難寫測試的部分變簡單，開發成員才會寫得下去，例如使用者介面很難測試，於是他就設計一個機制把它封裝起來，工程師只需要開發簡單的API就能完成測試，寫測試的意願便提高。
上了測試的癮，從此有測才安心
當然，未必所有的人都能接受XP的作法，陳彥任在推廣的過程，也有遇過不寫測試程式的工程師，因為抗拒自然就離職了；也會有人無法接受搭檔編程，而待不下去。同樣的，也有開發者聽說這個團隊採用XP而來應徵，理念相同便會留下來一起工作。
現在若是沒有寫測試程式，陳彥任的心裡會毛毛的，他說：「這種症狀稱之為『上癮』，染上測試的『毒』」。所以如果去一家不寫測試的公司，陳彥任會希望擔任傳教士，如果推廣失敗，結果同樣也是待不住。文⊙李延華
實施搭檔編程後，人的問題變多，而系統的問題變少
相較於TDD的明顯效益，多數人對於搭檔編程的疑慮比較大，陳彥任不諱言：「主管需要處理的『人』的問題會增加，到後來其實是在修心。」
陳彥任以自身為例，他本身很講究程式的寫法，而搭檔卻不以為意，雙方便起了爭執。最後由主管出面協調，後續的合作，雙方的態度都有所妥協。
搭檔編程的訴求：避免死角
他認為如果主管重視以下好處，就會願意付出搭檔的成本：
1. 教育訓練：如果有新進人員，透過老手的從旁指導可以很快上手。
2. 品質：每個人的想法都可能存在盲點，而兩人合作時，可以互相「Cover」對方的盲點。
3. 善用時間：只要一開始寫程式，幾乎就停不下來，中研院實施一段時間後，主管甚至需要規定時間「下課」。
搭檔的技巧：一強配一弱效果最好
搭檔編程需要留心的技巧是：搭檔怎麼配很重要。兩個能力強的配在一起的情況比較少，因為會浪費人力。大部分的情況是一強配一弱，可以提升素質到平均水準。若是兩個菜鳥的組合，一定是不重要的功能，可視為練習的機會。文⊙李延華
IT人物─陳彥任
力可科技資深軟體架構師
●學經歷：東海大學化工系研究所畢業，曾任中德電子工程師，之後轉往中央研究院生醫所，擔任IT部門高級工程師，主導技術架構及開發流程，協助建立基因體鑑定中心服務平臺，並完成臺灣生物資料庫。
公司檔案─力可科技
www.liquable.com
●成立時間：2007年
●營業項目：多人連線型Flash遊戲開發平臺
文/李延華 (記者) 2008-06-06
近年來，XP方法論在軟體工程上受到矚目，力可科技資深軟體架構師陳彥任認為最難落實的是搭檔編程與測試先行，但效益也最大，企業若想嘗試可以先從小專案開始。
你對XP（eXtreme Programming，極限編程）的認識有多少呢？許多程式人對於XP的認知仍處於理論階段，而在臺灣有勇氣落實的開發團隊更是不多見。
目前任職於力可科技的資深軟體架構師陳彥任，因為曾在中研院參與過以XP開發的專案，在學術單位注重方法論的薰陶下，成為XP與TDD（Test Driven Development，測試驅動開發）的擁護者。
之所以堅持軟體品質的理念，陳彥任表示是因為對程式開發有興趣，朋友都說他是一名技客（Geek），他強調：「如果在國外，我會寫程式到60歲。」
使用者在隔壁，簡單搞定客戶駐廠的要求
中研院生醫所在陳彥任加入之前，是採用RUP（Rational Unified Process）方法論，產出了大量的文件，但效益不彰，於是決定轉向嘗試XP。
落實XP方法論，包括客戶駐廠、系統隱喻、通盤規畫、小階段發行、簡單設計、測試先行、編程標準化、重構、搭檔編程、共同維護、持續整合及每周40工時等12個方法。
雖然不需要同時落實12個方法才算XP，不過陳彥任回顧中研院生醫所的專案，除了共同維護之外，其他方法幾乎都有不同程度的實踐。
他們的「客戶」，是近在隔壁的基因體鑑定中心，因此XP的12項方法中最難突破的「用戶駐廠」，在一開始就搞定。
陳彥任回憶：「第一階段畫面雛形完成後，請使用者來看時，意見可多了。」在使用者回饋的過程中，會發現雙方的認知，很多時候是完全不一樣的。客戶駐廠的用意就是傾聽使用者的聲音，才有機會及早修正。
談到系統隱喻，陳彥任認為最重要的就是要跟使用者建立共同語言。以他們的案例來看，雖然主管在面試時，特意挑選了一位有生物背景的開發者加入團隊，但對多數成員而言，面對生物領域仍然有許多挑戰。因為基因鑑定不但有一大堆專業術語，而且同一種東西、同一件事情，可能出現好幾種表達方式。於是必須持續要求使用者統一用語。
搭檔編程造成箝制效果，開發效率高
陳彥任認為XP的方法中，最不容易實踐的是「搭檔編程（Pair Programming）」和「測試先行（Code The Unit Test First）」。
許多人對搭檔編程有誤解，認為兩個人寫一隻程式，產能降一半。
陳彥任以自身的經驗分析，認為情況剛好相反，兩個人一起工作會造成相互制衡的效果，他和搭檔一起工作時，不曾傳送MSN或回覆郵件，工作效率反而高。
陳彥任解釋合作開發的兩人，坐在後面指揮的一方叫做領航者（Navigator），而在鍵盤前打字的則稱為操作者（Operator）；操作者只是負責輸入語法，而領航者則是看程式上中下三層的大方向，工作的過程中，兩者互相搭配。
在兩人合作的開發模式下，陳彥任表示：「常常坐下來就持續專注討論和寫程式，直到一個階段完成，才發現3個小時過去了。」
共同維護類似共產主義，將剝奪成就感
在XP中另一個與搭檔編程有關的方法是「共同維護」，強調頻繁地替換搭檔（Switch Pair），然而這也是中研院唯一沒有落實的方法。
陳彥任解釋，根據XP的定義，搭檔開發的功能要在1～2天之內完成，之後成員就替換，所以如果功能必須兩天以上才能完成，就要切得更細。
如此一來，開發者每次只處理系統的一小塊，而持續替換的結果，使得每個人都清楚整套系統的設計與機制，也就達到共同維護的目的。然而衍生的缺點，是開發者像是生產線上的工人。
程式開發有一部分動機是追求成就感，如果工作一直換的話，就類似共產主義，使得開發者無法擁有任何東西。
陳彥任舉例：「共同維護就是以切碎系統，剝奪成就感，如同要求雕刻家只負責刻眼睛，無法獨立完成一個藝術品。」所以，他們的作法是以6個人為一個單位，兩兩為一組，只在整個模組做完之後，才來一次大風吹重新編組。
身兼傳教士，推廣TDD的好處
針對測試先行這一項要求，陳彥任坦承：「一開始要用逼的！」而中研院的作法是由「重度」TDD的信仰者陳彥任擔任「傳教士」，負責宣導測試的重要與好處，並教所有成員如何寫單元測試（Unit Test）。
正規的「測試先行」是先寫測試程式，再寫程式，但對於多數開發者而言，在沒有寫程式之前，先寫測試是難以想像的事情。
這方面陳彥任的作法，是比較好想像的計算類功能，就先寫測試；但網頁和介面互動的部分，未實作前的確難以想像，就採後寫的方式。
中研院要求測試的覆蓋率要到90%以上，陳彥任表示：「如果測試程式要達到高覆蓋率，就要想辦法移除測試的門檻。」把難寫測試的部分變簡單，開發成員才會寫得下去，例如使用者介面很難測試，於是他就設計一個機制把它封裝起來，工程師只需要開發簡單的API就能完成測試，寫測試的意願便提高。
上了測試的癮，從此有測才安心
當然，未必所有的人都能接受XP的作法，陳彥任在推廣的過程，也有遇過不寫測試程式的工程師，因為抗拒自然就離職了；也會有人無法接受搭檔編程，而待不下去。同樣的，也有開發者聽說這個團隊採用XP而來應徵，理念相同便會留下來一起工作。
現在若是沒有寫測試程式，陳彥任的心裡會毛毛的，他說：「這種症狀稱之為『上癮』，染上測試的『毒』」。所以如果去一家不寫測試的公司，陳彥任會希望擔任傳教士，如果推廣失敗，結果同樣也是待不住。文⊙李延華
實施搭檔編程後，人的問題變多，而系統的問題變少
相較於TDD的明顯效益，多數人對於搭檔編程的疑慮比較大，陳彥任不諱言：「主管需要處理的『人』的問題會增加，到後來其實是在修心。」
陳彥任以自身為例，他本身很講究程式的寫法，而搭檔卻不以為意，雙方便起了爭執。最後由主管出面協調，後續的合作，雙方的態度都有所妥協。
搭檔編程的訴求：避免死角
他認為如果主管重視以下好處，就會願意付出搭檔的成本：
1. 教育訓練：如果有新進人員，透過老手的從旁指導可以很快上手。
2. 品質：每個人的想法都可能存在盲點，而兩人合作時，可以互相「Cover」對方的盲點。
3. 善用時間：只要一開始寫程式，幾乎就停不下來，中研院實施一段時間後，主管甚至需要規定時間「下課」。
搭檔的技巧：一強配一弱效果最好
搭檔編程需要留心的技巧是：搭檔怎麼配很重要。兩個能力強的配在一起的情況比較少，因為會浪費人力。大部分的情況是一強配一弱，可以提升素質到平均水準。若是兩個菜鳥的組合，一定是不重要的功能，可視為練習的機會。文⊙李延華
IT人物─陳彥任
力可科技資深軟體架構師
●學經歷：東海大學化工系研究所畢業，曾任中德電子工程師，之後轉往中央研究院生醫所，擔任IT部門高級工程師，主導技術架構及開發流程，協助建立基因體鑑定中心服務平臺，並完成臺灣生物資料庫。
公司檔案─力可科技
www.liquable.com
●成立時間：2007年
●營業項目：多人連線型Flash遊戲開發平臺
訂閱：
文章 (Atom)