Tag Technical Debt

[CUSE] Discussion Paper ครั้งแรก

Blog นี้เป็น Blog ที่ดองมานานเกือบเดือนครับ เพราะจำได้ว่ารุ่งขึ้นมีสอบครับ ระหว่างอ่านทบทวนก็เริ่มเบื่อเลยมาเขียน Blog ดองไว้ครับ สำหรับการนำเสนอ Paper ครั้งนี้เป็นของวิชา Software Metrics ครับ โดยตัว Paper ที่กลุ่มผมนำเสนอชื่อว่า Applying Metrics to Identify and Monitor Technical Debt Items during Software Evolution ใน Paper นี้เป็นการบอกว่าเมื่อ Software มีการวิวัฒนาการขึ้นไปเนี่ย ถ้าเรามีการจัดการมันไม่ดี ทั้งด้าน Requirement Resource และเวลา ส่งผลให้ระหว่างที่…

Rewrite code is Refinance !!!

Blog นี้พยายามเขียนเป็น 2 ภาษา แม้ว่าผมจะรู้ภาษาอังกฤษแค่งูๆปลาๆนะครับ เข้าเรื่องเลยดีกว่าลองมาดูคำศัพที่คิดว่าควรรู้กันก่อน ทำไมต้อง Refinance แล้ว Refinance มันไปเกี่ยวกับ Rewrite code ยังไง ? ลองคิดดูทำไมเราต้องเขียน Code ใหม่หละ ? รู้จักกับ Technical Debt ก่อน แล้วที่เขียน Code ที่เขียนใหม่มันไม่ต่างกับ Refinance เหรอ  ? แล้ว อะไร คือ สิ่งที่ดีที่สุดหละ ปิดท้ายด้วย Code ที่คิดเอง ไม่รู้มีคนคิดซ้ำไหมนะ ลองอ่านดูครับ ^___^ Rewrite Code…

Technical Debt ไม่ได้เกิดจาก Developer อย่างเดียว !!!

ภาพจากเว็บ http://blog.crisp.se/2013/07/12/henrikkniberg/the-solution-to-technical-debt

วันนี้น่าจะเป็นวันที่ผ่านมากับ 1 ปี กับ อีก 6 เดือน สำหรับงานที่เข้ามาทำ BOTDMS – DataSet เป็น Module ที่เหมือนถูกทิ้งไว้กลางทาง หลายคนอาจจะส่งสัยว่าทำไมผมเขียน Blog ตอนนี้ขึ้นมา โดยที่ผมอยากเขียน เพราะอยากแชร์ประสบการณ์ครับ ถ้าเป็นเมื่อ 2-3 ปีก่อน ผมมองว่าเรื่อง Technical Debt มันเกี่ยวกับตัว Developer เป็นหลัก แต่หลังจากทำงานที่เรียกว่าเป็น Full-Stack ก็ได้ หลังจากทำงานนี้มา มุมมองของคำว่า “Technical Debt” ของผมเปลี่ยนไปมาก ผมว่าหนี้พวกนี้ ไม่ได้เกิดจากความมักง่ายของ Developer แต่เกิดจากทุกๆคนที่ทำงานร่วมกัน ทำไมหละ…

การทำหรือเผา Data Dictionary ที่มีประสิทธิภาพ

ตอนนี้โปรเจคที่ผมกำลังเข้าช่วงโค้งสุดท้ายในการลงนาม ตรวจรับ สิ่งที่สำคัญที่สุด คือ การเผา เอกสารครับ ตอนนั้นมีเอกสารในส่วนของฐานข้อมูล ผมขอเรียกมันว่า Data-Dict นะครับ ตอนแรกทีมที่ทำก็อึ้งๆ เนื่องจากโปรแกรมมีมานานและ 20 กว่าปี แต่ไม่เคยมี Data-Dict ที่สมบูรณ์สักที ทำไมทำมาได้ 1100 Table เพราะ มีหนี้ทางเทคนิค Technical Debt ที่เกิดจาก แต่งาน Customize เสริมยังดีที่มีการทำ Data-Dict มาแล้ว ก่อนตะแก้ปัญหา เราต้องดูก่อนว่ามี Resource อะไรบ้าง สิ่งที่ต้องทำ เผา Data Dictionary  ทันใน 1…

Workaround Solution กับ Technical Debt

