蒼時弦也
54 位追蹤者
我是軟體開發的求道者蒼時弦也，主要使用猶如賢者之石一般的 Ruby 語言，期望能夠在軟體開發這條路上找出一個能讓每個人都享受撰寫程式樂趣的方法，並且讓世界上能有更多優秀的程式被設計出來。
55會員
40內容數
軟體工程師逐漸變成一個熱門的職業，當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢？這系列的專欄會分享日常工作中的經驗以及一些案例分析，讓我們一起努力成為一位更優秀的軟體工程師吧！
全部內容
由新到舊
最近工作上以及私下跟朋友討論時，剛好都遇到了 Null（不存在）類型的處理，通常我不會特別去在意這件事情，然而近年讀了一些關於 Null 的文章後（如：The worst mistake of computer science）對於這件事情的看法有不少改觀。
執行力低下的宅宅們想要去奇美博物館總是需要鼓起很大的勇氣，在一年後我們終於下定決心出發去台南。然而，因為疫情的爆發加上確診，原本應該在涼爽的春夏交錯之時抵達，一直延後到了即將迎來鬼怪狂歡的盛夏。
因為經常有面試人的機會，然而在不同的面試條件中有一個「Problem Solving」的項目讓我一直在思考代表怎樣的意義，剛好在 LeSS in Action 的課程中有了一些想法。
這系列大概花了快兩個月的時間快速的把學到的一些知識記錄下來，然而還是有許多內容很難用文章簡單的說明。
雖然這系列的課程是設計給工程師的，然而在學習敏捷開發（Scrum 為主）的過程中，我們是從如何做「產品」的角度去做切入，也因此在課程接近尾聲的時候我們再次討論了產品跟專案的差異，也是這一週課程中各種安排的理由所在。
我們已經了解到了驗收驅動開發、持續整合以及壞味道這幾個概念，要減少技術債的方式就是重構，然而在實踐重構的時候並非我們所想像的必須「安排時間」重構，而是在開發的過程中不斷的進行。
當我們使用主幹開發（Trunk-based Development）、以及驗收測試驅動開發（A-TDD）之後，所撰寫的程式碼會逐漸的變多，也因此我們會開始注意到程式碼有壞味道（Code Smell）的出現。
不同於我們大多數討論持續整合（Continuous Integration）是以工具為主的議題，在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代，也因此必須持續的將團隊的產出整合在一起。
當我們能夠通過一個驗收測試後，就是時候將程式碼推送到遠端的服務中。跟基於分支的開發方式不同，我們是以 Trunk-based Development（主幹開發）的方式進行，也就是只有 main 一條分支，並且所有人都會提交進去。
完成對功能的了解之後，我們就要開始進入實現功能的開發階段。跟以往的開發流程不同的是，我們在敏捷開發中注重的是製作有價值的東西。也就是在計畫中，我們獲取的資訊都是對使用者有用、可以被看見以及操作和跨團隊協作的性質。
