軟體開發真的沒有銀彈嗎？淺談世界級軟體開源社群運作

圖片來源：One Piece

無人不知的軟體神書人月神話：軟體專案管理之道(The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition)其中一個章節提到人月神話這個迷思，簡單解釋，以工程學來說，今天我用50個人建一間房子需要100天，那工程上因為可以拆解工作，所以理論值(大量的平均數來看)可以用500個人在10天內建一間房子；這就是一種人月工時結構的估算。

很可惜，軟體並不是工程。軟體開發是一個很殘酷用智商高低決定勝負的領域，以開著同一款車，一個頂尖的賽車手頂多就比普通會開車的人快個2-3倍，但軟體頂尖程序員跟普通程序員可以差到百倍(the measure indicators should be include quality, scalability and stability)。

但今天透過網路無遠弗界的集結，開始有著一絲可以打破人月神話的運作機制存在，這個機制就是開發者社群(Community)。一個好的開放原始碼社群透過制度、標準、流程、規範有效集結世界各地志同道合的夥伴。以OpenStack開源社群為參考說明。

開源社群運作基礎流程：

1. 先有個code base，最小可能就只有幾千、幾萬行程式碼，然後由一個或兩個單位維護研發，eg：NASA, Rackspace。
2. source被open，並且License Agreement被擴張為Apache License，簡單的說就是拿到這個授權的程式碼，你可以無償的使用他，拿來改、賣都沒關係，隨便你搞，但前提是組織不負後續責任。通常這時候就會開始吸引到市場的鯊魚。
3. 忘了說，一定要有個源碼版控系統。
4. 社群建立，會開始進行幾件事情：
• 建置官方網站，繪製個吉祥物mascot感覺比較沒這麼枯燥乏味。
• 釋放Release Note(說明這個版本主要完成哪些功能)、發佈各種進程的版本(alpha, beta, candidate, stable, )、發布版本、定出版號、
• 針對社群貢獻者(contributors)會給幾條較有法律性的規範CLA(Contributors License Agreement)

2014末 - 自我技術成長的省思

最近悠悠轉轉某開源社群一段時間，鑽研其中一個主題，過程大概就是系統安裝、trace code、把架構搞清楚、拉哩拉雜用了一堆元件、再把python又複習了一下，腦袋中累積了不少東西，想把東西寫出來做個分享，表示自己好像獲得一項成就(?)，結果寫到一半，突然發現...

我現在不過是把社群上的英文文件翻成中文而已啊...

我現在不過是把社群上的英文文件翻成中文而已啊...

我現在不過是把社群上的英文文件翻成中文而已啊...

嚴重發現自己沒有貢獻(哪有人自己當穿新衣的國王，還同時扮演那個指著國王說沒有穿新衣的那個小孩)，不過就這樣一個move就得到一個反省思考的機會。

台灣的軟體實力長久以來，跟硬體、晶圓代工廠那些還可以跟世界搶單一較高下的技術來比，根本就是一塊如同殘障的領域。沒辦法，台灣一個小島才多少人，最強的都跑去當醫生、律師，再來是電機，然後才...好了，這種涉及到人身攻擊的議題到此為止。

關於軟體開源社群，在台灣能有"實質貢獻"的機會並不多；觀察幾年下來，台灣軟體產業界的毛病仍舊停滯不前。

1. 拿了國外寫好的開源專案，稍微改個UI、換個LOGO就說是新技術；這點其實很tricky，到底是拿既有開源專案去忽悠上面說開發了新技術，然後上面決策層級(擁有資源)的人很開心，就開始大肆做宣揚、媒體推廣的人但不去思考這到底算不算是一個真正能讓產業升級的關鍵技術。兩邊還真不知道誰對誰錯，也許這是一個共犯結構、上下交相賊，下面想辦法透過最短途徑讓長官開心，長官也有了新的題材讓大長官更開心，你開心、我開心、大家開心，開心之餘又有錢領何樂而不為，反正題材願景的泡泡只要不戳破就沒問題。
2. 不斷的做Me2

[OpenStack]如何修改OpenStack Horizon(Web UI)主題風格

本來這件事情，是不想當作一篇文章發佈，但在經過一個週末的休憩後，週一上班的時候就發現上周五的記憶就這樣蕩然無存...存在感跟螞蝗開出的633政見差不多低，所以趕快記一下...

