“เลิก” ว่าโค้ดคนอื่นว่าห่วยแตกกันเถอะ

Sakul Montha
3 min readOct 24, 2019

--

สวัสดีสิงห์นักอ่านทุกท่านครับ จั่วหัวมาซะแรงขนาดนี้ อันที่จริงข้างในไม่ได้โหดร้ายทารุณขนาดนั้นนะครับ มาเริ่มกันเลยดีกว่า

ผมเชื่อว่าหลายคนคง “เคย” ถูกต่อว่า หรือ ว่าคนอื่น ว่า โค้ดห่วย, ทำไมเขียนแบบนี้ (น้ำเสียงดุ ๆ), เขียนอะไรมาวะ, ทำแบบนี้จะเทสยังไง, นี่เอามือเขียนรึเปล่า, ถ้าให้ฉันเขียนไม่เป็นแบบนี้แน่ ๆ, ไปทำมาใหม่ ไม่ approve, คนเก่าทำทิ้งไว้อ่านไม่รู้เรื่องเลย ทำใหม่ดีกว่า บลา ๆ ๆ ใช่ไหมครับ ที่จริงมันจะมีคำพูดที่สรรหามาต่อว่าโค้ดเก่า ๆ หรือโค้ดสด ๆ ที่ไม่ถูกใจเราได้เจ็บกว่านี้ เอาเป็นว่า ไม่เป็นไรครับ…

ตัวผู้เขียนเองก็เคยโดนตอนยังเด็กครับ ที่จริงตอนโตก็ยังมีโดนนะ ฮ่า ๆ เคยเป็นฝั่งโดนว่าว่าเขียนอะไรมาเนี่ย แล้วก็ฝั่งว่าเขาทำไมเขียนแบบนี้ แล้วก็เคยเจอแบบว่า Method เดียว 100 บรรทัด Class เดียว 1,000 บรรทัด อะไรงี้ ไม่มีเทสใด ๆ ใช้ใจล้วน ๆ เราก็ได้แต่บ่น ๆ ๆ เพราะคนทำไม่อยู่แล้ว อะไรก็ว่ากันไป

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

มันจะดีกว่ามั้ย ถ้าหากตอนที่เรา “Review code” เราเปลี่ยนจากคำดุ คำต่อว่า หรือถากถาง เปลี่ยนเป็น การให้ Feedback แบบ “Positive Feedback

เพราะสิ่งที่เสียไปแล้ว นำกลับมาไม่ได้คือ ความรู้สึก

Feedback

คำว่า “Feedback” ผมเชื่อว่าหลายท่านคงจะเคยพบเห็นกันมาแล้ว การให้ Feedback นั้นก็มีอยู่ด้วยกันหลายอย่าง อย่างที่กล่าวไปข้างต้นนั้นก็ถือเป็นการให้ Feedback อย่างนึง แต่ความรู้สึกมันจะออกมาเป็น Negative เสียมากกว่า…

Feedback คำง่าย ๆ แต่ความหมายสุดลึกล้ำ

การให้ Feedback มีอยู่ด้วยกันหลายแบบ วันนี้ผมจะพาท่านไปรู้จักกับ การให้ Feedback ด้วยเทคนิคแบบ BOFF

BOFF

BOFF มาจาก Behavior, Outcome, Feelings และ Future อันที่จริงในหมู่ Leadership และ/หรือ Manager ต่างก็มักจะได้ร่ำเรียน และ เทรนในเรื่องนี้มา ซึ่ง BOFF จะสามารถให้ Feedback ได้ทั้ง “Positive Feedback” และ “Constructive Feedback” ที่จริงผมว่ามันเหมาะกับทุกคนเลยหละครับ

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

BOFF // image by iamgique

Behavior

เริ่มต้นด้วยการอธิบายตัวอย่าง หรือ รูปแบบของพฤติกรรมที่คุณมองเห็น อย่าลืมว่า ให้มันยึดติดกับข้อเท็จจริงด้วยหละ

Outcome

อธิบายผลลัพท์ของพฤติกรรมนั้น ๆ ให้กับคนฟัง

Feelings

แสดงถึงความรู้สึกของคุณ ทั้งในแง่บวก หรือ ลบ เกี่ยวกับปัญหานั้น ๆ

Future

ขั้นตอนสุดท้ายคือ ขอให้ผู้ที่รับฟัง เปลี่ยนพฤติกรรมนั้น ๆ ของพวกเขา

