ถ้าพูดถึงการพัฒนาซอฟต์แวร์ จะว่าไปแล้วมันก็ดูเป็นสิ่งนึงที่ติดลูป วนไปวนมาในชีวิตชาวเดฟเหมือนกันนะ โดยเฉพาะอย่างยิ่งกับองค์กรที่ใช้ 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
「technical debt」的推薦目錄:
technical debt 在 矽谷牛的耕田筆記 Facebook 的最佳貼文
ref: https://svpino.com/lessons-learned-from-the-smartest-software-engineer-ive-met-35895ac9fe3a
本篇文章是工作經驗談,作者想要分享這十多年的工作經驗中,從那些聰明人身上所學到的事情,包含了
1. Fast is better than good
2. Unlearn what you know about technical debt
3. There aren’t stupid questions
4. Communication outweighs technical skills
5. Just because you can doesn’t mean you should
6. Share like there’s no tomorrow
7. Take full responsibility
8. The best code is the one nobody wrote
9. If you don’t test, it doesn’t work
10. Embrace failures
Fast is better than good
大部分的情況下,一個稱得上是好的解決方案勢必都要能夠針對時間,精力與成本這三個方面取得平衡。
太多人很容易一開始就會想要設計最完美個解決方案,導致一開始花費大量時間在思考跟設計,卻遲遲沒有動手。
作者認為不是說不要思考,而是不要認為有辦法一開始就可以想到一個最佳解,而是應該一邊做一邊改進。
Unlearn what you know about technical debt
技術債想必是大家都很厭惡的一個情境,作者希望大家可以從不同層面的地方去看待技術債
作者認為只要能夠用正確的方式去面對,技術債身上也可以有值得學習的機會,因為大部分的技術債
都是因為時間與人力不足下進行取捨所造成的結果,這邊帶來的隱含是到底哪些事情是團隊當前最重要的,哪些是不重要可以之後再改善的
最後來個公道話,計畫債太多一定有問題,但是沒有技術債更大的機率代表你都把時間花費在不是最重要的事情身上
There aren’t stupid questions
有問題就使勁地去發問,更多時候努力工作並不會讓你這個人獲得一個很深刻的印象,但是有效率與聰明的工作相對容易讓你被人記住。
任何不清楚的地方就問,問到一切都明瞭。
最後補上一個引言
「會問問題的人會當傻子五分鐘,但是不問問題人的人則是一生傻子」
Communication outweighs technical skills
能夠透過溝通來清楚描述想法的能力可謂是一個不可或缺的技能。
相對於技術能力來說,溝通能力很容易被大家給遺忘,甚至大家都不會覺得這記得有什麼值得重要的。
但是良好的溝通帶來的效果是無形的,所以請投資時間去學習如何有效的溝通。
Just because you can doesn’t mean you should
最簡單為團隊帶來影響的方式就是好好的針對所有事情排定優先順序,學會如何分辨重要性其實非常重要
畢竟時間有限,如何於有效的時間內帶來最大的效益也是一個不可或缺的技能
Share like there’s no tomorrow
隱瞞各種資訊並不會讓你成為團隊中不可或缺的關鍵人物,相反的,願意分享事情與知識的人更容易變成團隊中的核心角色
學會分享也同時藉由分享的這個步驟讓整體團隊一起成長
後續有興趣的可以參閱原文
technical debt 在 CloudMile 萬里雲 Facebook 的最佳貼文
「 榮獲 Google Cloud #雲端搬遷 認證!」
超過 400 個企業數位轉型認可,
CloudMile 在 2021 年 6 月獲得
『 Google Cloud 雲端搬遷技術認證 』!
過去 4 年的 CloudMile 團隊努力下,
除了在國內外服務超過 400 多家企業,
數位轉型服務已跨足超過 10 個產業,
橫跨零售、金融、高科技製造、遊戲與公部門,
進軍新加坡,更獲政府部門的正面肯定!
#眼睛看不到,#不代表不存在。
企業長期累積的技術債(Technical Debt)
透過 CloudMile 雲端轉型計畫
都可以助您重新開始!
瞭解更多 CloudMile 雲端搬遷服務
👉 http://bit.ly/Q3CloudMigration-1
#GoogleCloud #CloudMigration #GCP
technical debt 在 What is Technical Debt? Definition, Types and Best Practices 的推薦與評價
Join our Slack Community for FREE: https://kode.wiki/JoinOurSlackCommunity Hello and welcome to our video on technical debt. ... <看更多>
technical debt 在 Stop saying “technical debt” - Stack Overflow Blog 的推薦與評價
Technical debt is about the conscious, collective choice between a tactical solution and a slower but more robust approach. The whole team makes ... ... <看更多>