โปรแกรมเมอร์ work from home
ผมกับเจนมีโอกาสได้ co-train คอร์ส LeSS in Action ของ Terry Yin ช่วง 15–19 กรกฎาคมที่ผ่านมา สิ่งที่ผมได้จากคอร์ส ผนวกกับที่กำลังโค้ชน้อง ๆ สหกิจที่กำลังจะจบการศึกษา ทำให้ผมเห็นระดับของโปรแกรมเมอร์ละเอียดขึ้น
1 เขียนโค้ดให้คอมพิวเตอร์อ่าน
น้อง ๆ นักศึกษาได้ฝึกเขียนโปรแกรมจากโจทย์ที่อาจารย์ให้ น้อง ๆ ส่วนใหญ่แก้โจทย์ต่าง ๆ ได้หมด อาจจะเร็วช้าต่างกัน แต่โดยรวมถือว่าทำได้ดี ปัญหาคือ โค้ดที่น้องเขียนมามันเอาไปแก้ต่อยากมาก น้องคุ้นชินกับการแก้โจทย์ให้สำเร็จ พอทดสอบแล้วว่ามันทำงานถูก น้องก็ส่งให้อาจารย์แล้วโค้ดนั้นก็เปลี่ยนเป็นคะแนน แล้วชาตินี้น้องก็ไม่ต้องเจอกับโค้ดนั้นอีกเลย
แต่ในชีวิตการทำงาน ผมบอกน้อง ๆ ว่า
โค้ดเราเขียนครั้งเดียว แต่เราและเพื่อน ๆ ในทีมจะต้องอ่านมันไปทั้งชีวิต — จั๊วะ
ยิ่งในองค์กรที่ cost ในการทำ regression test สูง ๆ บางทีอาจจะไม่สามารถ refactor หรือปรับปรุงมันได้อีกหลังจากมันขึ้น production ไปแล้วด้วยซ้ำ
และนี่คือโปแกรมเมอร์ level แรกสำหรับผม level ที่เขียนโค้ดให้คอมพิวเตอร์อ่านได้ แต่เพื่อนร่วมทีมอ่านยาก ใน level นี้ ทำงานคนเดียวได้ แต่จะเอาไปเสริมทีมยังทำงานด้วยยาก
2 เขียน romantic automate test
คำนิยามเรื่อง romantic เป็นสิ่งที่ผมได้จากคอร์ส LeSS in Action ถ้าอยากเข้าใจคำนี้อย่างลึกซึ้ง สามารถอ่านได้จากหนังสือ Zen and the Art of Motorcycle Maintenance แต่ในคอร์ส Terry ให้นิยามคร่าว ๆ ไว้ว่า
ถ้า user ได้อ่าน feature file ของคุณ เค้าควรจะน้ำตาไหล เพราะรู้สึกได้ว่าคุณเข้าใจความยากลำบากที่เค้ากำลังเผชิญจริง ๆ — Terry Yin
สำหรับ level 2 นี้ เป็นโปรแกรมเมอร์ที่เขียน automate test ไม่ว่าจะอยู่ในรูป unit test หรือ e2e test เพื่อถนอมความรู้เกี่ยวกับปัญหาที่ตัวเองกำลังแก้ไว้ได้ ถ้าผมทำแบบนี้ได้ ต่อให้ผมเขียนโค้ดที่เพื่อนร่วมทีมอ่านยากออกมา ก็เปิดพื้นที่ให้เพื่อนหรือตัวผมในอนาคตที่เก่งขึ้นแล้ว refactor หรือ rewrite solution ที่ผมทำมาได้
3 เขียนโค้ดให้ classic
เหมือนกับ romantic คือถ้าอยากเข้าใจนิยามคำนี้อย่างลึกซึ้ง สามารถอ่านเพิ่มเติมได้จากในหนังสือ แต่สำหรับในคอร์ส Terry เล่าว่า classic คืออยู่ยั่งยืนยงไปนาน ๆ หลายยุคสมัย ซึ่งหมายถึงการแสดงเจตนาของ design เราให้ชัด เวลาใครจะมาแก้ไขก็จะได้ต่อยอดงานเราได้ง่าย ๆ
ถ้าผมถึง level นี้ เพิ่มเติมจากการถนอมปัญหาที่ผมกำลังแก้ไว้แล้ว ผมยังถนอม design ของ solution ที่ผมเลือกมาแก้ปัญหาไว้ได้ด้วย การทำแบบนี้ คนอื่นก็จะมาต่อยอดงานผมได้ง่าย ไม่ต้องลบเขียนใหม่ตลอด
4 continuous integration
ในคอร์ส คำว่า continuous integration ไม่ใช่แค่การที่ทุกคนเขียนโค้ดบน main branch เหมือนกันเท่านั้น แต่ยังมีองค์ประกอบอื่น ๆ อีก 3 ข้อดังนี้
ต้อง push และ pull บ่อย ๆ เพราะ main branch ที่อยู่บน local ของเราก็แยกออกมาจากเพื่อน ๆ เช่นกัน เราจะได้ integrate กันก็ตอน push และ pull นี่แหละ
โค้ด frontend ที่ยังไม่ได้ call backend ก็ถือว่ายังไม่ integrate เช่นกัน เราต้องรีบเอามันมาต่อกัน ต่อกันด้วย response ที่ hardcode ไว้ก็ยังดีกว่าปล่อยให้อยู่แยกกัน
การทำ function ใหม่ขึ้นมา โดยที่ยังไม่ถูกเรียกจากส่วนอื่น ๆ ของโค้ด ก็นับว่ายังไม่ integrate เช่นกัน เหมือนการที่ frontend ไม่ได้ call backend แหละ
การแยก if else หรือ branching ในโค้ด ก็นับว่ายังไม่ integrate เช่นกัน อย่างกรณี feature toggle ก็นับว่าเป็นการ delay integration เช่นกัน
ข้อดีของการ integrate คือ ทุก ๆ ครั้งที่เรา integrate เรามักจะได้เรียนรู้อะไรใหม่ ๆ ยิ่งเรา delay integration ออกไป ก็คือการ delay การเรียนรู้ ซึ่งส่งผลให้เราทำงานช้าลงและความเสี่ยงจากการ integrate ก็จะสูงขึ้นเรื่อย ๆ เป็นเท่าทวี
โค้ดที่ไม่ได้ integrate มานาน ๆ มีโอกาสสูงที่จะเกิด code conflict ยาก ๆ ที่ผมอาจจะไม่สามารถแก้ได้ตามลำพังเพราะมีข้อมูลไม่พอ เพราะอาจจะไม่ใช่ทุกคนในทีมที่เขียน automate test ได้ romantic และเขียนโค้ดได้ classic จนผมอ่านเข้าใจเองได้ เลยต้องไปตามเพื่อน ๆ มาช่วยกันแก้ conflict เพื่อให้ทุกคนมี information ด้วยว่างานที่ผมทำเกี่ยวพันกับงานของเพื่อน ๆ อย่างไร
ถ้าผมถึง level 4 ผมจะใช้เวลาส่วนใหญ่ในการส่งมอบคุณค่าให้ user และใช้เวลาน้อย ๆ กับการ resolve code conflict เพราะ git ทำให้ได้โดยอัตโนมัติ
5 craft commit ได้
จริง ๆ แล้ว commit แต่ละ commit เหมือนการอ่านเรื่องราวว่าโค้ดโดนเปลี่ยนไปอย่างไรบ้างทีละขั้น ๆ
โปรแกรมเมอร์ที่ยังไม่ถึง level 5 มักจะสร้าง commit ใหญ่ ๆ บาง feature ที่ user ขอมามี commit เดียวก็มี ซึ่ง commit แบบนี้มันติดตามเรื่องราวยากมาก (รู้แค่จะทำ feature อะไรให้ user) ถ้าลองได้ไปดู commit ของ DHH ตอน RoR เกิดขึ้นมา จะเห็นว่า commit เค้าเล็กและอ่านง่ายมาก ไม่ต้องมีเจ้าตัวมานั่งเล่าให้ฟังก็พอตามได้ว่าเค้าคิดอะไร และพยายามจะแก้ปัญหาไปทางไหน
เมื่อคุณภาพของการสื่อสารเราดีพอ เราจะเริ่มสื่อสารแบบ asynchronously ได้ คือคุยกันผ่านตัวหนังสือเหมือนที่นักเขียนส่งต่อเรื่องราวและอารมณ์ผ่านนิยายที่เราอ่าน
ความเข้มข้นของสื่อ
ในคอร์สที่ผมสอนเรื่อง productivity ผมแบ่งปันเกร็ดเล็ก ๆ ของการสื่อสารว่าให้เลือกความเข้มข้นของสื่อให้เหมาะสมกับสารที่เราจะสื่อ สื่อความเข้มข้นต่ำ ๆ ที่ส่งได้แต่ตัวหนังสือเช่นอีเมลหรือ chat มีข้อดีคือความสะดวกสบายและราคาถูก ข้อเสียคือช่องที่มันสื่อได้นั้นจำกัด มันไม่สามารถส่งน้ำเสียง สีหน้า หรือบรรยากาศได้ สื่อที่มีความเข้มข้นสูงสุดคือการคุยกันแบบเห็นหน้า
สิ่งที่ผมมักจะแนะนำผู้เรียนในคอร์สคือ เมื่อไหร่ที่มันจะดราม่า ให้เลือกสื่อที่มีความเข้มข้นสูงเข้าไว้ เพราะธรรมชาติของมนุษย์ที่กลัวความผิดหวัง เวลาต้องเติมคำในช่องว่าง เราจะคิดเผื่อกรณีที่เลวร้ายที่สุดเอาไว้ เมื่อไหร่ที่สื่อมันเข้มข้นไม่พอ พวกน้ำเสียง สีหน้า ท่าทางที่เราจินตนาการเลยมักจะเลวร้ายกว่าความเป็นจริงเสมอ
จากประสบการณ์ที่ผมดูทีมหลากหลายมา ผมพบว่าทีมที่ประกอบด้วยโปแกรมเมอร์ level น้อย ๆ มันมีดราม่าระหว่างวันเยอะมาก ทั้ง code conflict ที่ทำให้งานฉันหาย ทั้งอ่านโค้ดเพื่อนไม่เข้าใจ ทั้งเข้าใจปัญหาที่เพื่อนกำลังแก้ไปผิดทาง ความขัดแย้งทั้งหมดนี้มันจะแก้ได้ง่ายมาก ถ้าเราลุกไปคุยกันแบบเห็นหน้าได้สะดวก
แต่เวลาทีมไม่อยู่ในสิ่งแวดล้อมที่ลุกไปคุยกันได้ง่าย ๆ ความขัดแย้งเล็ก ๆ นี้มันจะสะสมกลายเป็นรอยร้าวของความสัมพันธ์ ซึ่งแก้ยากกว่ามาก
ส่วนทีมที่ level ถึง ชีวิตการทำงานของพวกเค้าช่างราบรื่น ไม่เห็นความแกว่งของอารมณ์
ที่ผมเลือกเรื่องนี้มาแบ่งปันเพราะทางเลือกที่จะ work from home เป็นอำนาจที่ยิ่งใหญ่ เปิดโอกาสให้เรามีอิสระมากมายในการออกแบบไลฟ์สไตล์ของเรา แต่มันก็มากับความรับผิดชอบที่ใหญ่ยิ่งที่เราต้องฝึกคุณภาพของสารที่เราจะสื่อผ่าน automate test, ผ่านโค้ด, ผ่าน commit message เพื่อชดเชยคุณภาพของสื่อที่ถูกลดทอนจากการคุยกันออนไลน์ เพราะถ้าเราไม่ทำ นอกจากตัวเราจะต้องจ่ายความหงุดหงิดกับการสื่อสารที่ขาดหายไปแล้ว เพื่อนร่วมทีม รวมถึงทั้งองค์กรก็ต้องจ่ายเหมือนกัน อำนาจที่ขาดสมดุลของความรับผิดชอบนั้นผิดธรรมชาติ และสิ่งที่ขัดกับธรรมชาติจะไม่ยั่งยืน