Tips: ใช้พฤติกรรม เป็นจุดยึดสำหรับสิ่งที่คุณต้องการพูดคุย จากนั้นเลือก และ ผสมจากผลลัพธ์ ความรู้สึก หรือ อนาคตตามความเหมาะสม

รู้จัก BOFF กันไปแล้ว เราลองมาจำลองเหตุการณ์กันครับ สมมติว่า มีงานอยู่งานนึง ที่ นาย Meow ได้รับมอบหมายให้เขียนโปรแกรม ที่มี Array 26 ช่อง ใน Array เก็บตัวอักษร A – Z เอาไว้แบบเรียงกันหมด ซึ่งเป็นโปรแกรมที่มีอยู่แล้ว แต่ต้องการให้ นาย Meow เพิ่ม Function ในการค้นหา ตัวอักษรใด ๆ หนึ่งตัวใน Array นั้น

นาย Meow ก็รับคำสั่ง แล้วทำมาจนเสร็จ แต่นาย Meow ทำมาด้วยการ ใช้ For loop แบบ ที่ผลลัพธ์ออกมาเป็น O(n) โดยที่จริงแล้ว อักษร A-Z นั้นเรียงกันอยู่แล้ว การจะทำ Performance ที่ดีกว่านั้นคือการทำให้เป็น O(1) แต่อาจจะด้วยความที่นาย Meow อาจจะน้อยประสบการณ์ หรือ คิดเผื่อท่าพิสดาร ก็ไม่ทราบได้ จึงทำให้ออกมาในรูปแบบ O(n)

สิ่งที่เกิดขึ้นก็คือ นาย Meow อาจจะถูกพี่ในทีมต่อว่า หรือ มีคำถามที่ถากถาง อาจจะถูกถามว่าทำไมทำแบบนี้ ทำแบบนี้มันไม่ดี ทำแบบนี้มันแย่ บลา ๆ แล้วก็ไม่บอกด้วยว่าที่ดีควรทำยังไง ทำให้นาย Meow รู้สึกไม่ดี หรือ อะไรก็ตามแต่ แล้วแต่ผู้อ่านจะรังสรรค์… (ตัวอย่างมันอาจจะแบบเด็กน้อยไปนิดนะครับ แต่เพื่อให้เกิดความเข้าใจอย่างง่ายละกันเนอะ)

มันอาจจะดีกว่าก็ได้นะครับ ถ้าเราเปลี่ยนจาก คำต่อว่า บลา ๆ มาเป็นการให้ Feedback ที่ดี ไม่ทำให้ผู้ร่วมงานของเราเสียความรู้สึกด้วย
เราอาจจะลองเริ่มต้นจาก …

Behavior: พี่เห็นโค้ดที่ Meow เขียนมาแล้วนะ Meow ทำมาได้ไวมาก

Outcome: ผลลัพธ์ที่ได้ ไม่มีผิดเพี้ยนเลย แถมมีเทสมาให้พี่ด้วย

Feelings: พี่ชอบความตั้งใจกับ ความขยันของเรานะ แต่พี่ว่า มันน่าจะยังเขียนได้ Performance ที่ดีกว่านี้ได้อีกนะ

Future: เราลองคิดดูสิ ตัวโปรแกรมมันเรียง A-Z มาให้แล้วนะ ที่จริง เราไม่จำเป็นต้องวนหาแล้ว เราสามารถค้นหาได้ทันทีเลย ผลลัพธ์ที่ได้จะออกมาในรูปแบบ O(1) เลยนะ ซึ่งมันจะเร็วมาก ตอนนี้ Meow อาจจะยังไม่เห็นผล แต่ถ้าข้อมูลมันมีปริมาณมากมายมหาศาล มันจะมีผลมากมายเลยหละ

อ่านมาถึงตรงนี้ ท่านผู้อ่านพอจะเห็นภาพความแตกต่างของความรู้สึกของ Meow แล้วใช่ไหมครับ ผมว่าความรู้สึกมันต่างกันมาก แทนที่เราจะมัวมาต่อว่า มาถากถางกัน มาช่วยกัยทำให้ผู้อื่นรู้สึกดีที่ได้รับ Feedback กันเถอะครับ

