Application Lifecycle Management
協同平台
Trello
OneNote
Slack
TFS 2013
Continuous Delivery,CD
自動化部署
Continuous Integration,CI
迷思
『軟體工程需要在多人團隊下運行』
管理,最困難的部份在溝通,人數越少,溝通路徑越少,溝通路徑公式P=N(N-1),人數越少溝通路徑越短,就算是一人開發也是能夠使用ALM
『工作單越多代表績效越高』
工作單數量不應該拿來當做績效依據,軟體開發項目有分簡單跟困難,若拿到困難的單子的成員,績效永遠都不好??這會讓工作進度會議看起來像批鬥大會
『犧牲品質可以增加開發速度』
專案不會因為接受低品質的軟體而進行得比較快,也不會因為要求高品質而進行得比較慢,一旦因為低品質而造成無法交付,日後的維護可能要花兩至三倍的時間;我只有在實作Prototype時會犧牲品質
我怎麼做Prototype
『買了CI Server,就可以天下無敵、藥到病除』
流程的改進是要由內至外,由上至下,不論決定使用哪一套CI Server,它不會自動縮短交付時間,不會自動提昇品質,開發/管理人員必需要投入一定的時間持續學習、持續進步。
特性
建置→測試→部署→反饋
建置、測試、分析、部署、產生文件
自動化,不需人工介入
用途
管理、開發、測試都使用一樣的平台來協同合作,工作單、BUG單與程式碼連結
開發團隊可以提早發現問題
不懂技術的管理團隊,透過報表就能知道系統的健康度、完成度
縮短開發時間
提昇軟體品質
六個階段
Feedback
部署
部署-SQL
部署-Desktop
部署-WebSite
部署流程
QA手動(簽核機制)佈署到正式環境
QA用測試環境測試
自動佈署到測試環境
建置流程
然後在TFS上執行測試
然後在TFS上Build
TFS會從程式碼版控取得最新的程式碼
任何一個人簽入程式碼
目的
確保每個人拿到程式碼都能夠Build
程式不能只有你自己的電腦能跑
常見問題
拿到別台電腦就不能跑
應用程式在自己的電腦跑沒有問題
ALM 測試
種類
冒煙測試
壓力測試
效能測試
功能驗收測試
你如何驗證程式?
實例化
同一個專案,同時維護debug和release mode
有甚麼不同?
如何做?
差異設定從程式碼中抽取出來
Transform
抽到哪裡?Web.config/App.config
為了避免濫用 #if,使用 Conditional 屬性可以讓你降低錯誤發生
[Conditional]
#if(Debug)
手動調整
ADO.NET Entity Framework for C#
LINQ for C#
ALM 開發 for C#
OOP(Object-Oriented Programming)
根據實際狀況調整
3 Layer
OOD(Object-Oriented Design)
對需求的不瞭解
扶把害消防設備無法驗收
PM想的跟客戶要的不一樣,Developer做出來的不是PM要的
OOA(Object-Oriented Analysis)1
開始之前
工作流程
對開發人員來說
不要瞎忙
改善開發流程讓應用程式品質更好、產出更有效率
例子
晶圓廠製程改善,提升產線效能
企業內部工作流程電子化
流程改善
導入
實作
學習
找出問題
原本的工作流程已經可以完成工作
你是怎麼寫程式的?
有思考過需求嗎
需求有沒有真的被實作
需求有沒有被確認過
有思考過架構、效能嗎
不管三七二十一,瘋狂的寫
小調查
testability表示軟體透過測試(通常是以執行待測程式的方式來測試)可以被找出錯誤的難易程度。因為軟體開發至少有40%的成本是花費在測試上面
整個軟體生命週期裡面最花時間的是哪個階段?
維運
部暑
測試
開發
設計
需求
曾經因為需求異動把正式環境的資料弄壞了?
能熟悉、很有把握地修改你所維護的專案?
測試這件事花不花時間?
改完程式碼,你會全部測過嗎?
測試是否為開發的一部分?
程式寫好後會做測試嗎?
小故事
巴格王