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

เชื่อว่า Programmer/Developer โดยทั่วไปมักทำงานกันเป็นทีม ซึ่งเมื่อทำงานร่วมกันหลายคนย่อมต้องมีการกำหนดรูปแบบการเขียน Code ร่วมกัน บางครั้งหลังตกลงกันแล้วก็ได้ข้อสรุปที่ส่วนใหญ่พอใจ บางครั้งข้อตกลงก็ไม่ลงตัว ดังนั้นเพื่อลดปัญหาเหล่านี้ เรามาดูกันว่า วิธีเลือกข้อตกลงเกี่ยวกับการเขียน Code ที่ดีที่สุด มีอะไรบ้าง

ทำไมเราถึงต้องกำหนดข้อตกลง?

อันที่จริงมีหลายเหตุผลที่ว่า ทำไมเราถึงต้องมีข้อตกลงร่วมกัน แต่สำหรับการเขียน Code เราจะมุ่งเน้นไปที่เรื่องสำคัญหลักๆ ก็คือ เรื่อง Readability หรือ ความสามารถในการอ่าน Code นั่นเอง

ลองนึกดูเล่นๆ ว่า จะเป็นอย่างไร ถ้าใครคนหนึ่งในทีมอยากจะเขียน Code โดยใช้อักษรภาษาอังกฤษที่เป็น “ตัวพิมพ์ใหญ่” ทั้งหมดใน Code ก็คงมี Programmer หรือ Developer หลายคนที่คิดว่า มันดูแปลกๆ จริงไหม

คราวนี้ลองมาดูตัวอย่างง่ายๆ กันต่อ ลองคิดต่อถึงการตั้งชื่อตัวแปร หรือการจัดย่อหน้า/จัดระเบียบ Code ที่เขียนดู ถ้าทุกครั้งที่คุณกลับไปดู Code ที่เขียนไว้ แล้วพบว่า มันถูกเขียนแตกต่างกันไปทุกครั้ง มันทำให้เหมือนคุณต้องกลับไปเริ่มต้นอทำความเข้าใจใหม่ทุกครั้ง แต่หากคุณเขียน Code โดยใช้ข้อตกลงที่ได้จากการพูดคุยกันในทีมนั้น มันน่าจะง่ายต่อการทำความเข้าใจและต่อการอ่านมากกว่า แม้ว่าเขียมาแล้วหลายเดือนก็ตาม

สิ่งนี้มีความสำคัญยิ่งขึ้น เมื่อต้องทำงานกับทีม Developer ซึ่งแต่ละคนก็จะเขียน Code ในรูปแบบที่ตัวเองชอบหรือถนัด ทำให้ระยะเวลาที่ใช้ในการทำความเข้าใจและตรวจสอบ Code ของกันและกันจะใช้เวลานานมากขึ้น ดังนั้น เพื่อให้เกิดความร่วมมือกันระหว่าง Developer อย่างมีประสิทธิภาพและมีคุณภาพ คุณจำเป็นต้องมีข้อตกลงร่วมกัน

วิธีเลือกข้อตกลงเกี่ยวกับการเขียน Code ที่ดีที่สุด

ไม่ว่าคุณจะเพิ่งเริ่มเขียน Code หรือคุณเป็นส่วนหนึ่งของทีม Dev หรือหากคุณเพิ่งได้เป็น CTO ก็ตาม คุณจะเลือกข้อตกลงเกี่ยวกับการเขียน Code ที่ดีที่สุด ได้อย่างไร      ลองมาดูแนวทางเหล่านี้กัน            :

1. ทำตามแนวทางของทีม Dev ที่คุณชื่นชม:

ไม่มีอะไรที่สู้ประสบการณ์ได้ มีบริษัทที่มีขนาดใหญ่และมีชื่อเสียงบางแห่งที่เผยแพร่แนวทางการเขียน Code ของพวกเขา ตัวอย่างเช่น Airbnb เผยแพร่ Style Guides เกี่ยวกับ JavaScript และ Ruby ​​ของพวกเขาและ Google เผยแพร่ Style Guides เกี่ยวกับ Java และ Python ด้วยเช่นกัน ไม่ว่าคุณจะชอบบริษัทเหล่านี้หรือไม่ ถ้าคุณได้รวบรวมและสรุปสิ่งที่ได้จากประสบการณ์ที่ยาวนานของ Developer แต่ละคนเชื่อว่า มันคงมีมากมายมหาศาล ลองนำ Style Guides ของบริษัทเหล่านี้มาใช้กับทีมของคุณดูสิ

2. รวบรวมความรู้จากเพื่อนร่วมงานของคุณ:

โชคดีที่ปัจจุบันพวกเรามี Community ต่างๆ ที่เกิดขึ้นมากมาย หนึ่งในประโยชน์ข้อหลักๆ ของการเป็น Developer ในปัจจุบัน คือ Community ของคนไอทีนั่นเอง ไม่ว่าจะเป็น Slack, Spectrum, Discord หรือCollab Platform อื่นๆ ก็ตาม คุณสามารถค้นหา Group ที่มีความรู้ต่างๆ เพื่อโพสต์คำถามเกี่ยวกับการจัดการ Code และรับคำตอบจาก Developer ทั่วโลกได้ทันที

3. ไม่ใช้ตัวอย่าง Code:

ใช่แล้ว! ถ้าไม่จำเป็นก็อย่าใช้พวกมัน คงมีหลายคนที่พอติดขัดนึกไม่ออกก็จะเข้าไป Copy/Paste Code ที่ได้จาก Stackoverflow หรือจากแหล่งอื่นๆ ก็ตาม สิ่งที่ผู้คนมักจะหลงลืมไปก็คือ ตัวอย่าง Code ที่เพิ่ง Copy มา อาจถูกเขียนเป็นคำตอบของคำถามที่เป็น Technical หรือเป็นคำอธิบายสำหรับบาง Library ซึ่งบ่อยครั้งที่ผู้เขียนอาจไม่ได้ตั้งใจและไม่มีเวลาจัดการกับข้อตกลงเกี่ยวกับ Code

เคล็ดลับเหล่านี้จะช่วยคุณใช้เป็นจุดเริ่มต้นและวางรากฐานสำหรับการแนะนำข้อตกลงเกี่ยวกับการเขียน Code สำหรับทีม Dev ของคุณ

แล้ว ข้อตกลงที่ดีที่สุด มีอยู่จริงไหม

ขึ้นอยู่กับว่า คำว่า "ดีที่สุด" หมายถึงอะไร อย่างของ Airbnb หรือ Google ก็จะใช้ข้อตกลงที่ชัดเจนแน่นอนของพวกเขา หรือหากมี  CTO 10 คนต่างบอกว่า ข้อตกลงของพวกเขาดีที่สุด นั่นหมายถึงว่า มันเป็นข้อตกลงที่ดีที่สุดสำหรับคุณหรือไม่ นอกจากนี้ข้อตกลงก็อาจมีการเปลี่ยนแปลงได้ บางสิ่งที่ถูกเปลี่ยนไปตามกาลเวลา จะสามารถเรียกว่า "ดีที่สุด" ได้หรือไม่

ตอนที่ Ofer Vugman (ผู้เขียนบทความนี้) ได้เริ่มงานเป็น Front-end Developerที่ Lemonade เขาพบว่า มันยากที่จะอ่าน Code ที่ Developer คนก่อนหน้าเขียนไว้ มันอาจเป็นข้อตกลงที่ดีที่สุดสำหรับทีม แต่มันกลับไม่ใช่เลยสำหรับ Ofer ดังนั้น เขาจึงเขียน Code ที่เขาต้องใช้ใหม่ทั้งหมดตามแนวทางของเขา และเมื่อเวลาผ่านไป Developer เข้าร่วมทีมมากขึ้น ก็ทำให้ข้อตกลงต่างๆ ปรับเปลี่ยนไปมากขึ้นตามไปด้วย

Developer แต่ละคนมี Background ที่แตกต่างกัน ทำให้มีแนวทางการเขียน Code แตกต่างกันไปด้วย ดังนั้น เพื่อทำให้เกิดข้อตกลงร่วมกันของทีม จึงได้มีการใช้ JavaScript Style Guide ของ Airbnb เป็นจุดเริ่มต้น ทีมงานได้ตรวจสอบข้อตกลงของ Code ใน Guide นั้น แล้วทำการปรับเปลี่ยนหรือลบสิ่งที่ทีมไม่เห็นด้วยและนำสิ่งที่ทีมงานชอบใส่เข้าไป นอกจากนี้ยังนำข้อตกลงที่ได้จากประสบการณ์ของ Developer มา Integrate เข้ากับข้อตกลงหลักของทีมอีกด้วย

กระบวนการในการประเมินผลว่า แต่ละข้อตกลงที่ทีมตัดสินใจว่า ควรนำมันมาใช้ดีหรือไม่นั้น ไม่เพียงแต่ช่วยปรับปรุงในเรื่อง ความสามารถในการอ่าน Code เท่านั้น แต่ยังช่วยพัฒนาการทำงานเป็นทีมอีกด้วย

นี่คือความจริง: ไม่มีคำนิยามสำหรับข้อตกลงที่ดีที่สุดหรอก เพราะ มันไม่มีอยู่จริง

มันตรงกันข้ามกับสิ่งที่คุณถูกสอนมาจากโรงเรียน คือ ไม่มีคำตอบไหน ที่สามารถเป็นคำตอบที่ถูกต้องสำหรับทุกคำถามหรอก ซึ่งในกรณีนี้ อาจมีคำตอบอยู่มากมาย

Developer แต่ละคนล้วนมีแนวทางในการ Implement ที่แตกต่างกันไป บางคนชอบตั้งชื่อ Class ที่ขึ้นต้นด้วย ‘m_’ บางคนก็ชอบใช้การเว้นวรรค 2 ครั้ง บางอันก็ชอบใช้การ Tab บางคนอาจบอกว่าการใช้คำว่า Utils ในชื่อ Class นั้นผิด นี่คือการสนทนาที่ไม่มีจุดสิ้นสุด แต่ความชื่นชอบเหล่านี้ล้วนมาพร้อมกับเหตุผลที่ดี

ไม่ว่าจะอย่างไร สุดท้ายแล้วข้อตกลงนั้น ควรจะช่วยปรับปรุงในเรื่อง ความสามารถในการอ่าน Code (Code Readability) ให้ดีขึ้น ซึ่งควรเป็นสิ่งที่ทำให้ทีมของคุณสื่อสารได้ดีขึ้น สามารถก้าวไปข้างหน้าได้เร็วขึ้น และมีประสิทธิภาพมากยิ่งขึ้นนั่นเอง

ที่มา:  https://medium.freecodecamp.org/