LeSS in Action - 後記

LeSS in Action - 後記

更新於 發佈於 閱讀時間約 3 分鐘

這系列大概花了快兩個月的時間快速的把學到的一些知識記錄下來,然而還是有許多內容很難用文章簡單的說明。

裡面有許多知識是需要靠著實踐才能夠學會的,因此在課程中我們需要先理解概念、實踐,最後在課後不斷的練習這些技巧內化成自己的技能。

重新思考開發

我認為自己屬於那種相當 Geek 的類型,也因此大多數時候都是在關注「怎麼做」跟「能使用怎樣的技術」這樣的問題上,卻很少思考「為何這樣做」的問題。

然而,每一個軟體被設計出來都是要解決問題。如果在實現軟體的時候只關注技術的部分,就會陷入使用的技巧非常華麗卻一點也不實用的狀況,甚至在未來要進行修改的時候變得非常困難。

這是一個非常值得反思的問題,也就是在探索技術之外,我們所設計的程式是否是真的實用的。

剛剛好的實現

假設我們關注在功能來開發,就能夠開始朝向「恰當」的實作前進。在過去我們會想要完整的考量所有東西、把架構規劃設計完善。然而,很多時候並不符合真實的狀況。

之前有寫過一篇軟體是一種生物的文章來描述軟體開發世界的多變,如果做了過多的設計我們面對「改變」是很脆弱的,因為所有設計都必須要大量的調整跟修改。

然而我們使用驗收測試驅動開發(A-TDD)的想法去看,假設第一個規格是顯示文字,我們只需要實現顯示文字即可。接下來是勇敢的面對改變,跟使用者確認這樣的功能是否符合,不符合就再繼續增加規格(新增測試)擴充,直到所有功能都符合使用者的期望為止。

搭配上測試驅動開發(TDD)的「小步前進」在對應變化的能力就會大幅的提升,這樣一來也能慢慢掌握「剛好」的實現來減少耗費額外的力氣。

總結

這門課程主要不是在學習某種技能,而是去重新了解被我們沒有完整理解的「敏捷開發」並且搭配實踐來更新思考的方式,唯一的缺點大概是會在工作上有些不習慣吧!

目前 LeSS in Action: Developer Practices 這門課程還有在台灣開設下一期的課程,大概是在九月的時候,想要完整學習的話還是推薦大家盡快報名。雖然費用不便宜,然而可以學到的知識很可能會改變未來工作的機會。


封面圖片使用 UnsplashAngelina Litvin 的作品,這系列的文章只是課程的一小部分,因此並無法完整涵蓋所有概念以及精神,看關於技術的主題可以到弦而時習之找找靈感。

avatar-img
蒼時弦也的沙龍
55會員
40內容數
軟體工程師逐漸變成一個熱門的職業,當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢?這系列的專欄會分享日常工作中的經驗以及一些案例分析,讓我們一起努力成為一位更優秀的軟體工程師吧!
留言
avatar-img
留言分享你的想法!
蒼時弦也的沙龍 的其他內容
雖然這系列的課程是設計給工程師的,然而在學習敏捷開發(Scrum 為主)的過程中,我們是從如何做「產品」的角度去做切入,也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異,也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念,要減少技術債的方式就是重構,然而在實踐重構的時候並非我們所想像的必須「安排時間」重構,而是在開發的過程中不斷的進行。
當我們使用主幹開發(Trunk-based Development)、以及驗收測試驅動開發(A-TDD)之後,所撰寫的程式碼會逐漸的變多,也因此我們會開始注意到程式碼有壞味道(Code Smell)的出現。
不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後,就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同,我們是以 Trunk-based Development(主幹開發)的方式進行,也就是只有 main 一條分支,並且所有人都會提交進去。
完成對功能的了解之後,我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是,我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中,我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
雖然這系列的課程是設計給工程師的,然而在學習敏捷開發(Scrum 為主)的過程中,我們是從如何做「產品」的角度去做切入,也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異,也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念,要減少技術債的方式就是重構,然而在實踐重構的時候並非我們所想像的必須「安排時間」重構,而是在開發的過程中不斷的進行。
當我們使用主幹開發(Trunk-based Development)、以及驗收測試驅動開發(A-TDD)之後,所撰寫的程式碼會逐漸的變多,也因此我們會開始注意到程式碼有壞味道(Code Smell)的出現。
不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後,就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同,我們是以 Trunk-based Development(主幹開發)的方式進行,也就是只有 main 一條分支,並且所有人都會提交進去。
完成對功能的了解之後,我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是,我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中,我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。