การพัฒนา Software ในโลกของความเป็นจริงนั้นแตกต่างจากสิ่งที่ถูกสอนกันในมหาวิทยาลัย แต่จะแตกต่างกันอย่างไรบ้าง คุณ Tan Le Tian จะมาถ่ายทอดสิ่งที่เขาได้เรียนรู้หลังจากทำงานเป็น Junior Software Engineer ที่บริษัท Startup แห่งหนึ่งที่ให้บริการสร้าง Web Application ตามความต้องการเฉพาะของลูกค้า
1. การเป็น Full Stack Engineer ไม่ใช่ทางเลือก แต่เป็นสิ่งที่จำเป็น
ด้วยความที่เป็นบริษัท Startup ขนาดเล็กที่มีคนทำงานเพียงแค่ 7 คน จึงมีข้อจำกัดอยู่บ้างในการว่าจ้างพนักงานที่มีความเชี่ยวชาญเฉพาะทางมา เช่น Frontend, Backend, Database หรือ Design ซึ่งแน่นอนว่ามีความแตกต่างจากบริษัทขนาดใหญ่เป็นอย่างมาก
ที่บริษัท เรามักจะได้รับหลาย ๆProject จากลูกค้าหลายรายมาพร้อม ๆ กัน ซึ่งทุกคนจะได้รับ Project เป็นของตัวเองและต้องทำมันให้เสร็จ ดังนั้นจึงเป็นเรื่องจำเป็นสำหรับทุกคนที่จะต้องรู้ในทุกแง่มุมของการพัฒนา Web เพื่อ Implement Feature ต่าง ๆ และแก้ Bugs
ตัวอย่างเช่น เราต้อง Implement Feature ทั้งหมดที่อนุญาตให้ User สามารถเพิ่มและแก้ไข Record ใน System เราจำเป็นต้องใช้ HTML, CSS และ JavaScript เพื่อสร้าง Form ในส่วนของ Frontend ขณะที่ Backend จำเป็นต้องใช้ภาษา PHP และ MySQL เพื่อทำการอ่านและเขียน Database
2. สร้าง Product ให้ใกล้เคียง Budget และ Requirement ของลูกค้าให้มากที่สุด
บางครั้งลูกค้าก็ต้องการ Software อย่างเร่งด่วนเพื่อแก้ไขปัญหาบางอย่าง พวกเขาตั้ง Deadline ที่กระชั้นและมี Budget ที่จำกัด
ด้วยเหตุผลข้างต้น ทำให้ต้องมีการ Trade-off อยู่ตลอดเวลาระหว่าง เวลาในการ Develop, ราคา และคุณภาพของ Software Product และมันก็เป็นเรื่องยากที่จะส่งมอบ Product ที่มีคุณภาพสูง ภายใต้ราคาที่ต่ำ และ Deadline ที่กระชั้นมาก
ดังนั้น เราจำเป็นต้องจัดลำดับความสำคัญในการ Develop ตัว Requirement หลัก ๆ ของ Software ก่อนเป็นลำดับแรก โดยทั่วไป Product ที่มีคุณภาพสูงอาจต้องใช้เวลาในการสร้าง และเพื่อส่งมอบ Product ให้ตรงเวลา และอยู่ภายใน Budget บางครั้งเราถูกบังคับให้ Trade-off ในเรื่องของความสวยงามและ User Experience
แต่ความเป็นจริงแล้ว ลูกค้าได้บอกกับเราอย่างชัดเจนว่า สิ่งที่พวกเขาต้องการก็คือ Web Application ที่สามารถใช้งานได้ และพวกเขาก็ย้ำหลายครั้งว่า พวกเขาไม่ได้สนใจเรื่องความสวยงามของ User Interface ตราบใดที่เราคิดราคาที่ถูกที่สุดเท่าที่จะทำได้
อาจฟังดูเหมือนว่าลูกค้าต้องการ Product ที่แค่พอให้พวกมันใช้งานได้เท่านั้น แต่พวกเขาก็แค่ต้องการ “ Minimum Viable Product” หรือ “Proof of Concept” ซึ่งแม้ว่าพวกมันจะห่างไกลจากความสมบูรณ์แบบ แต่ก็ดีพอที่จะใช้การ Automate ในงาน Manual บางอย่างในบริษัทของพวกเขาได้
นอกจากนี้ การพัฒนา Software เป็น Iterative Process หาก Software ได้รับการพิสูจน์แล้วว่า มันมีประโยชน์ในการใช้งานจริง ลูกค้าอาจจะไม่ลังเลใจที่จะจ่ายเพิ่มขึ้นเพื่อปรับปรุงพวกมันให้ดียิ่งขึ้น
3. บางครั้ง การใช้ทางลัดและแก้ปัญหาเฉพาะหน้าก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้
ไม่มีใครชอบเขียน Code ที่แย่ ๆ ซึ่งแม้จะสามารถใช้งานได้ แต่กลับไม่สามารถ Maintain และ Scalable ได้ รวมทั้งคงไม่มีใครชอบสร้าง Technical Debt แล้วต้องกลับมาแก้ไขปัญหาพวกมันในภายหลัง
โดยส่วนตัวของ Tan Le Tian แล้ว เขาพยายามเขียน Code ที่อ่านแล้วเข้าใจง่ายและ Clean อยู่เสมอ แต่บางครั้งเขาก็ไม่มีทางเลือกมากนัก
เมื่อ Integrate กับ 3rd Party API ในบางครั้งก็อาจทำให้เกิด Result ที่ไม่คาดคิด โดยทั่วไปแล้ว Documentation ของพวกเขามักจะไม่ได้อธิบายเหตุผลอย่างชัดเจนนัก
เมื่อใช้บาง Open Source Libraries มันก็หลีกเลี่ยงไม่ได้ที่จะเกิด Bug เล็ก ๆ น้อย ๆ อยู่บ้าง จากประสบการณ์ของ Tan Le Tian เอง ความไม่เข้ากัน (Incompatibility) ระหว่าง Version ต่าง ๆ ของ Libraries มักจะเป็นตัวการอันดับหนึ่งของการเกิด Bug ที่ไม่คาดคิด
ด้วยเหตุทั้งหมดข้างต้น อาจทำให้ Application ไม่ทำงาน และอาจสร้างความไม่พอใจให้แก่ลูกค้าของคุณ แม้ว่า Bug ที่เกิดขึ้นจะเกิดจาก Code ที่คนอื่นเขียน แต่ลูกค้าจะคิดว่ามันเป็นความผิดของคุณทั้งหมด และแน่นอนว่าคุณต้องรับผิดชอบในความผิดพลาดเหล่านั้น
ในกรณีนี้ วิธีเดียวที่จะแก้ไข Bug เหล่านี้ใน 3rd Party Code ก็คือการ Implement หนทางแก้ปัญหาเฉพาะหน้าที่ชาญฉลาดใน Code ของคุณเพื่อให้งานเสร็จ บางครั้ง Patch อาจจะไม่สมบูรณ์แบบนัก แต่มันก็สามารถใช้งานได้และช่วยให้คุณสามารถส่ง Product ได้รวดเร็วขึ้น
4. ไม่ใช่เรื่องผิดที่ใช้เทคโลโลยีที่เก่า (อย่าง PHP, jQuery)
ในช่วงไม่กี่ปีที่ผ่านมา มีเทคโนโลยีใหม่ ๆ เจ๋ง ๆ เกิดขึ้นมามากมาย เรามีทั้ง React.js, Vue.js, express.js, Golang, Scala และอื่น ๆ อีกมากมาย ผู้คนมากมายเริ่มดูถูกเทคโนโลยีเก่า ๆ อย่าง PHP, jQuery และ Java เพราะพวกมัน “น่าเบื่อ” และถูกใช้งานแพร่หลายจนดูเกร่อ
ในฐานะของ Developer มันน่าตื่นเต้นเสมอที่จะได้เรียนรู้เทคโนโลยีใหม่ ๆ และสร้างสิ่งต่าง ๆ จากพวกมัน แต่ในมุมมองทางธุรกิจแล้ว มักจะมีเหตุผลดี ๆ ที่เราจะไม่ใช้เทคโนโลยีที่เกิดใหม่ล่าสุดและสุดยอดที่สุด
อย่างในที่ทำงานของ Tan Le Tian เอง ก็มี Senior Engineer ที่มีประสบการณ์มากกว่า 10 ปีในการพัฒนา PHP Applications ดังนั้นพวกเราจึงสามารถเข้าถึง Codebase ของ PHP ในเชิงลึกเกี่ยวกับ Features ทั่วไป เช่น การส่ง Emails, การส่ง Notifications ไปยัง Mobile App และ การ Upload รูปไปยัง AWS S3
นี่หมายถึงการ Implement Feature ใหม่ใน Project เราสามารถคัดลอก Code บางส่วนจาก Project เก่า ๆ และทำการแก้ไขมันที่จำเป็น ด้วยวิธีนี้ทำให้เราสามารถพัฒนา Web Applications ได้อย่างรวดเร็ว
แม้ว่า PHP จะมีข้อบกพร่องอยู่บ้าง แต่มันก็ดีพอที่จะเป็นเครื่องมือในการสร้าง Product ที่ตรงตามความต้องการของลูกค้าได้
นอกจากนี้ยังมีการถกเถียงกันว่า เราควรเลิกใช้ jQuery ที่ทั้งเก่าและดี แล้วหันมาใช้ vanilla JavaScript ดีหรือไม่?
บางคนไม่ชอบใช้ jQuery ก็เพราะมันต้อง Load Library ขนาด 30kb (minified และ gzipped) เมื่อทำการ Load Webpage พวกเขาสนับสนุนให้ใช้ vanilla JavaScript เนื่องจากมันสามารถสร้าง Web Applications ที่มีน้ำหนักเบาและ Load ได้เร็วขึ้น
แต่เมื่อพิจารณาถึงความนิยมของ jQuery แล้ว Developers ส่วนใหญ่ที่อยู่รอบตัว Tan Le Tian เองกลับคุ้นเคยกับ jQuery มากกว่า พวกเขาสามารถทำสิ่งต่าง ๆ ด้วย jQuery ได้อย่างรวดเร็วด้วย การใช้ Library ขนาด 30kb นั้นดูจะคุ้มค่ากว่าเมื่อแลกกับความเร็วในการ Develop ที่สูงขึ้น
นอกจากนี้ ทำไมเราถึงไม่ใช้ Frameworks ที่ใหม่และเจ๋งกว่า อย่าง React.js หรือ Angular.js ล่ะ?
ในกรณีของ Tan Le Tian เอง Project ส่วนใหญ่ที่เขาทำ เกี่ยวข้องกับ Inventory Management Systems ที่ถูกใช้งานภายใน บริษัทของลูกค้าเอง ซึ่ง jQuery ดูเหมือนจะดีเพียงพอที่จะ Implement Features ทั้งหมดตามที่ลูกค้าต้องการได้
การใช้ JavaScript Frameworks เพื่อสร้าง Single Page Application อาจสร้าง User Experience ที่ดีขึ้น แต่มันทำให้ความรู้สึกว่า มันมากเกินไปสำหรับ Web Application ขนาดเล็กที่ใช้งานโดย Admin ของบริษัทแค่ไม่กี่คน
นั่นกล่าวได้ว่า เราไม่ได้ต่อต้านการใช้เทคโนโลยีใหม่ ๆ เราจะไม่ลังเลที่จะใช้ JavaScript Frameworks ที่ทันสมัย หากลูกค้าของเราต้องการ Dynamic Web Application ที่มี Frontend Feature ที่ซับซ้อน
สรุป
การเป็น Software Engineer นั้น มากกว่าแค่การเขียน Code และความท้าทายที่แท้จริงอยู่ที่การเข้าใจปัญหาที่ลูกค้ากำลังเผชิญอยู่ จากนั้นก็พัฒนา Solution ภายใน Budget และ Deadline ที่กำหนด
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://medium.com/