บทความ IT เจ๋งๆ

สำหรับ Developer แล้ว คุณควรเขียน Code หรือสร้างอะไรก็ตาม ที่จะไม่ทำให้คนที่จะมา Monitor Code ของคุณ เกิดความยุ่งยากในการทำงาน อยากให้มองว่าคนที่มา Monitor Code ของคุณ (ซึ่งส่วนใหญ่มักเป็นทีม Operation) เป็นเหมือนหนึ่งในลูกค้าที่คุณกำลังสร้าง Software ให้เขา นั่นคือ คุณควรทำให้คนที่ทำงานต่อจากคุณ ทำงานได้ง่ายและสะดวกขึ้นนั่นเอง เรามาดู วิธีมัดใจทีม Operations ของ Developers

• ทำตาม Standard ที่ตกลงกันไว

หากคุ้นเคยกับ Structure ของ Software คุณจะทำงานสะดวกขึ้น ดังนั้น ควรเขียนและทำตามชุดของ Standard ว่าอะไรที่เทคโนโลยีต้องใช้, วิธีใช้ รวมทั้งภาพรวมของ Software

• อย่ามองข้ามเรื่องที่สำคัญ

หากคุณต้องการใช้ Document Database ซึ่งคุณควรรู้จักและใช้ JsonDB หรือ Nitrite ใน Software ของคุณด้วย แต่คุณได้วางมันในจุดที่เหมาะสมใน Disk แล้วหรือไม่ มันมีการถูก back up หรือ replicate อย่างเหมาะสมหรือไม่ และอีกหลายประเด็นที่เกี่ยวข้อง ดังนั้น จึงไม่น่าแปลกใจว่า ทำไมคนที่ Monitor Code ของคุณอาจไม่สบอารมณ์เอาได้

การทำตาม Infrastructure ที่เหมาะสม ซึ่ง support ทั้ง business & technical requirements นั่นหมายถึง คุณอาจไม่ได้ทำตามที่คุณอยากทำ และต้องทำตามที่กำหนดไว้ อย่างไรก็ตาม มันจะช่วยให้คุณเลี่ยงจากปัญหาหรือถูกไล่ออก เมื่อเกิดปัญหาด้าน Infrastructure ที่ไม่คาดคิด จนส่งผลให้เกิดการสูญหายของข้อมูล

• มีขั้นตอนการ Review อย่างสม่ำเสมอ

ควรมีขั้นตอนการ Review ตาม Standard ที่กำหนดไว้สำหรับสิ่งที่อยู่ใน Software และขั้นตอนใดที่อยู่ในกระบวนการ QA และ Deployment หากองค์กรของคุณไม่มีการทำแบบนี้ ก็ควรสร้างมันขึ้นมา เมื่อมีอะไรเปลี่ยนแปลง ไม่ว่าจะใน release notes, installation guide และจุดไหนก็ตาม อย่าใส่แค่ “มีการเปลี่ยน JSON Code” แต่ให้ใส่ว่า “นี่คือการแก้ไข Bug เล็กๆ น้อยๆ ที่ไม่ขึ้นอยู่กับ หรือส่งผลกระทบต่อ Infrastructure”

• แสดง APIs (อย่างปลอดภัย)

แทนที่จะต้องคลายไฟล์ Zip หรือจัดการว่า จะเปิดหรือปิดอะไร หรือเปลี่ยนแปลงการ Config. ค่าบางอย่าง ก็ให้ แสดง API นั้น เพื่อทำให้ Software ของคุณสามารถจัดการได้ง่ายขึ้น แต่อย่าทำเช่นนี้ใน port 80 ควรทำตาม Security Standards ที่ดี

• แสดง Metrics

ใน APIs เหล่านั้น ให้แสดง Metrics ทำให้สามารถตรวจสอบ Software ของคุณได้ มีการ Track ข้อมูลอย่าง requests per second, financial transactions per day หรือ performance metrics ทำงานร่วมกับทีม Operation เพื่อหาว่าสิ่งใดที่ควรMonitor บ้าง

• Support เครื่องมือในการ Monitor

ทำให้แน่ใจว่า APIs เหล่านั้น Support เครื่องมือในการ Monitor ของทีม Operation บางครั้ง ทีม Operation อาจใช้ Nagios โดยหวังว่าจะไม่ติดอยู่กับ HP OpenView version เก่าๆ (ซึ่งสถานการณ์นี้ อาจเกิดกับ บริษัทขนาดใหญ่บางแห่ง)

• วางมาจรฐานการ Installation

พยายามทำให้ทุก Version ของการ Installation มี Pattern ไปในแนวทางเดียวกัน ถ้าจะให้ดีก็ทำให้เป็น Script หรือ ชุด Installation ไปเลย (อย่างเช่น “คัดลอกไฟล์ .war ที่นี่”)

• เผยแพร่คู่มือการ Migration

การเปลี่ยนแปลงของ Database และ Structure ต่างๆ สามารถเกิดขึ้นได้เป็นครั้งคราว ไม่ว่าคุณจะเปลี่ยนแปลงอะไรในขั้นตอนพัฒนาหรือ Test ก็ตาม ควรบันทึกการเปลี่ยนแปลงนั้นไว้ด้วย และอธิบายว่าเปลี่ยนแปลงอะไรและทำเพราะอะไร จัดทำคู่มือการ Migration เป็น Step by Step เพื่ออธิบายถึงสิ่งที่ทีม Operation ควรทำและเพราะอะไร ถ้าเป็นไปได้ ให้สร้าง Script ที่สามารถ reproduce ได้ง่าย ขึ้นมาด้วย

• อ่อนน้อมถ่อมตน

หาก Developer คนไหนมี Ego ล่ะก็ คงไม่มีใครอยากร่วมงานด้วย ลองเปลี่ยนเป็น การขอความช่วยเหลือเพื่อให้แน่ใจว่า Software สามารถจัดการ, ตรวจสอบ และติดตั้งได้

ที่มา:  https://www.infoworld.com/

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

บทความที่เกี่ยวข้อง

• 6 เคล็ดลับ การเขียน Clean Code
• 4 Features ที่ควรมีใน Low-Code Development Platforms
• ข้อผิดพลาดของ Junior Developer พร้อมวิธีหลีกเลี่ยง