Who am I ?

Denny Huang

• 雷亞遊戲 Rayark Inc.

• SITCON 2013, 2014 總召

• About me

開發經驗

• Python, Java...

• Shell Script

• Android

• 系統 / 網路 / 後端

緣起

HackGen Workshop -
歡迎來到 GitHub 新手村

銘傳大學 資管所
Oases Ong

Open Source Software 發展程序模型建構

特別感謝

Oases Ong

本簡報題目來自於 Oases Ong 論文訪談問卷

軟體工程？

系統性
規範化
可定量的程序化方法

• Request and Analysis Phase（需求與分析階段）

• Design Phase（設計階段）

• Coding Phase （撰寫階段）

• Testing Phase（測試階段）

• Maintenance Phase （維護階段）

Open Source project 的開發流程？

系統 / 工具

• Mailing list
  • Google Groups
• IRC
  • ChatZilla / irssi / webchat
• Issue tracking system
  • GitHub
• Wiki
• Continuous integration service
  • Travis CI

版本控制

Git

溝通工具

Mailing list

Google Groups

關於 Mail 的大小事

• 封存
• CC / BCC
• 引用
• 打招呼 告訴別人你是誰 結尾署名
• 設定 回覆所有人
• Lab 取消傳送
• 篩選器 / 標籤

IRC

#SITCON@freenode

IRC Client

• Irssi

• ChatZilla

• Web

• Registering your nick on freenode

• Registering a channel on freenode

Request and Analysis Phase
需求與分析階段

• 由於專案的人員身處各地，非同步化的討論是否會花費過多的時間？你的看法是甚麼？

• 參與專案的使用者若無具備軟體工程的基本概念，是否會導致溝通不良呢？你的看法是甚麼？

• 以傳統軟體工程的觀點，分析使用者的工作流程、習慣，整理成圖表，才能逐一地找出使用者的需求。
  所以，像 OSS 這樣無嚴謹化的需求分析真的能找出使用者的需求嗎？你的看法是甚麼？

• https://github.com/MongoEngine/mongoengine/issues/858

Issue tracking system

• GitHub

• GitLab

• Gogs

• Redmine

• Phabricator

SITCON

Redmine

Redmine

Redmine

GitLab

GitLab

Phabricator

Demo

sample: nw.js

Design Phase
設計階段

• 軟體的設計上是相當複雜的，所以採用簡單的架構，是否足夠？細部設計是由開發者自行設計或者仍需要溝通？如何溝通？

• 所設計的軟體架構的文件，能否充分表達設計概念？是否需要技術文件的附註？

Wiki

Demo / sample: node-webkit

• 軟體的環境會隨著技術的發展而變化，所以開發者如何因應？可否提出你的看法？

Coding Phase
撰寫階段

• 傳統的程式開發會採用自上而下、自下而上等整合方法。在你的專案中是否會採用到上述的方法？可否提出你的看法？

• 要 reuse 別人的程式碼到自己的專案中，這當中難道不會碰到結構上的問題嗎？如何處理？大部分 reuse 的程式碼需要修改嗎？還是只有部分的 reuse 的程式碼需要修改？

• OSS 的開發者進行開發時，對於所使用的開發工具或環境熟練嗎？若從未接觸過，他們是如何上手的呢？

Testing Phase
測試階段

• 專案中，是否有使用同僚覆核（peer review）的方式互相檢視專案人員的程式內容？

• 有人使用同僚覆核，需不需要其他動態的測試方法？若有，如何進行？沒有，又如何彌補這部分之不足？

Testing

Demo repo

Continuous integration

Travis / Jenkins

Travis

.travis.yml / result

Jenkins

• OSS 開發者是否會將軟體所出現錯誤進行分類？

• OSS 專案在發展模式和經濟的因素下，不會擁有專門進行軟體測試的 QA 團隊。所以只會有幾個 committer 或甚至是一個管理者，這樣的方式會不會較不嚴謹，錯誤率會不會偏高？

Maintenance Phase
維護階段

• 由於 OSS 軟體的版本釋出的時間相較於商業軟體是較短的，所以在這麼短的軟體發展生命週期裡，如何維護軟體的品質？是否較為困難？

• 開發者和使用者對於專案所發展的軟體，若沒有較宏觀的軟體架構的話，往後在系統整合或維護上是否相對困難？

• 由於非嚴謹的溝通和非標準的流程，是否會造成花費過多的時間？

動手練習實際付諸行動吧！

Thanks for listening

本投影片採用創用 CC「姓名標示—相同方式分享 3.0 台灣」授權條款