นี่คือสิ่งที่ผมได้เรียนรู้ หลังจากทำงานในสาย Software Engineer เป็นเวลา 1 ปี
สวัสดีทุกท่านอีกเช่นเคยนะครับ สำหรับบทความนี้ก็จะตรงตัวกับหัวข้อเลย ซึ่งเอาจริง ๆ จากเวลาที่เขียนบทความนี้ นับย้อนหลังไปก็เป็นระยะเวลา 1 ปี 3 เดือนแล้ว ที่ผมได้ใช้ชีวิต และทำงานในฐานะของนักพัฒนาซอฟต์แวร์ ตัวของผมจะเน้นไปทางด้านการพัฒนาทางฝั่งของ Backend, Server-side, หลังบ้าน ก็แล้วแต่จะเรียกกันเลยนะครับ ฮ่า ๆ โดยผมสรุปสิ่งที่ผมได้รับรู้จากการเป็น Developer จริง ๆ ไว้คร่าว ๆ เพื่อให้กับคนที่อยากจะเข้ามาเป็นส่วนนึงของสังคมนักพัฒนาได้รับรู้กันครับ ว่าชีวิตวัยทำงาน กับตอนเรียนเนี้ย มันต่างกันแค่ไหน และจริง ๆ แล้วสิ่งที่เราเรียนไป มันได้ใช้ในการทำงานจริง ๆ รึเปล่า
เล่าพื้นหลังกันก่อน คือตัวผมเนี่ย จบในสาขาวิชาวิศวกรรมคอมพิวเตอร์นะครับ ก็เลยจะมีการเรียนในส่วนของวิชาพื้นฐานของคอมพิวเตอร์ ไปจนถึงวิชาเฉพาะอย่างพวก SE, SA, OS, Network, ML อะไรจำพวกนี้ครับ พื้นฐานในฝั่งของสาขาอาชีพก็เลยมีอยู่แล้วก่อนที่จะทำงานเป็น Software Engineer เต็มตัวนะครับ
หมายเหตุ ในส่วนองค์ความรู้นี้เป็นสิ่งที่ผมได้เรียนรู้มา โดยแต่ละคนก็จะมีประสบการณ์ที่ได้รับที่แตกต่างกันในระหว่างการทำงาน ดังนั้นบทความนี้จึงเป็นเหมือน Case-study ให้กับน้อง ๆ หลายคนมากกว่านะครับ 😁
หัดใช้ Git ให้ดีให้คล่อง พิจารณาก่อน Merge และ Pull Code บ่อย ๆ
===========
ด้วยความที่ตัวเองเจ็บมาเยอะพอสมควรในระหว่างช่วงเรียน มีโค้ดหายบ้าง แก้ Confilct เยอะบ้าง อันนี้ก็เลยอยากจะปักธงเอาไว้เลย 🚩และ Git หรือ Version Control นั้น ถือว่าเป็นสิ่งที่จำเป็นมาก ๆ ในสายอาชีพ ณ ปัจจุบันนี้ หรือคุณอยากใช้ Version Control version Flashdrive ก็ได้นะ แต่มันจะเป็นปัญหาระยะยาวแน่ ๆ ฮ่า ๆ เอาจริง ๆ ผมก็ไม่ได้เก่งใช้งาน Git มากหรอก แค่พอทำที่ใช้งานกันทั่วไป และไม่ปวดหัวได้ ทิ้งท้ายหัวข้อนี้ผมแปะลิงค์เรียนเพิ่มเติมไว้ให้สำหรับคนที่ใช้ยังไม่คล่องนะครับ
Learning resource: Git and GitHub
ถ้าเป็นไปได้ ผมคิดว่า สำหรับมือใหม่ การทำความเข้าใจ Workflow นี้ น่าจะทำให้ชีวิตดีขึ้น 😅
ถ้า Flow การทำงานมันซับซ้อน เขียน Flowchart หรือไตร่ตรองการทำงานของโค้ดก่อน ก่อนลงมือเขียนโค้ดจริง
===========
ในตอนเรียน คือผมก็เป็นพวกมั่นใจในฝีมือตัวเองมากพอสมควร Flow การทำงานบางอย่างไม่ต้องเขียนโฟลก็ได้ แค่คิดในหัวก็พอทำได้ หรืออ่านจาก Sequence Diagram ก็เขียนได้เลย หรือจะคิดไปเขียนไป ไปด้วยเลยอะไรแบบนี้
แต่จุดเปลี่ยนของผมก็มาถึง เมื่อผมเจอ flow ที่มันซับซ้อน, มี business logic แทรกระหว่าง flow หรือมีพวกการทำ Recursive พอมาถึง flow จำพวกนี้ มันก็พอนึกในหัวได้ แต่พอจะสลับความคิดไปคิดอีกอย่าง อันเก่าก็เลือนลาง สุดท้ายก็มีพี่ที่ทำงานก็แนะนำว่า ให้ลองเขียน flowchart ก่อนมั๊ย ตอนแรก ๆ ก็ไม่เชื่อ ก็เลยลองดู
สรุปว่า flow ที่ใช้เวลานานมาก่อนหน้านี้ เสร็จไวขึ้น แค่สละเวลาออกไปนั่งวางแผนก่อนเขียนโค้ดแค่นั้นเอง หลังจากนั้นมาเวลาเจอ flow ยาว ๆ ยาก ๆ ผมมักจะชอบเขียน Flowchart ก่อน และก็ตอนนี้ก็ลดนิสัยคิดไปด้วย โค้ดไปด้วย ลงไปบ้างแล้ว ชีวิตโค้ดก็ดีขึ้นนะครับ 😄
ทีมและการสื่อสารคือจุดเริ่มต้นความสำเร็จ
===========
ขอเล่าเลยว่า ผมเป็นพวกประเภท Introvert ไม่ค่อยชอบเที่ยว ไม่ค่อยเข้าสังคม เวลาออกไปเดินเล่นอะไรยังเงี้ย ผมจะรีบกลับตลอด 😂 เนื่องจากไม่ค่อยพูดมากเท่าไหร่ ดังนั้นทักษะการสื่อสาร ก็เลยต่ำมาก ๆ เลย (ถึงตอนนี้จะดีขึ้นมาบ้าง แต่วิธีการพูดก็ยังไม่ธรรมชาติอยู่ดี)
พอเริ่มเข้ามาทำงานแรก ๆ ก็เป็นประเภทรับ Task มา แล้วก็ไปนั่งทำคนเดียว และด้วยความที่ติดนิสัย One man show มาตั้งแต่สมัยเรียน ก็เลยทำงานไม่สุงสิงกับใคร และด้วยความที่มันเป็นแบบนั้น มันก็มีเหตุการณ์ที่ผมเขียนโค้ดไปแล้ว แต่ว่ามันไม่ตรงกับ requirement ซะทั้งหมด ทำให้ผมต้องกลับมารื้อโค้ดของตัวเอง ซึ่งตอนนั้นอารมณ์เสียกับตัวเองมาก ตั้งแต่คราวนั้นมา ผมก็เลยซักถามบ่อยขึ้น ๆ และงานมันก็ค่อย ๆ ดีขึ้น จนตอนนี้ในทีมผมก็สามารถคุยได้สบาย ๆ แล้ว
พอเห็นว่าผลลัพธ์มันต่างกันพอสมควร แถมบรรยากาศการทำงานก็ดีขึ้นมาด้วย ก็เลยมีการ Refactor ตัวเองนิดหน่อย จะได้ทำงานร่วมกันคนอื่นได้ดีมากขึ้น
รับฟังคนอื่นบ้าง บางทีเราก็ไม่ได้ถูกทั้งหมด หรือไม่เคยถูกเลย
===========
ด้วยความที่เป็นคนที่มั่นใจในตัวเองสูงพอสมควร บ้าระห่ำเลยก็ว่าได้ แต่หลังจากที่ทำงานไปซักพักก็ได้บทเรียนว่า การรับความคิดใหม่ ๆ บางทีเราก็อาจจะได้รู้ ในสิ่งที่เราไม่เคยรู้มาก่อน และบางทีมันก็ล้มล้างความเชื่อเก่าของตัวเองไปได้เหมือนกัน
ถามคำถามให้ดีขึ้น ด้วยบางสิ่งที่เราได้ลองทำไปบ้างแล้ว จะได้คำตอบ และแก้ไขปัญหาเร็วขึ้น และอ่าน Error ซะบ้าง
===========
อันนี้จริง ๆ แล้ว ผมคิดได้ตั้งแต่สมัยเรียน แต่เอาจริง ๆ ข้อนี้มันขึ้นอยู่กับระยะเวลาที่เราคลุกคลีกับมัน หรือสิ่งที่เราสนใจ บางครั้งคำถามกับตัวเองหรือปัญหาที่เราเจอมันก็คลุมเครือจนไม่รู้จะอธิบายยังไง แต่อยากเสริมว่า การที่ทำแบบนี้ จะทำให้เราสามารถถามคำถามได้โฟกัสกับปัญหามากขึ้น และการแก้ไขปัญหาของเราก็จะเร็วขึ้น
โดยส่วนมากปัญหาของโค้ดนั้น มักจะปล่อยออกมาจาก error ที่มัน throw ออกมา ไม่ว่าภาษาใด ๆ ก็ตาม (แต่ถ้าตายเงียบ คือ GG เตรียมหัวหมุนได้เลย 😂) และโดยส่วนมากเวลามัน error มักจะมาจากนักพัฒนาอย่างเรานี่แหละ เป็นคนวางบอมบ์ไว้เอง
Test โปรแกรมก่อนอัพขึ้น Version Control จะ Manual Test หรือรัน Lib Test ก็ได้ และโค้ดที่อยู่บน Repository หลักควรจะรัน start ขึ้นมาได้
===========
การ Test logic ของเรา ถือว่าเป็น practice ที่ดี เพราะมันจะเป็นการการันตีว่าโค้ดเราทำงานถูกต้อง ซ้ำยังทำให้งานดูมีคุณภาพไปด้วย ที่ผมจั่วหัวว่า จะ Manual Test ก็ได้นั้น เป็นเพราะว่าในบางครั้งงานมันก็ต้องทำตาม deadline และมีกำหนดการของมัน ทำให้เรารู้สึกว่าบางทีอาจจะต้องคิดไป ทำไป และไม่ได้ใช้ Lib unit testing มาเขียน Test function ของเรา ซึ่งผมอาจจะอ่อนประสบการณ์รึเปล่า แต่ในบางครั้งเราก็ต้องทำแบบนั้น เพื่อต้องส่งมอบ แต่อย่างน้อยก็อาจจะต้อง test มือกันบ้าง เช่นยิง Postman เพื่อ Test result อะไรแบบนี้
โค้ดให้คนอื่นอ่านรู้เรื่องและมาทำต่อได้
===========
ย้อนกลับไปสมัยที่เป็นนักศึกษา ก่อนที่จะออกฝึกสหกิจ มีจิตใจที่จะแสดง power ให้เต็มที่ ท่ายากอะไรฝึกไว้เยอะ ๆ แต่บทเรียนนั้นมันก็ตามมาด้วยที่ว่า โค้ดนั้นเราอ่านได้คนเดียว หรือบางทีเราก็ดันลืมไปแล้ว ว่าเราเขียนอะไรไป 😅
แต่หลังจากสหกิจเสร็จ พร้อมทั้งประสบการณ์การทำงานที่ผ่านมา ได้เห็นโค้ดจากพี่ที่ทำงาน และโค้ดจาก Github เป็นร้อย ๆ repo สรุปว่าจริง ๆ แล้ว เราไม่ต้องทำท่ายากอะไรเลย ถ้า Execute time มันพอ ๆ กัน สู้ไล่ให้เป็น Step ๆ ให้อ่านรู้เรื่องดีกว่า
Naming Convention กับ Code Format ศึกษาให้ดี เพราะมันเป็นมาตรฐาน และมันเป็นจุดเล็ก ๆ ที่ทำให้เราเป็นนักพัฒนาซอฟต์แวร์ที่มีคุณภาพมากขึ้น
ความมั่นใจในตัวเองเป็นอาวุธที่สำคัญมาก
===========
ข้อนี้มันอาจจะขัดใจใครหลาย ๆ คน แต่สำหรับผม ถ้าทำอะไรครึ่ง ๆ กลาง ๆ มันก็ทำได้ไม่เต็มที่ใช่ไหมล่ะ แต่มันก็ต้องไม่ข้ามเส้นจนกลายเป็นพวกอีโก้สูงไปด้วยนะ มั่นใจในสิ่งที่ทำ ถึงมันจะทำงานผิดพลาด แต่อย่างน้อยเราก็ได้เรียนรู้วิธีที่ที่จะทำให้มันพังนะ
ไม่จำเป็นต้องรู้ทุกอย่าง แต่ต้องรู้จุดแข็งของตัวเอง และรับรู้จุดอ่อนของตัวเอง
===========
อย่างผมนี่คือชอบทางฝั่งด้าน Backend ผสม DevOps ผสม Architect ดังนั้นสกิลฝั่ง Frontend เลยต่ำนิดหน่อย อาจจะพอเขียน Layout ง่าย ๆ ได้บ้าง Mobile app ง่าย ๆ ได้บ้าง แต่มันก็ไม่สวย ผมก็รับรู้และพัฒนาเพื่อพยายามลบจุดอ่อนของตัวเองอยู่เรื่อย ๆ และในขณะเดียวกันก็ต้องพัฒนาจุดแข็งของตัวเองให้ดียิ่ง ๆ ขึ้นไป
ประโยคนี้เป็นประโยคที่ผมติดปากมาตั้งแต่มหาลัย
มันไม่ได้ยาก เราแค่ยังไม่รู้ ✌️
อันนี้เป็น Roadmap ที่ผมเคยไปเปิดมาเจอ เลยอยากนำมาแบ่งปัน เพื่อเป็นแนวทางในการศึกษา และช่วยหา พัฒนาจุดแข็งได้
วิชาพื้นฐาน ก็คือพื้นฐานทุกอย่างจริง ๆ คือ ความรู้ด้าน Data Structure & Algorithms
===========
ไม่รู้จะอธิบายออกมายังไงดี แต่มันสำคัญมากจริง ๆ มันทำให้เราเข้าใจ structure ข้อมูลมากขึ้น ออกแบบโค้ดได้ดีขึ้น คิดได้ดีขึ้น Optimize execute time ของฟังก์ชันได้ดีขึ้นด้วย
Learning Resources
เรามีงานประจำ แต่ก็ไม่ใช่ว่าต้องเรียนรู้แค่เฉพาะที่ใช้ในงาน บางทีทำตามใจตัวเองบ้างก็ได้
===========
ด้วยความที่เป็นคนชื่นชอบ Technology programming และ ecosystem เลยคอยตามข่าวพวกนี้อยู่ทุกวี่ทุกวัน ตัวไหนเข้าใหม่ Framework ใหม่ ภาษาไหนจะบูม ก็ต้องคอยดูแนวโน้มตลอด ตัวผมก็เน้นไปทาง Node.js backend ในงานปัจจุบัน แต่ถ้าอยากเพิ่มโอกาส และประยุกต์ใช้หลาย ๆ งาน ก็มีศึกษาศึกษาเพิ่มเติมด้วยตัวเอง สละเวลาช่วงเลิกงาน และวันหยุดซักเล็กน้อยก็ได้ ตอนนี้เวลาของผมส่วนใหญ่ก็หมดไปกับเรื่องพวกนี้เช่นกัน 😅
ตัวอย่าง Channel Youtube ที่ชอบดูเกี่ยวกับ Programming & Technology
- Academind จารย์แม๊ก
- Traversy Media จารย์แบร๊ด
- freeCodeCamp.org
- Google Cloud Platform 💖
Optional สำหรับสาย Backend
===========
สำหรับสาย Backend ก็อยากจะเสริมสิ่งที่ควรจะต้องรู้ อาจจะไม่ต้อง expert แต่รู้ไว้จะทำให้ชีวิตดีมากขึ้นนะครับ 😋
Container & Docker & Kubernetes
เป็นเรื่องที่สำคัญมาก ๆ ในยุคนี้ ในยุคที่ Microservices และ Serverless กำลังครองเมือง เนื่องจากว่าการมีอยู่ของ Container ทำให้ environment การทำงานของเรา มีความ Portable สูง และไม่ต้องกังวลกับเรื่อง environment ของเครื่อง server มากนัก
Docker for Beginners: Full Course
Kubernetes Tutorial | Kubernetes | Kubernetes tutorial for beginners
Cloud computing 💖
อาจจะเลือกมาซักตัวก็ได้ เพื่อทำการศึกษาเช่น AWS, Azure, GCP หรือ DigitalOcean เพราะตัว fundamental ของแต่ละเจ้าจะคล้าย ๆ กันอยู่แล้ว 🤟
สามารถเข้าไปศึกษาเพิ่มเติมได้จากบทความนี้ก็ได้
Jenkins
คีย์หลักของการทำ DevOps คือการทำ CI/CD Pipeline ตัว Jenkins จะเป็นตัวที่คอยจัดการเรื่องนั้นให้กับเรา ซึ่งมันมีตัวอื่น ๆ อีกนั่นแหละ แต่การที่เราเรียนรู้ไว้มันจะเป็นพื้นฐานให้กับอีกหลาย ๆ ตัว
CI CD Of Docker Containers | DevOps | Jenkins Pipeline Tutorial | Docker CI/CD | DevOps CI/CD
หมดนี้ก็เป็นสิ่งที่ผมได้เรียนรู้โดยสรุปออกมาคร่าว ๆ เพื่อให้เป็นตัวอย่างให้กับนักศึกษา นักพัฒนาซอฟต์แวร์หน้าใหม่ บุคคลที่สนใจ และได้สอดแทรกแหล่งเรียนรู้เอาไว้ไปศึกษาต่อ หวังว่าจะเป็นประโยชน์ให้กับทุกท่านได้ไม่มากก็น้อยนะครับ
สุดท้ายนี้ก็ถ้าหากใครอยากสอบถามเพิ่มเติม หรือจะ Make connection กันไว้ก็สามารถมาที่ช่องทางนี้ได้เลยนะครับ ขอบคุณที่อ่านจนจบนะครับ 😉
