See the original English version of this article here
Caleb Taylor ผู้เขียนบทความนี้ ได้สังเกตเห็นคุณสมบัติบางอย่างของ Engineer ที่เรียกได้ว่ามีค่าต่อองค์กร ซึ่งโดยทั่วไปมักจะเป็นคนที่เฉลียวฉลาดอยู่แล้ว ซึ่งนั่นไม่ได้เป็นเหตุผลหลักที่ทำให้พวกเขาเป็นคนที่ยอดเยี่ยมได้ แต่พวกเขามีแนวโน้มที่จะทำสิ่งที่คนอื่นทำไม่ได้ต่างหาก ในบทความจะมาบอกถึงคุณสมบัติที่ช่วยให้เป็นสุดยอด Software Engineer
สิ่งที่จะแนะนำต่อไปนี้อาจไม่ใช่เรื่องง่ายที่จะทำ แต่มันก็เป็นหลักการชี้นำ สำหรับคนที่กำลังต้องการจะเป็นสุดยอด Engineer ซึ่งอาจไม่ได้ครอบคลุมครบทุกประเด็นและคำจำกัดความของคำว่า “สุดยอด/ยอดเยี่ยม” ของแต่ละคนก็ไม่เหมือนกัน
ฝึกซ้อมเพื่อเป็น “นักผจญเพลิง”
ตอนที่ Caleb เพิ่งเริ่มทำงานใหม่ ๆ เขาได้รับบทเรียนที่มีค่าครั้งแรกจาก Manager ของเขา โดย Manager พูดว่า “หากคุณต้องการเป็นคนที่มีค่าขององค์กร ก็จงเป็นคนที่กล้าลุยฝ่ากองไฟ” ซึ่ง Manager ของเขาสนับสนุนให้เขาเป็น Engineer ที่เต็มใจและมีความสามารถที่จะจัดการกับปัญหาใหญ่ ๆ ได้
คำว่า “ไฟ” ในที่นี้เป็นได้ทั้ง Bug ใน Production ที่ยากจะแก้ไข ไปจนถึงการเปลี่ยนโครงสร้างของ Service ที่สำคัญ ซึ่งไม่ใช่ทุกคนที่จะสามารถดับไฟเหล่านี้ได้ ความเต็มใจที่จะจัดการกับปัญหาที่หนักหนาสาหัสถือเป็นขั้นตอนแรก แต่มันก็ยังไม่เพียงพอ คุณต้องมีความสามารถในการดับไฟด้วย
การเตรียมพร้อมสำหรับช่วงเวลาที่สำคัญเหล่านี้ไม่ใช่เรื่องที่ทำได้ง่าย ๆ คุณจะต้องอุทิศตัวเองเพื่อทำความเข้าใจกับสถาปัตยกรรมและการออกแบบของระบบ ยิ่งระบบซับซ้อนมากเท่าไร ก็ยิ่งใช้เวลามากขึ้นเท่านั้น
นี่คือวิธีที่ Caleb พบว่ามันช่วยให้เขาสามารถสู้กับไฟได้:
- สร้าง HLD (High-level design) สำหรับ App / Service ของคุณ
- ทำ Document สำหรับ Code ส่วนที่มีความซับซ้อน
- ทำการ Debug Flow หลัก ๆ ผ่าน Code ของคุณทีละบรรทัด
- ทุ่มเทเวลาในการทำความเข้าใจ Code ที่คุณยังไม่เข้าใจ
- ทำการ Research เทคโนโลยีที่ทีมของคุณใช้งานและจะทำให้พวกเขาเป็นผู้เชี่ยวชาญ
เมื่อคุณทำงานแต่ละงาน ขอให้ระวังในสิ่งที่คุณไม่เข้าใจ จงอย่าคิดว่า “มันก็แค่งาน” ทุกครั้งที่คุณต้องเกี่ยวข้องกับ Code ไม่ว่าจะด้วยเหตุผลใด ถือว่าคุณได้มีโอกาสทำความเข้าใจมัน นั่นเป็นเหตุผลที่ การฝึกฝนให้เป็น “นักผจญเพลิง” นั้นยากมาก มันอาจเป็นเรื่องน่าเบื่อ ต้องใช้ความพยายามในการทำทุกวันเพื่อให้พร้อมสำหรับไฟที่จะต้องเจอในอนาคต ซึ่ง “สุดยอด Engineer” คือ คนที่ทำสิ่งเหล่านี้อย่างสม่ำเสมอ พวกเขายินดีที่จะสู้กับปัญหาที่พวกเขาไม่รู้แม้วิธีแก้ไข พวกเขามักจะทุ่มเทมากกว่า Engineer ทั่วไป เนื่องจากพวกเขาต้องการเข้าใจสิ่งต่าง ๆ อย่างแท้จริง ซึ่งสิ่งนี้ไม่เกี่ยวข้องกับความฉลาดเลย แต่มันเป็นเรื่องของ Mindset
สรุปแนวคิดที่สำคัญ: จงอุทิศตัวเองเพื่อทำให้เข้าใจอย่างลึกซึ้งเกี่ยวกับ Application ของคุณ เมื่อเกิดปัญหาที่ยากๆ จงเต็มใจที่จะทุ่มเทกับมันและดับไฟนั้นให้ได้
รู้จักกับเรื่องของคอขวด (Bottlenecks)
คุณเคยประสบสถานการณ์เช่นนี้มากี่ครั้งแล้ว
Developer A: “ผมจะ Deploy การเปลี่ยนแปลงล่าสุด ตกลงไหม? เมื่อผม Update Static Files แต่ละ File แบบ Manual และลบการตั้งค่า Configuration ในเครื่องแล้ว ผมถึงจะสามารถ Upload ได้”
Developer ใหม่: “เดี๋ยวก่อน คุณแก้ไข File เหล่านี้แบบ Manual ทุกครั้งที่คุณจะ Deploy เหรอ?”
Developer A: “ใช่แล้ว มันเป็นอะไรที่แย่มาก เราทำให้ Production เสียหายไปหลายครั้งเมื่อเราทำผิดพลาด มันค่อนข้างน่ารำคาญ”
Developer ใหม่: “นั่นดูเหมือนจะเป็นวิธีที่ไม่ดีสักเท่าไร ในการ Deploy”
Developer A: “ใช่ เราควรแก้ไขมันสักที”
นี่เป็นปัญหาที่พบได้บ่อยสำหรับทีม Software ชิ้นงานส่วนสำคัญหรืองานทั่วไปของ Workflow ของทีมคือ การ Manual, ความเสียหายที่เกิดได้ง่าย และความช้า บางครั้งทีมเองจะรับรู้ได้ว่า มันเป็นปัญหาและต้องแก้ไขมัน
แล้วจะเริ่มมองหาจากที่ไหนก่อนดี จุดเริ่มต้นที่ดีคือให้คิดถึงการ Automate สิ่งต่าง ๆ เริ่มต้นด้วยงานที่สำคัญที่สุดที่คุณต้องดำเนินการแบบ Manual นั่นเอง ทีมของคุณมีการ Test ว่าทุกคน Run การ Pull Request แต่ละครั้งแบบ Manual เพื่อให้แน่ใจว่าพวกมันจะสามารถผ่านได้ ใช่หรือไม่? แล้วทำไมไม่ลองใช้งาน CI Server อย่าง Jenkins หรือ Travis CI และแสดงผลลัพธ์โดยตรงใน Pull Request ด้วย Web hooks ดูล่ะ?
สมาชิกในทีมของคุณใช้เวลาในการ Review Style และ Format ของ Code หรือไม่? ทำไมไม่ Lint Code ของคุณโดยอัตโนมัติ โดยใช้ Git hook ในแต่ละ Commit ด้วยเครื่องมืออย่าง Husky และ Lint-staged ล่ะ?
การ Optimize แบบนี้สามารถผิดพลาดได้ง่าย การที่ทีมยอมรับความยุ่งยากเหล่านี้ ก็เพราะมันคือ “สิ่งที่เป็นอยู่” แทนที่จะพยายาม Optimize มัน แต่สุดยอด Engineer มักจะคิดถึงปัญหาเหล่านี้ พวกเขาจะใช้เวลาในการแก้ไขปัญหา และการเปลี่ยนแปลงที่เกิดขึ้น ก็ถือเป็นชัยชนะที่ยิ่งใหญ่สำหรับทั้งทีมด้วย
เมื่อเร็ว ๆ นี้ Caleb ได้อ่าน Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations และพบว่ามันเป็น Resource ที่ดีเยี่ยม มันให้ข้อมูลเชิงลึกเกี่ยวกับ Best Engineering Practices และวิธีที่พวกเขาส่งผลต่อประสิทธิภาพและความสุขของทีม นอกจากนี้มันมีประโยชน์ในการช่วยปรับการทำงานในเรื่องปัญหาคอขวดของทีมอีกด้วย
สรุปแนวคิดที่สำคัญ: มองหาปัญหาคอขวดใน Development Process หรือ Deploy Pipeline ของทีม พยายามจัดลำดับความสำคัญและแก้ไขปัญหาที่สำคัญที่สุดก่อนเพื่อให้ชีวิตคนในทีมดีขึ้น
อย่าหลับหูหลับตาทำตามแต่ Pattern เดิมที่มีอยู่
Engineer มักชอบ “รูปแบบ” หนังสือหลายพันเล่มมักจะมีเนื้อหา Programming Patterns ที่ดีที่สุดและวิธีใช้งานพวกมัน แต่น่าเสียดายที่ไม่ใช่ Code Patterns ทั้งหมดที่ควรนำมา Reuse
บางครั้ง Caleb ก็ได้ Review Pull Request และพบว่ามีบางส่วนของ Code ที่ดูแปลก ๆ หรือถูกเขียนมาไม่ดี และเมื่อถามว่าทำไมถึงถูกเขียนด้วยวิธีนี้ คำตอบที่ได้ก็มักจะเหมือนกัน คือ “นั่นเป็นสิ่งที่เคยทำมาก่อนแล้ว และได้ไปคัดลอกมาจากที่อื่นมา”
สุดยอด Engineer จะระมัดระวังอย่างมากเกี่ยวกับการนำ Code ที่มีอยู่มา Reuse สิ่งนี้ใช้ได้ทั้งกับการเขียนและการ Review Code ซึ่งพวกเขามักจะถามคำถามเหล่านี้:
- Code ที่คัดลอกมา ถือเป็นวิธีที่ดีที่สุดในการแก้ปัญหาหรือไม่
- หากมันคล้ายกับส่วนของ Code ที่มีอยู่ เราจะสามารถรวมเป็น Module เดียวเพื่อลดความซ้ำซ้อนได้หรือไม่
- มี Bug ที่เกี่ยวกับ Logic อันเนื่องจากความแตกต่างระหว่าง Code ใหม่และ Code ที่มีอยู่หรือไม่
- Code นี้ มันตรงกับมาตรฐานและการออกแบบที่ได้ตกลงกันภายในทีมหรือไม่
หลักการเหล่านี้ยังใช้กับการ Update Code เก่า ๆ ด้วย มันง่ายมากที่จะเข้าไปดู Code ที่ล้าสมัยหรือเขียนไว้ไม่ดี โดยที่ไม่ได้แก้ไขอะไรเลย แต่สุดยอด Engineer มักจะไม่ค่อยทำเช่นนี้ พวกเขาจะนำเอาแนวคิดของการ Refactor อย่างต่อเนื่องมาใช้
นี่ไม่ได้หมายความว่า การ Update Code แต่ละครั้ง จะส่งผลให้เกิดการเปลี่ยนแปลงครั้งใหญ่ การปรับปรุงแก้ไขสามารถเป็น (และมักจะเป็น) สิ่งต่าง ๆ ที่เรียบง่าย เช่น การปรับปรุงแก้ไข ตัวแปรหรือชื่อ Function หรือ แบ่ง Function ที่มีขนาดใหญ่และซับซ้อน ออกเป็น Function ที่มีขนาดเล็กกว่า เป็นต้น
เมื่อเร็ว ๆ นี้ Caleb ได้อ่านหนังสือ Refactoring: Improving the Design of Existing Code ของ Martin Fowler และพบว่ามันเป็น Resource ที่ดีมากสำหรับเรื่องการ Refactor
สรุปแนวคิดที่สำคัญ: จงประเมิน Code Structures, Patterns และ Design อยู่เสมอ การ Copy & Paste Code ถือเป็นสาเหตุของปัญหาที่จะตามมาทั้งหมด รวมทั้งทำ Code ให้อยู่ในสถานะที่ดีกว่าเดิม ทุกครั้งที่คุณพบมัน
สรุป
หากคุณเป็น Software Engineer สามารถนำคุณสมบัติเหล่านี้ไปประยุกต์ใช้กับงานของคุณได้ มันอาจเป็นเรื่องยากที่จะทำสิ่งเหล่านี้อย่างสม่ำเสมอ คุณสมบัติบางอย่างต้องการความพร้อมและความเต็มใจที่จะก้าวหน้าในหน้าที่การงานไปอีกขั้น หากคุณยินดีทำงานตามคุณสมบัติเหล่านี้คุณก็จะเป็น Software Engineer ที่ดีขึ้น
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 28 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://www.freecodecamp.org/