บทความ IT เจ๋งๆ
11 คุณสมบัติ บ่งบอกว่า Code ที่คุณเขียนอยู่ เป็น Code ที่ดี
27-เม.ย.-18
คัมภีร์เทพ IT
หากคุณเป็น Programmer, Developer หรือ Software Engineer แน่นอนว่าทักษะ Coding ถือเป็นสิ่งสำคัญกับชีวิตการทำงานของคุณ และไม่ว่าคุณจะใช้, ชอบ หรือถนัดภาษา Programming ใดในการเขียน Code ก็ตาม ก็ควรคำนึงถึงคุณภาพของ Code เหล่านั้นด้วย เรามาดูกันว่า คุณสมบัติอะไรบ้าง ที่บ่งบอกว่า Code ที่คุณเขียนอยู่เป็น Code ที่ดี
1. Debuggable
จะว่าไปแล้ว Runtime ที่ออกมาในช่วงหลังๆ นี้ ก็มีการอนุญาตให้คุณเพิ่มตัว Debugger เข้าไปได้ อย่าง Node.JS เองก็สามารถถูก Debug ได้โดย Visual Studio ดังนั้น ตอนที่คุณเขียน Code มันจะเป็นการดี หากคุณคิดเผื่อไว้ว่า วันหนึ่งคุณอาจจะเพิ่ม Debugger เข้าไป แต่เมื่อคุณทำเช่นนี้ ในบางครั้งมันอาจมีผลต่อวิธีการจัด Structure ของข้อมูลอยู่บ้าง คุณอาจใช้ตัวแปรชั่วคราวมากขึ้นเพื่อที่คุณจะได้ไม่ต้องไปวุ่นวายกับ Structure แต่โชคดีที่สิ่งเหล่านี้มักได้ผลออกมาดี วิธีที่ดีที่สุดที่คุณจะเริ่มต้นฝึกใช้ Debugger คือตอนที่คุณยังไม่เจอปัญหา แล้วลองดูว่าผลงานออกมาเป็นอย่างไร
2. Loggable
ไม่ว่าคุณจะใช้ Debugger ที่ทันสมัยแค่ไหนก็ตาม ก็อย่าลืมว่าในความเป็นจริง Code ของคุณอาจไป Run ที่ไหนก็ได้ อาจเป็นแบบ Serverless, Multithreaded หรือ Distributed หรืออาจ Run บน Cloud ก็ได้ ซึ่ง Environment เหล่านั้นมันทำงานไม่เหมือนตอนทำในคอมพิวเตอร์ของคุณ ดังนั้น คุณจำเป็นต้องใช้ Log ซึ่งหมายถึง คุณต้องเขียน Code และติดตั้งส่วนที่เกี่ยวกับLogging เข้าไปด้วยใน Software ของคุณ เพื่อให้สามารถอ่าน Log เหล่านั้น หรืออย่างน้อยก็ให้ตัว Log reader สามารถอ่านมันได้
3. Testable
Software ที่ดีนั้น ควรจะสามารถทำการ Test ได้ด้วย ซึ่ง Software ที่สามารถ Test ได้ง่ายนี้ ควรจะแบ่งออกเป็นฟังก์ชั่นที่เข้าใจได้ง่ายซึ่งจะช่วยให้การ Verify สิ่งต่างๆ ทำได้สะดวกขึ้น นอกจากนี้ Testable Software ควรจะช่วยส่งเสริมให้การทำงานต่างๆ ดีขึ้นและมีความยืดหยุ่นสูง ถ้าคุณเจอ Code ที่เขียนขึ้นโดยไม่มีการ Test มาก่อน คุณก็ควรเขียนมันจังหวะที่คุณต้องเข้าไปแก้ไขมันนั่นแหละ และที่สำคัญ ถ้าเป็นไปได้ ควรเขียน Test ซะก่อนตั้งแต่ต้นด้วย
4. Fast-failable
สัญญาณบ่งบอกว่า Code ของคุณน่าจะมีปัญหาถ้าหากใน Code ของคุณ มีบรรทัดที่เขียนว่า if (myvar == null) myvar =""; อยู่ด้วย และ Developer ที่เขียน Code บรรทัดนี้น่าจะเป็นมีความเลินเล่อไปหน่อย อะไรที่มันไม่ควรเกิด ก็อย่าทำให้มันเกิด แต่เมื่อมันเกิดปัญหาขึ้นใน Code แล้ว ก็ควรแจ้งเตือนข้อผิดพลาดออกมาให้หมด เพราะ ปัญหาต่างๆ จะได้ถูกแก้ไขเสียก่อนและไม่ส่งผลลุกลามต่อไปอีก ดังนั้น ควรรีบหาข้อผิดพลาดให้เจอเสียก่อน ยิ่งเร็วเท่าไรก็ยิ่งดี
5. Idempotent
ความหมายของมันก็คือ ไม่ว่าคุณจะทำมันกี่หน ก็ได้ผลลัพธ์ออกมาเหมือนเดิม ซึ่ง concept นี้ควรจะมีอยู่ทั่วทั้ง Code ของคุณ ซึ่งหมายถึง ไม่ว่าคุณจะเปลี่ยนบรรทัดใน Debugger ไป แต่ก็พบว่า มันยังคงช่วยแก้ปัญหาที่เจอได้ และเมื่อ Debugger เริ่มวนกลับไปทำงานใหม่ ผลยังคงออกมาเรียบร้อยดีเช่นเดิม การทำแบบนี้จะช่วยให้คาดเดา Software ได้ว่า มันจะไม่สร้างข้อมูลที่ยุ่งเหยิงวุ่นวายออกมาในอนาคต
6. Immutable
Concept หัวข้อนี้คือ การทำให้ Variable หรือ Data Structure เป็น Read only อย่างเดียว ในกรณีที่ Variable หรือ Data Structure นั้น ถูกใช้โดยหลายๆ thread พร้อมกัน เพราะถ้าปล่อยให้ Data Structure นั้นถูก Modify ได้จากหลายๆ Thread เวลาเกิดปัญหาขึ้น แล้วมันจะทำการ Debug ได้ยากกว่านั่นเอง
7. Intelligible
เมื่อ Functional Programming เป็นที่นิยม ก็มีผู้คนใช้กันอย่างแพร่หลาย แต่พวกเขากลับลืมไปว่า Code เหล่านั้นควรจะอ่านได้ง่ายด้วย ซึ่งมันก็คงเหมือนกับ Object-Oriented Code เมื่อสัก 1-2 ทศวรรษที่ผ่านมา ตามหลักการคือ การ Compile จะสร้าง Code ที่ Computer สามารถอ่านได้ ส่วนในฐานะที่เป็น Developer หน้าที่ของคุณคือ สร้าง Code ที่ทำให้มนุษย์อ่านได้เช่นกัน
8. Modifiable
เมื่อไม่นานมานี้ Andrew (ผู้เขียนบทความ) ต้องการจะเปลี่ยนแปลงแก้ไขบางส่วนใน Code (เพื่อจับ Username จาก Session ที่เกี่ยวข้อง) แต่ด้วยวิธีการเขียน Code นี้ (โดย Developer คนก่อนหน้า) กลับทำให้ต้องมีการปรับปรุงแก้ไขในหลายจุดเพื่อให้มันสามารถทำได้ตามที่ต้องการ หรืออาจพูดได้ว่า Code นี้ยากที่จะ Modify นอกจากผู้ที่เขียนมันขึ้นมา แสดงว่าเขาไม่ได้ใช้หลักการที่ว่า ควรเขียน Code ให้ Developer คนอื่น อ่านแล้วเข้าใจได้ง่ายเลย ไม่ว่าจะเป็น Class, Module, Function หรืออะไรก็ตาม ควรเขียนด้วยแนวคิดที่ว่า มันอาจจะมีการเปลี่ยนแปลงในอนาคตด้วย
9. Documentable
Code ที่ดีควรเป็น Documenattion ไปในตัวเลย ไม่ว่าจะเป็น ชื่อ Class, Function และ Variable อาจรวมถึง JavaDoc (หรือภาษาอื่นๆ ที่ใกล้เคียง) นอกจากนี้ยังเกี่ยวกับการออกแบบ Code ด้วย หากคุณไม่ทำ Documentation แถมยังไม่ทำในหัวข้ออื่นๆ ใน 11 ข้อนี้ด้วยแล้วละก็ อยากให้คุณลองคิดเสียใหม่และเริ่มลงมือทำมันซะ
10. Modular
Code ที่ดีควรมีการแบ่งเป็นส่วนย่อยๆ ซึ่งจะช่วยให้คุณสะดวกในการ Run หรือสามารถแก้ไขแค่บางส่วนที่คุณต้องการได้อย่างเป็นอิสระต่อกันและไม่กระทบไปยังส่วนอื่นๆ
11. Buildable
หาก Developer คนอื่นๆ ในทีมไม่สามารถเข้าถึง Code ของคุณใน Git และ run Build ที่คุณเขียนไว้ได้ คุณต้องเป็นคนเข้าไปจัดการ Build นั้น (ซึ่งคุณอาจใช้ Build Tool "ที่เป็นที่รู้จัก" อย่าง Maven หรือ Make เป็นตัวช่วย) และถ้ามันจำเป็นต้องใช้เวลา Process นานๆ คุณก็ต้องเข้าไปจัดการให้มันทำงานได้ จะว่าไปแล้ว ไม่มีเรื่องไหนที่คนในทีมต้องใช้ความพยายาม มากไปกว่าเรื่องเกี่ยวกับ Build ซึ่ง Developer ในทีมส่วนใหญ่มักต่อต้านมันเมื่อพวกเขาเพิ่งได้คอมพิวเตอร์เครื่องใหม่มาหรือกำลังอยู่ในช่วงที่ Release หรือ Hotfix
ที่มา: https://www.infoworld.com/
รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert
|
|
อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ
|
|
บทความที่เกี่ยวข้อง