如何修改OpenStack Horizon(Web UI)主題風格：

• OpenStack版本：Juno
• Vendor：Ubuntu
• 修改以下兩個檔案：
• Reference directory & file：/etc/openstack-dashboard/ubuntu_theme.py
• TEMPLATE_DIRS = ('/usr/share/openstack-dashboard-ubuntu-theme/templates', )

以上簡記

神註解 - 思考 Code Review 的重要性

無意間翻到一個放著發霉的js檔，傳說中是一間世界知名的硬體品牌廠對外網站產物，分享一下神註解(網路一夕爆紅，然後馬上就被撤)。

不要再跟我說code review不重要，你沒有時間做code review~

IDE混搭風 - 整合UltraEdit在Windows環境開發Linux系統

這是一個混搭的概念，適合用於一種特殊公司環境(絕大多數99.9%的幾萬名同事都活在Win系列)，而你自己也無法脫離(脫離了連收個信都很困難)的艱困環境下產生的IDE跨界混搭整合。

說明：

• 個人作業系統：Windows系列
• IDE：UltraEdit
• 程式語言：Python
• 研發運行環境：Linux系列
• Terminal：Putty
• 虛擬軟體：VirtualBox

配置：

• 開啟UltraEdit，點選檔案 -> 檔案檢視 -> FTP設定
• 設定要被遠端ssh連線的Ubuntu(執行在VirtualBox上)，輸入IP、帳號、密碼、預設登入目錄(defult是登入帳號的家目錄，但這樣不方便，因為你要開啟的目錄往往在其他地方)

研發主管職秘辛

圖片來源：http://s1.djyimg.com/

一些心得分享。

所謂團隊：自主運作、團隊產出與人力(數)成正比、隨時可以增添或拆解人力。
現在的團隊已經處於一個穩定狀態，透過兩週固定一次的例行會議，或是臨時性任務的E-Mail電子郵件交代，設定好人員、目標、時間，成員就能自行準時完成並且回報進度，以公司經營來說有點算是達成人力與目標的break even。雖說團隊規模還不大，但依照這樣的模式要擴大、因應新任務承接根本不成問題，並且依照人力的增補可以獲得相對應的工作產出，才是真正的團隊！這時候我就不需要注意細節部分的領導，可以把時間分配並專注於新領域的技術、市場導向研發。

個人領導原則：
個人其實在接下職務以前，早就對自己有所目標設定，兢兢業業不忘自己的領導原則。

自主型的團隊運作：
由於團隊是全新成立，為了讓大家及早進入狀況，採用敏捷式開發、每日站立會議方式提高成員間的溝通互動、大家對產品技術熟悉度。個人覺得強迫性導入敏捷的精神：時常溝通、不斷檢視是團隊現在能自主運作的最大成功因素，大家在需要的時候就迅速集合、快速討論、立刻下決定的處理方式，個人引以為傲。

除了滿足上級需求，更要培養菁英團隊：
一個主管的成功，如果只成功自己，個人不覺得是個成功領導。成功領導應是團隊性。怎麼培養真的是門藝術，要讓底下的人成長，成長到足以取代自己的位置，這樣自己才有基礎往更高的階梯上爬。
    至於如何滿足上級需求，這又是另一門學問了，簡單的說就是要用老闆的角度來思考事情，這裡不多述。

如何幫團隊擬定執行策略：
個人覺得這是件相當困難的事情，莫非定律表示：事情永遠在你很忙的時候，會冒出更多事情，所以幫團隊擬定最好的執行策略是當一個主管或領導最重要的任務：

1. 先找出最適合的人來負責事情，但要記得賦予權責：這裡講的是最適合，而非最好，大家都知道每個人專長都不一樣，有些人適合處理人際關係、有些人研發能力很強但可能文筆不是很好、有些人統御能力很強、有些人測試規劃很強，這些都是需要長期觀察並且試著去交辦任務才能發現，絕對不是把所有的事情往最強最厲害的人身上丟就沒事，那要你這個主管幹嘛？在強在厲害的人一天跟其他人一樣都只有24小時，主管要做的事就是去找出最適合的人選。找出人選後，要懂得授權，負責人有權利去調度人力或安排資源，不能讓他覺得綁手綁腳，最好也不要給其太多限制(除非觀念有所偏差，但這樣就不應該是你挑出來的人選)，讓成員有機會成長。
2. 給訂明確的目標

