Dev หัดเดิน @ Wongnai
ประสบการณ์เรียน Com Sci 1 ปีของคุณจะเท่ากับคนที่เรียนมา 4 ปีได้ยังไง — Anonymous (2018)
เป็นคำถามคล้ายคำสบประมาทที่เจอตอนสัมภาษณ์งานกับบริษัทแห่งหนึ่ง คล้ายเย้ยหยันว่าจะเป็น dev ได้ยังไง
เป็นคำถามที่ไม่มีคำตอบ เพราะคงมีแค่เวลาเท่านั้นที่จะช่วยพิสูจน์
หลังจากตัดสินใจใช้เวลา 1 ปีชุบตัวเรียนป.โท Com Sci (Computer Science) ทั้งที่ไม่ได้จบสายนี้มาโดยตรง ก็ตั้งใจไว้แล้วว่าจะต้องเป็น dev (Software developer) ให้ได้ ช่วงใกล้เรียนจบจึงยื่นใบสมัครและได้ offer จาก Wongnai ทำให้มีโอกาสได้ทำงานในฐานะ dev อย่างจริงๆ จังๆ
ก่อนเริ่มงาน
ความรู้ที่มีส่วนใหญ่เป็นความรู้พื้นฐาน เช่น
- Object-Oriented Programming
- Computer Architecture
- Operating Systems
- Algorithm & Data structure
- Database
- Git แบบใช้งานคนเดียว คือมีอยู่ branch เดียว หรือแม้จะเคยใช้ทำงานร่วมกับทีม แต่ก็พยายามเลี่ยง conflict กันตลอด
นอกจากนี้ ก็มีประสบการณ์ทำ Software project ซึ่งมีทั้งทำคนเดียวและทำเป็นทีม แต่ไม่ได้ให้ความสำคัญกับการออกแบบระบบเท่าไหร่ เพราะรองรับการใช้งาน user น้อยมาก ซึ่งก็คือตอนที่ต้อง demo และยังเป็น project ที่ไม่ต้อง maintain เพราะมีเป้าหมายสำคัญ คือ ทำ project ให้จบ หลังจากนั้นก็อีกเรื่อง 😆
ช่วงแรกที่ Wongnai
ความรู้ที่มีแม้จะใช้งานได้จริง แต่ก็ยังเป็นเสี้ยวเล็กๆ ของการทำงาน ทำให้ช่วงแรกที่ Wongnai เป็นช่วงที่ต้องเรียนรู้เยอะและหลากหลายมาก
เจอของใหม่เต็มไปหมด ไม่ว่าจะเป็น Spring Framework, Hibernate, Kubernetes และอะไรก็ไม่รู้อีกเยอะๆๆๆ ยอมรับว่างงกับทุกอย่าง โชคดีที่มีทีมที่ดีคอยช่วยเหลือตลอด ติดอะไรถามได้ตลอด และมี doc สำหรับ new joiner ให้ทำตามได้
ตอนนั้นยังมองไม่เห็นความเชื่อมโยงระหว่างแต่ละส่วน แต่พอทำไป งงไปเรื่อยๆ ก็จะค่อยๆ มองเห็นภาพว่า แต่ละส่วนมีหน้าที่อะไรยังไง เชื่อมโยงกับส่วนอื่นๆ ยังไง
Coding Dojo
ช่วงนั้น ทีม backend ยังเล็ก ก่อนเที่ยงทุกวัน เราจะมี Coding Dojo ซึ่ง backend ทุกคนจะมานั่งรวมกันแล้วเลือกงานของใครคนนึงมา คนนึงเขียนโค้ด คนที่เหลือดู ซึ่งเป็นเวลาที่ทุกคนจะได้แชร์ความรู้ระหว่างกัน เช่น ถ้าคนใหม่เป็นคนเขียน คนที่ดูก็จะช่วยแนะได้ว่าควรทำยังไง หรือถ้าคนที่มีประสบการณ์เขียน คนที่ดูอยู่ก็จะได้เรียนรู้เทคนิคใหม่ๆ ไปใช้ด้วย
เป็นช่วงเวลาที่ได้เรียนรู้เยอะมากๆ เช่น การทำ TDD (Test-driven development) การใช้ shortcut ทำให้ทำงานได้เร็วขึ้น (เพราะไม่ต้องสลับไปใช้ mouse) รู้จัก Wongnai Framework ที่ช่วยให้ทำงานง่ายขึ้น รวมถึงวิธีการไล่โค้ด ต้องเริ่มจากจุดไหนยังไง ความสำคัญของการตั้งชื่อตัวแปรให้เข้าใจง่าย เป็นต้น
หลังๆ มาทีม backend ใหญ่ขึ้นและกระจายกันไปอยู่ตาม squad ต่างๆ Coding Dojo ในแบบเดิมที่ทุกคนมานั่งรวมกันก็หายไปแล้ว แต่จะแบ่งให้ squad ต่างๆ จัดการกันเองอยู่
Feature แรกที่ Wongnai
หลังจากที่ทำงานมาสักระยะนึง ก็ได้แตะ feature หลายๆ อย่าง แต่ feature ที่จำได้ไม่ลืมคือ feature แรกที่ถึงแม้จะธรรมดา แต่ก็อยากเปิด app โชว์ใครต่อใครไปทั่ว เป็น feature ที่ทำให้ user รู้ว่า ร้านอาหารแต่ละร้านอยู่ห่างจากสถานีรถไฟฟ้า/สถานีรถไฟใต้ดินมากน้อยขนาดไหน ซึ่งเป็นปัจจัยหนึ่งที่ทำให้ user ตัดสินใจได้ว่าจะไปหรือไม่ไปร้านนั้นๆ ดี
ทาง Wongnai มีข้อมูลอย่างตำแหน่งร้านอาหารหรือตำแหน่งสถานีต่างๆ อยู่แล้ว ดังนั้น งานนี้หลักๆ คือการ precompute ว่า มีสถานีไหนบ้างที่ใกล้กับร้านอาหาร ส่วนการคำนวณระยะทางนั้น เราคำนวณตอนแสดงผลออกไป
หลังจากที่ implement ทุกอย่างเสร็จเรียบร้อยแล้ว โค้ดใช้งานได้แล้วบน test environment กำลังจะ merge feature แต่ก็ติดปัญหาเรื่อง Git เพราะตอนนั้นน่าจะแตก branch แบบมั่วๆ มา เละมากๆ 5555 เลยขอให้ทีมมาช่วย สุดท้ายก็ deploy ขึ้น production เรียบร้อย
หลังจาก deploy เรียบร้อยแล้ว ก็กดปุ่ม precompute ข้อมูล กดเสร็จก็ไปทำอย่างอื่น ไม่ได้คิดอะไรมาก เพราะ test มาแล้ว ผ่านไปอีกแป๊บ server ร่วง ตอนนั้น คือ งง รู้สึกว่า เอ๊ะ เราทำหรอ ยังไม่ได้ทำอะไรเลยนะ แค่กดปุ่มเอง 55555555 หลังจากนั้น ก็มี senior เข้ามาช่วยซ่อม server และแนะนำวิธีแก้ไขที่ควรจะเป็นให้ หลังจากที่แก้เรียบร้อยแล้ว ก็กด precompute อีกรอบ…เป็นอันใช้ได้
ฟู่…ในที่สุด…user ก็ได้ใช้งานซะที 😆
Code Review
ก่อนที่ทุกๆ feature จะปล่อยออกไป dev จะต้องเปิด MR (merge request) และต้องมี dev คนอื่นๆ อย่างน้อย 2 คนมารีวิวและ approveโค้ดชุดนั้น จึงจะสามารถปล่อย feature นั้นๆ ออกไปได้
ตอนแรกๆ ไม่กล้ารีวิวโค้ด เพราะอ่านโค้ดไม่ค่อยเข้าใจ ไม่กล้ารีวิว กลัวความรู้เราไม่มากพอที่จะ approve แต่ที่ Wongnai จะมี 1–1 (one-on-one session) ทุกเดือน ซึ่งเราจะได้รับ feedback ว่ามีส่วนไหนที่เราควรปรับปรุงหรือมีอะไรบ้างที่เราต้องการความช่วยเหลือ ตอนนั้นก็ได้คุยกับ senior เรื่องนี้ และเปลี่ยนความคิดที่มีในเรื่องนี้ไป
กล้ารีวิวโค้ดมากขึ้น มองว่า การรีวิวโค้ดเป็นการแชร์ความรู้กันและเป็นการคุยกันว่าเราสามารถพัฒนาโค้ดชุดนี้ได้ยังไงบ้าง เป็นการพัฒนาให้ code base ของเราดีขึ้นไม่มากก็น้อย ไม่ว่าจะเป็นการดูว่าโค้ดอ่านง่ายมั้ย หรือมี typo ตรงไหนรึป่าว ซึ่งมือใหม่อย่างเราก็ทำได้ไม่ยากเลย รวมถึง ถ้าโค้ดดีแล้วในความคิดของเรา ก็สามารถ approve ได้เลย
พอเรามีประสบการณ์มากขึ้น ถ้าเรายังยึดหลักการเดิมอยู่เหมือนตอนเริ่มงานใหม่ น่าจะไม่โอเคแล้ว ถ้าเรายังมองหาแต่ typo ดูแค่ว่าโค้ดอ่านง่ายมั้ย เราก็จะไม่พัฒนา หลังจากนั้น จึงพยายามทำความเข้าใจโค้ดมากขึ้น ทำไมมันต้องเป็นแบบนั้น ทำไมไม่เป็นแบบนี้ หรือพอเจออะไรใหม่ๆ ที่ไม่เคยรู้มาก่อน ก็พยายามหาว่ามันคืออะไร แทนที่จะจมอยู่กับความไม่รู้ต่อไป
แต่ก็ยังมีนิสัยเสียๆ อยู่ คือ ชอบไปดูโค้ดก่อนจะดูจุดประสงค์ของ task ซะอีก ประมาณว่า ดูโค้ดแล้วก็ เอ๊ะ นี่จะทำอะไรนะ แล้วค่อยกลับไปอ่าน description ว่า task นี้ทำเกี่ยวกับอะไร
แนวทางต่อไปในการรีวิวโค้ดน่าจะเป็น การเข้าใจเป้าหมายของ task ก่อนจะอ่านโค้ด คิดว่า ถ้าเป็นเราจะ implement แบบไหน คนที่ทำ feature นี้เค้าทำยังไง ทำเหมือนเรารึป่าว ถ้าทำไม่เหมือนกัน จุดไหนที่ทำให้เราคิดไม่เหมือนกัน เป็นต้น
WeHack & Backend Sharing
WeHack & Backend Sharing เป็นช่วงเวลาที่เปิดโอกาสให้คนในทีมแชร์ความรู้ให้คนอื่นๆ ในทีมฟัง โชคดีที่มีโอกาสได้แชร์ความรู้ให้ทีมฟังอยู่บ้างเหมือนกัน ซึ่งเป็นโอกาสที่ดีในการฝึกเรียบเรียงความคิด การลำดับการเล่าเรื่อง และหาวิธีอธิบายให้คนอื่นเข้าใจได้ง่ายที่สุด
ตัวอย่างที่ตั้งใจนำเสนอแบบแบบสุดๆ คือ หยิบเรื่อง LRU (Least Recently Used) Cache ไปเทียบกับตู้เสื้อผ้า ตอนพูด ยังนึกเขินๆ อยู่ในใจ (ว่าพูดเรื่องอะไรอยู่กันแน่ 😆)
อีกอย่างนึงที่เป็นประโยชน์ของการแชร์ คือ การที่จะอธิบายอะไรสักอย่างนึงออกไปได้ เราต้องมีความเข้าใจในเรื่องๆ นั้นอยู่ระดับนึง ดังนั้น อะไรที่เคยใช้งานอยู่แต่ยังไม่เข้าใจ ก็ได้มาทำความเข้าใจตอนที่เตรียม presentation นี่แหละ 😆
WeRich (Wongnai Dev Club)
ที่ Wongnai จะมีสิ่งที่เรียกว่า 90/10 ซึ่งให้ dev ใช้เวลา 10% ของการทำงานในการเรียนรู้อะไรก็ได้ มีอยู่ครั้งนึงที่ Dev manager อยากลองให้เรียนรู้ในรูปแบบของชมรม ตอนนั้น อยากเข้าใจ React เลยตั้งชมรม WeRich ขึ้นมาเพื่อใช้ React สร้าง web application สำหรับจำลองการซื้อขายหุ้น
เป็นช่วงที่สนุกดี ตอนนั้นรู้สึกเหมือนกำลังจะตั้ง startup อะไรแบบนั้นเลย เริ่มตั้งแต่ brainstorm กับทีมว่าจะทำ features อะไร (เขียน idea แบบไม่ตัดสินให้เยอะๆ เข้าไว้แล้วค่อยมาเลือก) คุยกันว่าจะใช้ tech stack อะไรบ้าง แบ่งงานออกเป็นส่วนๆ ใครรับผิดชอบอะไร และเข้าใจบทบาทของ Project manager ในทีมมากขึ้น เพราะต้องมีคนที่ช่วยมองภาพรวมอยู่ตลอด รู้ว่าทำอะไรไปแล้ว กำลังทำอะไรอยู่และควรทำอะไรต่อไป
หลังจากผ่านไปประมาณนึง Dev manager ก็มาบอก เดี๋ยวมี presentation นะ ให้มาเล่าว่าทำอะไรกันไปบ้างหรือจะ demo โชว์ผลงานก็ได้ จากตอนแรกที่ทำกันไปเรื่อยๆ ต้องโฟกัสมากขึ้น ควรมี features ไหน ควรตัด features ไหน เพื่อให้งานเสร็จในเวลาที่จำกัด
WeFlex
สวัสดิการอย่างนึงที่ชอบมากของ Wongnai คือ ค่าหนังสือ ตอนนั้นมีกฎว่า ถ้าซื้อหนังสือแล้วต้องสรุปเนื้อหาให้คนอื่นในบริษัทอ่านด้วย แล้วถึงจะทำเรื่องเบิกได้
ด้วยกฎนี้ ทำให้ต้องบังคับตัวเองให้อ่านหนังสือที่ซื้อมาแล้วจนจบ 😆 และเขียนสรุปด้วย ปกติก็จะอ่านหนังสือจนจบอยู่แล้ว แต่ข้อดีอยู่ที่การเขียนสรุปนี่แหละที่ทำให้ได้ทบทวนว่าได้อ่านอะไรไปแล้วบ้าง
เสียดายที่ตอนหลังยกเลิกกฎนี้ไปแล้ว คือให้เบิกค่าหนังสือได้โดยที่ไม่ต้องสรุป ด้วยความขี้เกียจ เลยกลายเป็นอ่านหนังสือแต่ไม่ได้สรุป ซึ่งหลายๆ ครั้ง พอวางหนังสือ ก็จำไม่ได้ด้วยซ้ำว่าอ่านอะไรไป
Retrospective
Retrospective meeting เป็นเวลาที่คนในทีมจะมารวมกันหลังจากจบ sprint นึง เพื่อบอกเล่าสิ่งที่เรียนรู้ ปัญหาที่เกิดขึ้น เพื่อให้ทีมช่วยกันหาวิธีแก้ไข มีหลายๆ ครั้งที่ได้แง่คิดดีๆ กลับมา และมีบางครั้งที่ช่วยขัดเกลาทัศนคติให้ดีขึ้น
มีครั้งนึง ที่ติดปัญหาทาง technical แก้ไม่ได้ ไม่เข้าใจว่าเกิดจากอะไร ลองดูโค้ดเทียบกับแบบอื่นๆ ที่ทำไว้แล้วแก้ให้เหมือนแบบที่เคยทำมา สุดท้ายโค้ดที่แก้ใช้งานได้ แต่เราไม่ได้พัฒนาขึ้นเลย เพราะไม่เข้าใจสาเหตุว่าอะไรทำให้วิธีนึงใช้งานได้และอีกวิธีนึงใช้งานไม่ได้ หลังจากนั้นก็พยายามมองหาต้นเหตุของปัญหาให้มากขึ้นมากกว่าแก้ให้มันผ่านไป
อีกครั้งนึง คือ ตอนที่ทำ feature ที่ต้องรอ response จาก 3rd party ปัญหา คือ จะเทสยังไงบน local environment วิธีตอนนั้น คือ deploy code ของเราไปบน test environment ซึ่งมีการติดต่อกับ 3rd party จริง และเทสว่าทำงานถูกต้องมั้ย หากเจอว่าทำงานผิด เราก็ต้องมาแก้โค้ดและ deploy ขึ้นไปบน dev ซ้ำ ทำให้การทำงานช้าลง คำแนะนำที่ได้ตอนนั้น คือ เวลาติดปัญหาที่ทำให้ทำงานได้ยาก แทนที่จะทนทำมันต่อไป ให้เราพยายามหาวิธีแก้ที่เหมาะสมดีกว่า นอกจากช่วยให้เราทำงานง่ายขึ้น ยังช่วยให้คนอื่นที่เจอปัญหาคล้ายๆ กันทำงานง่ายขึ้นด้วย
CL/CI — Continuous Learning/Continuous Improvement
นับจากวันแรกจนถึงวันนี้ก็ผ่านมา 2 ปีแล้ว พัฒนาการที่เกิดขึ้นชวนให้นึกถึงคำถามในวันนั้น เข้าใจแล้วว่า “เวลา” สร้างความแตกต่างในการทำงานได้มากจริงๆ ประสบการณ์ 1 ปีกับประสบการณ์ 4 ปีคงจะเทียบกันไม่ได้ ทำให้บางครั้งนึกเสียดายที่รู้ตัวเองช้าและนึกเสียใจที่ไม่ได้เรียน Com Sci ตั้งแต่ต้น แต่ก็ดีใจ เพราะการไม่ได้เรียน Com Sci กลับเป็นแรงผลักที่ดีที่สุดให้ไม่เคยหยุดพยายามและเป็นเดือดเป็นร้อนทุกครั้ง (บางครั้งก็เกินไป) ที่รู้สึกว่าตัวเองย่ำอยู่กับที่
การยอมรับในอดีตที่ผ่านมาและเชื่อว่ามันดีที่สุดแล้ว ทำให้เลิกคิดวุ่นวายถึงเรื่องสมัยก่อน เพราะมันไม่สำคัญอีกแล้วและมีเพียงความพยายามของเราใน “ทุกๆ วัน” “ต่อจากนี้” เท่านั้นที่จะเป็นตัวกำหนดเส้นทางข้างหน้าของเรา!