ก่อนอื่นของกล่าวถึงคำว่า Workaround มัน คือ การแก้ปัญหาเฉพาะหน้า เฉพาะกิจครับ เช่น ระบบจำเป็นต้องต่อกับระบบ Network ผ่านสายแลน เนื่องจากต้องการความเสถียร และความเร็ว แต่ที่โต๊ะ User ยังไม่มีการติดตั้งระบบ Networkทางทีมเสนอให้ใช้ Wireless ไปก่อน เป็นต้นครับ ถ้านึกภาพไม่ลองออกไปดูพวก Trust me I am Engineer ก็ได้ครับ ฮ่าๆ ในแง่ของการพัฒนา Software ก็มีเหมือนกัน เจ้า Workaround มัน คือ การแก้ปัญหาเฉพาะหน้า เพื่อลดเวลา หรือความยุ่งยากในการพัฒนาครับ ซึ่งส่งผลกระทบโดยตรงกับ Code และตัวระบบครับ…

การออกแบบสะท้อน ถึงโครงสร้างและวัฒนธรรมขององค์กร

พอดีนั่งหาข้อมูลเกี่ยวกับตัว Technical Debt แล้วเจอตัวนี้เข้า ใช่เลย “Software Design mirrors the [Organizational and social] structure of the organization that builds it” “การออกแบบซอฟต์แวร์สะท้อน ถึงโครงสร้างและวัฒนธรรมขององค์กร ที่สร้างมัน” ลองดู Product ที่อยู่รอบตัวเราก็ได้ครับ อย่าง Google, Facebook และ Microsoft เป็นต้นครับ ทุกอย่างมีสไตล์การพัฒนาของตัวเอง อย่าง Google ทุกอย่างดูเรียบง่าย และไปในทางเดียวกันทุก Product แต่ฝั่ง Microsoft ที่เมื่อก่อนแต่ละ Product…

สายไฟที่ยุ่งเยิงกับซอฟต์แวร์ที่สับสน

ระหว่างทางไปทำงาน กลับบ้าน วิวรอบทางของมนุษญ์เงินเดือนในเมืองใหญ่ คงไม่พ้นกับสายไฟ สายโทรศัพท์ ดูๆไปแล้ว มันโคตรจะยุ่งเหยิง บดบังทศนีย์ภาพ แล้วถ้าเราเอาภาพของสายไฟ มาเปรียบกับ Software บ้างหละ สิ่งที่เราทำอยู่มันเป็นอย่างไร เริ่มที่ภาพแรกเลยและกัน ชุมสาย ชุม Code >> ยำ Code >> Spaghetti code ถ้ามี Change หละ คนแก้คงทำใจ ก่อนแก้ Code และจะต้องคิดหนัก ว่าแก้อย่างไร ไม่ให้กระทบ Code คนอื่น (สายไฟ สายโทรศัพท์ของเจ้าอื่นๆ) เปลืองสาย อันนี้ไม่แน่ใจว่า มีการขดสายไฟพันไว้ทำไม !!! แต่มุมของผมเดินผ่านมา…

Technical Debt เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!

จากหัวข้อของบทความ หลายคนน่าจะสงสัยว่าทำไม “เขียน Code แล้วทำไมถึงติดหนี้ แถมมีดอกเบี้ยด้วย !!!” เดี๋ยวผมจะมาอธิบายครับ ว่าทำไมเราถึงได้สร้างหนี้ และหนี้ในการเขียน Code จริงๆ ก็ไม่เชิงนะ บอกว่าเป็นหนี้ในการพัฒนาระบบ น่าจะดีกว่าครับ โดยหนี้ที่เกิดขึ้นมี ดังนี้ครับ Acceptable – เป็นหนี้ในระยะสั้น และระยะยาวได้ประโยชน์ มองเป็นการลงทุนแนวๆ VI ได้เลยนะเนี่ย Unavoidable – หนี้ที่เกิดจากสถานการณ์ที่เราไม่สามารถคาดเดาได้ Unnecessary – หนี้ที่เกิดแล้วทำให้ระบบงานเรารอดมีงานส่งได้ หนี้ที่เกิดแล้วทำให้ระบบงานเรารอดมีงานส่งได้ แต่ไม่มีประโยชน์ให้แก่ทีมงาน หรือองค์กรเลย Bad – หนี้แบบซุกไว้ใต้พรม หนี้แบบนี้ ถ้าเกิดแล้วระบบงานของเราคงจะรอดยาก หรือขึ้น Production…