當Mac OS遇上VMware Workstation

謎之聲："個人喜歡Apple Inc.，也有iPhone、Mac Air...這篇純粹是秉著程序員求新的態度孕育而生~"

Apple Inc.在WWDC 2014橫空出世發表了新的programming language: Swift，以下是Apple自己給Swift的簡介：Swift is Apple's brand-new programming language for writing great iOS and OS X apps. Learn the basics of the language. See how to declare variables, use the fundamental data types, declare functions, and implement classes. Explore some of the great features that make Swift a safe, modern, and extremely powerful language. 簡單來說，Apple要將為人詬病已久不易上手的Object-C換到新語言Swift上，其支援近年流行的Lambda語法、Script隨寫隨編隨跑等特性，直教人想趕快玩一玩；但要用Swift可真是讓小弟費煞了一番苦心，沒有Mac怎麼辦？沒關係，Virtualization的第一名VMware真的很厲害~以下介紹如何在Windows上用VMware Workstation安裝Mac OS

個人測試環境需求：

1. VMware Workstaion 10 (以上)，才能支援最新版的Mac OS
2. VMware unlock tool (v120 以上)，得以解鎖Workstaion原本對Mac系列OS的屏蔽
3. Mac OS X Mountain Lion 10.8.3.iso or Mac OS X Mountain Lion 10.8.3.dmg
4. xcode6 beta.dmg

[VMWare Workstaion安裝Mac OS X步驟]

[OpenStack]使用DevStack快速部署OpenStack

OpenStack是一套雲計算 IaaS 的管理平台開源專案，相關的敘述不再多說，請自行上Google搜尋。鑑於陸陸續續聽到不少聲音說OpenStack相當難於建置部署，但發展至今，其實網路上的鄉民高手們已經提供很多強大的一鍵式安裝包，以下要介紹的是利用DevStack快速建置OpenStack。

個人部署環境說明：

• 虛擬化平台：VMware WorkStation 8 (免費的VirtualBox大家也相當推薦)
• OS：CentOS 6.5 64bits Eng.
• devstack Github：git clone git://github.com/openstack-dev/devstack.git
• 用VMware把CentOS 6.5裝起來，網路記得要打通，個人是用VM的虛擬網卡eth0 採bridge方式至手機的3G，在Virtual Network Editor選項可以對網路設定做修改
• 需要的指令，以藍字標註。

安裝步驟如下：

[建立OpenStack原始碼的下載目錄]

• 這裡先放在/tmp底下，請自行選擇
• $mkdir /tmp/devstack

[從Github拉最新的OpenStack原始碼]

• $cd /tmp/devstack
• $git clone https://github.com/openstack-dev/devstack.git

你在做，主管怎麼看

暨寫完軟體主管的喃喃自語：領導原則，這是給自己看的，藉以提醒自己不要走失了方向。領導團隊一陣子了，看到了一些現象，也有些心得與感想。

主管要幫你沒錯，但不是你的管家：
    每間公司都有既定的體制與規則，當然部門與部門之間也享有或是管理不同資源的責任，舉例來說，今天你的團隊明天要出外景，然後你發現自己沒有攝影機，臨時採購當然來不急，這時候就要去跟別的部門商借，這時候可能就要動到主管去跟其他部門交涉攝影機的使用資源(只是舉例)。但接下來的工作，包含借攝影機可能需要填什麼表單、是不是還要借電源線、是不是需要借鏡頭、機器的使用方法等等，就應該你要自己處理了，而不是還要主管幫你換這些工作層級的尿布。
    也許你會問，那到底什麼時候可以請主管來幫我？很簡單，就是這件事情你自己喬不動的時候，需要有權力的人來推一下。除此之外，個人建議盡量就別動用到主管，畢竟主管真的很忙。
    怎麼說忙，你又會問，我看主管都沒在做事情阿？有帶過團隊的人應該都能體會，當成員有問題來找你，假設光是一個對話(成員說明、內容對話、情境了解、給定決策)需要10分鐘就好，然後你每次打斷主管思緒後要讓他在回到原有思緒，總共算15分鐘好了，假設你的團隊有10個成員，大家每天都來問一件事情就好，主管就要花兩個半小時跟團隊周旋... ...這樣的算法還沒算到跟主管的主管、還有別的團隊的主管周旋。

