關於 agile tdd ，我們在網路上蒐集到這些相關的討論、資訊與評價

ถ้าพูดถึงการพัฒนาซอฟต์แวร์ จะว่าไปแล้วมันก็ดูเป็นสิ่งนึงที่ติดลูป วนไปวนมาในชีวิตชาวเดฟเหมือนกันนะ โดยเฉพาะอย่างยิ่งกับองค์กรที่ใช้ Agile และ Scrum ในการทำงาน ที่มีการแบ่งการทำงานเป็นรอบ ๆ (Sprints)
.
เพราะคุณจะต้องเก็บ Requirements ของลูกค้าหรือผู้ใช้งาน แล้วก็นำไป Design และ Process เป็นซอฟต์แวร์ขึ้นมา จากนั้นก็ไปเก็บ Feedback จากลูกค้าหรือผู้ใช้งาน เพื่อนำ Feedback ไปปรับปรุงและพัฒนาซอฟต์แวร์ต่อในรอบถัดไป 🤔
.
👉 ซึ่งในการพัฒนาซอฟต์แวร์จะมีคำอยู่คำนึงที่มักพูดถึงกันบ่อย ๆ นั่นก็คือคำว่า “Technical Debt” หรือแปลเป็นไทยตรง ๆ ว่า “หนี้ทางเทคนิค” นั่นเอง
.
.
🔥 Technical Debt คืออะไร?
.
คำว่า Technical Debt เกิดขึ้นครั้งแรกโดย Ward Cunningham ตอนกำลังทำ Software ด้านการเงินอยู่ (เขาคือ 1 ใน 17 คนที่ได้คิดคำว่า Agile ขึ้นมา) ซึ่งเขาอยากอธิบายปัญหาที่เจออยู่ให้นายจ้างที่ไม่รู้เรื่อง Technical จึงเลือกเปรียบเทียบปัญหาทางเทคนิคกับหนี้ทางการเงิน (Monetary Debt) 💸
.
👉 คำว่า Technical Debt จึงพูดถึงปัญหาต่าง ๆ ด้านเทคนิค 💻 ไม่ว่าจะมาจากการเขียนโค้ดที่ไม่ดี Design ที่ไม่มีคุณภาพหรือไม่ยืดหยุ่น การละเลยปัญหาบางอย่างระหว่างพัฒนา หรือสาเหตุใด ๆ ก็ตามที่สุดท้ายก็ต้องมาตามแก้ทีหลังอยู่ดี
.
.
🔥 Technical Debt เกิดจากอะไรได้บ้าง?
.
เป็นคำถามที่มีคำตอบได้ล้านแปดอย่าง เพราะการพัฒนาซอฟต์แวร์คงหลีกเลี่ยงปัญหาไม่ได้อยู่แล้ว ยิ่งเป็นซอฟต์แวร์ขนาดใหญ่แล้ว ยิ่งใช้เวลามากเท่าไหร่ หรือมีคนร่วมพัฒนาเยอะแค่ไหน ก็อาจทำให้มีปัญหาอีกมากมายที่รอให้เราไปตามแก้อยู่ 🤕
.
👉 และที่สำคัญ Technical Debt ไม่ได้มีแค่ “โค้ด” เท่านั้น ไม่ว่าจะปัญหาจากการออกแบบ การเทสต์ การทำเอกสาร เครื่องมือที่เลือกใช้ในการพัฒนา หรือผู้ร่วมพัฒนาเองก็เป็น Technical Debt ได้เหมือนกัน
.
.
🔥 ตัวอย่าง Technical Debt ที่คุณอาจจะได้เจอ
.
🔹 ใช้ Architecture หรือ Tools ต่าง ๆ ไม่เหมาะกับสิ่งที่พัฒนาอยู่
🔹 รู้ว่าซอฟต์แวร์มีปัญหาตรงไหน แต่ไว้ก่อนจนสุดท้ายไม่ได้แก้
🔹 เวลาที่ให้ไม่สอดคล้องกับจำนวนงานที่ต้องทำ
🔹 ไม่เข้าใจซอฟต์แวร์ที่กำลังทำอยู่
🔹 ลืมทำ Documents หรือทำแบบขอไปที ไม่มีคุณภาพ
🔹 เขียนโค้ดซับซ้อน อ่านทำความเข้าใจและ Maintain ได้ยาก
🔹 คนในทีมมีภาระหนักเกินไป เช่น ทำงานมากกว่า 1 งาน ในเวลาพร้อม ๆ กัน
.
.
🔥 ทำยังไงดี ถ้าไม่อยากมี Technical Debt
.
เอาเข้าจริง ๆ แล้วการพัฒนาซอฟต์แวร์ คงจะหลีกเลี่ยง Technical Debt ได้ยาก แถมพอมีแล้วก็ต้องตามแก้กันอีก ราวกับส่งดอกให้เจ้าหนี้ 😔 แต่ถึงจะเลี่ยงได้ยาก ก็ไม่ได้แปลว่าจะเลี่ยงไม่ได้เลย เรามาดูวิธีลด Technical Debt กันดีกว่า
.
👉 แน่นอนว่า สิ่งที่ช่วยลด Technical Debt ได้ดีที่สุด ก็คือการไม่สร้างมันขึ้นตั้งแต่แรกด้วยวิธีต่าง ๆ เช่น เขียนโค้ดให้ Clean, ใช้ Test-Driven Development (TDD) ในการพัฒนา, ทำ Unit Testing รวมถึงวางแผนการพัฒนาซอฟต์แวร์ให้ดีและเลือกใช้เทคโนโลยีที่เหมาะกับสิ่งที่ทำ
.
🤔 แต่ถ้ามันเกิดขึ้นมาแล้ว จะทำยังไงล่ะ? ข้อแรกเลยคือต้องรู้ก่อนว่า อะไรเป็น Technical Debt ของซอฟต์แวร์ แล้วจึงหาวิธีแก้ไขปรับปรุง โดยจัดลำดับความสำคัญของปัญหาที่เจอ แล้วแก้ไปเรื่อย ๆ เพื่อให้ Technical Debt ลดลง อย่าแค่รู้ว่ามีปัญหาอะไร แล้วก็ไว้ก่อน จนสุดท้ายก็ไม่ได้แก้
.
.
📌 สรุปแล้ว Technical Debt ก็ไม่ได้ต่างจากหนี้ทางการเงินเท่าไหร่ เพราะมีหนี้ก็ต้องมีจ่าย และไม่ได้จ่ายแค่เงินต้น เราต้องเสียดอกเบี้ย และจะเสียมากขึ้นไปอีก ถ้าปล่อยให้หนี้ก้อนนี้อยู่ไปนาน ๆ เหมือนกับ Dev ที่ต้องมาตามแก้ปัญหาต่าง ๆ แถมถ้าทิ้งไว้นานแล้ว หรือเป็นหนี้ก้อนใหญ่ ก็ต้องใช้ทั้งแรง ทั้งเวลา และทั้งเงินในการขจัดปัญหานั้นมากกว่าเดิม
.
เพราะฉะนั้น ถึงเวลาแล้วล่ะ 🙌 ที่จะบอกลา (หรือลด) คำพูดก่อหนี้อย่าง “เดี๋ยวค่อยทำ” หรือ “ทำ ๆ ให้เสร็จไปก่อน” หรือ “ไม่ต้องมี Test หรอก” เพื่อให้เกิดหนี้ทางเทคนิคอย่าง Technical Debt น้อยที่สุดนั่นเอง~
.
.
🔖 ขอบคุณข้อมูลจาก
https://siamchamnankit.co.th/ว่าด้วยเรื่อง-หนี้ทางเทคนิค-technical-debt-ทำไมต้องใส่ใจ-b7a0c296b590
.
borntoDev - 🦖 สร้างการเรียนรู้ที่ดีสำหรับสายไอทีในทุกวัน
#TechnicalDebt #BorntoDevวันละคำ #BorntoDev