ลองดูอีกสักตัวอย่างนึง นาย Bay เขียนโปรแกรมขึ้นมาใช้งาน โดยที่โปรแกรมก็รันได้อย่างปกติสุขดีบน Production วันนึงเจ้านายรับ นาย Bew เข้ามา นาย Bew มาเห็นโค้ดที่นาย Bay เขียน แล้วก็บ่นนาย Bay ว่าเขียนโปรแกรม ทำไมไม่เขียนเทส ถ้าเกิดมีการแก้ไขโปรแกรม ถ้าหากมี Issue ขึ้นมาแล้วแก้ไขไป จะรู้ได้ไงว่าของเดิมมันผิดพลาด เขียนแบบนี้ได้ยังไง ความรู้สึกของนาย Bay ที่มีต่อนาย Bew คือแบบเสียไปแล้ว แทนที่จะอยากรับฟัง อาจจะทำให้เกิดอาการต่อต้านขึ้นได้…

จนกระทั่งวันนึงมี Issue บน Production ซึ่งนาย Bay กับนาย Bew ก็เป็นคนแก้ขึ้นไป แต่กว่าจะได้นำ โค้ดชุดใหม่ขึ้นไปบน Production นั้นก็จำเป็นต้องใช้เวลานาน เนื่องจากต้องมีการทดสอบระบบกันใหม่ นาย Bew ก็พูดขึ้นมาอีกว่า เห็นมั้ย บอกแล้วให้เขียนเทส จะได้ไม่ต้องมานั่งเทสกันใหม่แบบนี้… ถ้าหากนาย Bew ลองใช้วิธี BOFF ด้วยการบอกนาย Bay ว่า

Bew (Behavior): เรามีปัญหากันบน Production ซึ่งเราใช้เวลาในการ Investigate กันนาน และเราก็ไม่มั่นใจด้วยว่าที่แก้ไปนั้น มันกระทบกับส่วนอื่นไหม

Bew (Outcome): เราจะรู้ได้ยังไงถ้าเกิดว่า เรามีการแก้ไขโปรแกรม แล้วโปรแกรมส่วนอื่นที่ทำงานอยู่ด้วยนั้น มันจะยังใช้งานได้ เราอาจจะต้องใช้คนเข้ามาทดสอบระบบเราใหม่ทั้งหมด ซึ่งมันทำให้เสียเวลาอย่างมาก

Bew (Feelings): เราว่ามันไม่ค่อยโอเคอะ ถ้าหากเวลาที่เราจะแก้แค่บางอย่าง แต่มันต้องมานั่งกังวลว่า แล้วส่วนอื่นมันจะยังทำงานได้ถูกต้องไหม เสียทั้งเวลาคนเดฟ และ คนเทส

Bew (Future): เราคิดว่าถ้าหากครั้งหน้า มีการปรับปรุง แก้ไขโค้ดส่วนไหน พวกเราควรจะเขียน เทสเพิ่มเข้าไปในส่วนนั้น ๆ เพื่อให้มั่นใจได้ว่า ที่จะกลับมาแก้อีกครั้ง มันจะยังทำงานได้อย่างถูกต้อง แล้วก็ถ้าเกิดเราพอจะมีเวลา ก็ค่อย ๆ ทยอยช่วยกันเขียนเทสให้มากขึ้นเพื่อ Increase productivity และ Quality ของโปรดักของเรา

Conclusion

จะเห็นได้ว่า เราไม่จำเป็นต้องให้ Negative Feedback นอกจากมันจะทำให้คนฟังรู้สึกต่อต้านแล้ว มันมักจะไม่ค่อยเกิดสิ่งที่ดีอีกด้วย

การให้ Feedback มันไม่จำเป็นต้องพูดถึงการ พัฒนาซอฟแวร์อย่างเดียวนะครับ มันเป็นอะไรที่ Common สุด ๆ เอาไปใช้ในชีวิตประจำวัน ไม่ว่าจะกับคนรอบตัว กับงาน กับญาติพี่น้อง หรืออื่น ๆ ทั้งนี้ จะให้มันมีประสิทธิภาพนั้น เราก็ต้องมั่นตรวจสอบตัวเองอยู่เสมอด้วยนะครับ รู้เท่าทันตนเอง งานใหญ่จะได้ไม่เสีย อย่างไรก็ดี บางทีการทำอะไรแบบนี้ มันก็อาจจะใช้ไม่ได้กับคนทุกหมู่เหล่านะครับ อันนี้ก็ขึ้นกับผู้รับด้วยเหมือนกัน… Feedback is a gift และ อย่างที่ได้บอกไปครับ

เพราะสิ่งที่เสียไปแล้ว นำกลับมาไม่ได้คือ ความรู้สึก

--

--

Sakul Montha

Chief Product Officer, a man who’s falling in love with the galaxy.