工作分配下去，團隊都有定期開會，我還需不需要另外回報進度？

OSGi簡易實作於Eclipse

某些因緣際會，最近稍微研究一下OSGi Framework，但對於這個技術，網路上較多的都是一些框架概念，實作分享不多，就連Eclipse本身直接拿內建的Plug-in建立專案也沒辦法跑(奇怪...Eclipse不是基於OSGi去開發的嗎?) 以下是個人簡易實作分享。

什麼是OSGi：
網路上很多介紹，這裡僅做簡介：OSGi是一個Framework(框架)、是一個概念，框架往往就是好幾個Design pattern構成，用來幫助開發者統一建構系統的標準架構；面臨一個大型系統建置，絕對不會把所有程式碼都放在同一個Project(專案)，因為這樣不好維護、分包撰寫，所以OSGi提供一個切割子Project的方法，每一個子專案在OSGi之上視為一個Bundle，每個Bundle可以擁有自我獨立的生命週期，如果撇開Dependency(相依性)不管，每個Bundle可以自由地透過OSGi統一的Command line進行管理(啟動/關閉/重啟...等等)，而不影響其他Bundle的運作。
    換句話說，假設，假設今天你開了一台基於OSGi框架製造出來的車子上路，你開到路上車子還在跑，但是你卻突然發現路旁有家新開的輪胎行，德國H牌輪胎之類的，看起來很厲害，然後你臨時想換個輪胎但又不想停下來，只要今天你的輪子也是基於OSGi製造，轉動輪子的軸承也是，那你就可以在車子還在跑的情況之下把輪胎換成心愛的H牌輪胎(什麼爛比喻?!)

先來提提Eclipse內建的OSGi專案：(這個實作並沒有完全成功，網路上找到的bug shooting也沒什麼用)

1. 下載並安裝Eclipse，https://www.eclipse.org/downloads/
2. 建立workspace，點選File -> New -> Other -> Plug-in Project
3. 進入對話框Plug-in Project，記得把下面的Target Plateform換成an OSGi framework，點選Next
4. 進入對話框Content，Execution Environment不要動，記得還是選JavaSE即可，不要換成OSGi/Minimum，否則等專案跑起來會沒有osgi.jar檔，然後Next
5. 進入對話框Templates，點選Hello OSGi Bundle，然後Finish. 專案應該就建立完成了。(Eclipse好棒啊)
6. 執行專案，沒有問題可以執行，Console很開心的跟你說Hello World! 
7. 悲劇來了，接著馬上噴出一堆錯誤訊息...一句話，別花時間去解了，聽說是專案自己initial其他沒用的jar，然後那一拖拉庫的jar也不知道要關掉哪些才有用，因為關了一些，又噴出其他的錯誤訊息...

那我們該怎麼辦

大陸河北談生意

那是我第一次到達河北，中國河北省石家庄火車站。

先來講講中國的城鄉差距好了。中國大陸，有五個一線城市，分別是北京、上海、廣州、深圳，其他二線如南京、武漢、天津、河北，然後更鄉下的就不用講了，在古代來說，那就是所謂的荒郊野嶺。那身為一個二線城市的河北省省會石家庄又如何呢？

大陸北方的沙塵暴一點也不意外的侵襲到距離北京西南300公里的石家庄，不打緊，出車站時早就有心理準備，沒有心理準備的是車站的公共廁所。你妹阿！只有四個字可以形容："屎尿橫飛"，沒錯！廁所裡有小便斗，問題是，大便的地方沒有門...沒有門就算了，他是直接大到木桶裡面，沒錯！是木桶！然後滿地、牆上全都是屎尿，進廁所需要憋氣、躡手躡腳找著可以踩下去的地板走...這是我對河北省的首都、市中心石家庄的第一個印象：屎跟尿。

離題了，今天是要來講講我們去拜訪河北客戶的故事。故事大概發生在2011年。