什麼是 BDD?

BDD 是 Behavior Driven Development 的縮寫. 它和 TDD, exploratory testing 是 Agile Testing 最重要的三個新的 practice.

很多人都聽過這個名詞, 但是不知道他是什麼

Dan North 在 twitter 上用了這樣一句話來說明
“Using examples at multiple levels to create shared understanding and surface uncertainty to deliver software that matters.”

這裡有提到幾個重點

(1) examples
怎樣解釋需求是最有效的方式, 那就是舉些範例, 由範例來讓大家了解這個需求是怎麼運行的

(2) shared understandling
這個 practice 的重點是要達成共識. 如果你的 BDD 只是工程師自己寫寫自動化, 沒有 PO 或是客戶的加入, 那不能稱為是 BDD, 那只是你多寫了一些測試程式.

(3) surface uncertainty
那些範例需要寫出來? 是什麼地方需要有共同了解? 不是都寫些大家都知道的, 不確定的部分更是我們處理的重點.

(4) deliver software that matters
除了不確定的部分, 有價值的部分更是我們要優先釐清.

這樣有幫助你了解在實施 BDD 時, 什麼地方透別要注意嗎？

如何寫出人人有共識的需求 - 範例描述需求篇
https://kojenchieh.pixnet.net/blog/post/558923197-specbyexamplecourse
報名網址:
https://forms.gle/zqgPBEyCvcEhN6ms5

最近 Agile 台中 #單元測試線上工作坊 連三發。

先由 Max 打頭陣，用 Python 示範，
再由 Kuma 接棒，用 Java 示範，
接著由 Recca 用 PHP 示範。

我可以拍胸脯跟各位保證，他們幾位講單元測試內容都很專業的，因為都來過我的單元測試課一起交流過，他們實務上也都會落實撰寫單元測試，甚至 TDD 去輔助開發他們的產品。

至少我們這個流派，測試都是用來描述需求使用情境的，用來抓 production code API 易用性問題、職責設計的問題，那種 auto-validation(testing) 的回歸測試，只是順便的好處而已。

要聽，就要聽這種專業的陣容啊，大家都是實際在戰場用這種方式在打仗的。

那種只是教教 test framework, 工具, mock framework 的，要聽也是可以啦，只是如果連這樣的簡介你都不想花時間了解，即使聽了，你在實務上還是用不上去，得不到真正的好處的。只會產生一種錯覺：「我也會寫測試，只是 legacy code 太髒，要花我太多時間去寫測試了，我時間不夠，不然我也可以」

No, sorry，你不行，你就是不行。

因為可以的、能寫測試的，從來都不會覺得自己「沒時間寫測試」。

--
偷偷蹭一下大家的光芒，雖 #不要臉，但 #我驕傲