不嘴砲！敏捷式(Agile)開發玩真的

敏捷式開發的流程圖大致上會長成這樣，很簡單，但問題是該如何執行?

繼日前介紹的每日站立會議執行心得，時光飛逝，一晃眼2014來了，中國新年也要到了(請不要問版主今年貴庚...)，也是再給個交代的時候了。

實際執行過的軟工方法 What we did ?

• 每日站立會議 Daily Standing Meeting
• WBS(Work Breakdown Structure)
• 持續性整合 Continuous Integration(CI)
• 自動化測試 Auto Testing
• 視覺化工作進程追蹤 Kanban
• 使用議題追蹤系統 Using issue tracking system with Microsoft Team Foundation Server(TFS)

敏捷式(Agile)開發到底是什麼鬼 What the hell is AGILE ?

以下完全是個人對敏捷式開發下的定義，不代表任何一個出處。

• 敏捷式開發不是軟工方法，敏捷只是一種心理狀態的描述、一種工作環境的意念，如果公司文化沒有敏捷的意圖或是想法存在，導入任何方法都沒有用。但軟體開發總是需要方法來協助執行，下一節會針對上述個人所使用過的軟體工程方法來成果分析。
• 敏捷注重的是大量的重複迭代(Iterator)，簡單的說，就是你的任何工作不要做完了才拿出來，千萬不要做完了才拿出來，而是時間到了就要拿出來檢視、拿出來討論、拿出來DEMO。老師在講你有沒有在聽？老師在講有沒有在聽？這可不是跳針，是強調！
• 所以敏捷團隊執行狀態比較會像是：在專案開發初期，所有成員一起制定目標，這個系統要呈現使用者什麼樣的功能、什麼樣的感覺，不一定要馬上有既定的結論，但必須把工作項目(backlog)內容及時程制定下來，然後由成員各自認養。
• 不是認養回去就算了，還得繼續把目標切割(item)透過不斷的執行、驗證、根據驗證後的感覺進行討論然後修改、再執行，這樣每次的執行、驗證、再修改、再執行就是一個 iteration。老實說這種思維很難跟沒有執行過的人、不夠經驗的開發者、長官等等解釋，沒有實際執行過真的永遠只會理解教條上那套。

那這樣一直反覆迭代，難道你心中沒有一個疑問？事情一直重複做、重複修改，哪來這樣的美國時間？這樣真的有敏捷到嗎？恭喜你，你開始要有點懂敏捷式開發了。

軟體主管的喃喃自語：領導原則

圖片來源：www.nipic.com

大方向：

不是很喜歡主管這個詞彙，主管感覺只是在管人、管事，但其實在管理階層要做的事情不能只是管理，要能找出團隊未來的方向，雖然對台灣人來說會很反感，個人倒是覺得用"領導"才是比較洽當的詞彙。


領導(主管)認知：(個人立場)

1. 謀定而後定，避免朝令夕改：要認知主管的一舉一動、下達指令都是成員們的圭臬，要是今天主管請你研發A，後天跟你說改成研發B，再過幾天又跟你說要研發C，想必大家都會無所適從，專案進度永遠都在歸零。所以個人在下每個命令或指導棋之前，絕對不會脫口而出，都是在腦海中沙盤推演這個命令下去後會讓多少人投入資源，投入資源後會獲得哪些產出，再藉由這些產出能不能達到目的才會下這道決策。要知道主管的話語對下屬來說就是指南針，今天你自己都抓不準方向，又要如何讓事情獲得成功？
2. 必須有扛責任的覺悟：團隊成敗與否絕對是在主管身上，別想怪罪到下屬上；要是主管老是以"員工不認真"、"員工能力不足"來搪塞失敗，那上級長官又何必賦與你主管職，一個主管存在價值就是在於領導團隊的成功。
3. 不是只為上司負責，更要為成員的未來負責：設想一個情形 - "如果今天你所在這間公司突然倒閉了，你的成員都有辦法、有能力找到別的工作嗎？"主管的任務不僅是要完成上面長官交代的事情，同時間你應該要為下屬的能力培養盡到責任(除非你的下屬就是沒有心思學習，另當別論)，今天你交辦給他的任務應該是要有技能性、學習可能、有競爭力的。