16 Programming Skills ที่มหาวิทยาลัยไม่ได้สอนคุณ
หลักสูตรของมหาวิทยาลัยมีรากฐานการเขียน Code ที่ดี แต่การเขียน Program ในโลกแห่งความเป็นจริงจำเป็นต้องมีทักษะนอกเหนือจากในห้องเรียน บทความนี้จะสำรวจแนวปฏิบัติที่สำคัญของอุตสาหกรรมไอที เช่น Automated Testing, Code Reviews และ ซึ่งมีความสำคัญต่อความสำเร็จทางวิชาชีพ กับ 16 Programming Skills ที่มหาวิทยาลัยไม่ได้สอนคุณ
1. การเขียน Code ที่บ้าน ช่วยให้เกิดการเรียนรู้ด้วยตนเอง ในขณะที่การเขียน Code ที่บริษัทจะเกี่ยวกับการทำงานร่วมกัน และการแก้ปัญหาในโลกแห่งความเป็นจริง ซึ่งประสบการณ์เหล่านี้เสริมซึ่งกันและกัน แต่ไม่สามารถแทนกันได้
2. Testing นั้นมีความสำคัญมาก สำหรับ Software Development เพื่อให้มั่นใจถึงฟังก์ชันการทำงาน Developer จะต้องทดสอบ Code อย่างละเอียดโดยใช้การทดสอบแบบ Automated เพื่อไม่ให้เสียเวลา (ประกอบด้วย Unit Test, Integration Test, Performance Test, การจำลองการใช้งานจริง และ Stability Test เป็นต้น)
3. PR/Code Review, Automation สำหรับ Build & Run Test ช่วยเพิ่มคุณภาพและความมั่นใจ เมื่อทำ Refactoring (การจัดองค์ประกอบและโครงสร้างภายในของ Software ใหม่) โดยไม่ต้องกลัวว่าฟังก์ชันการทำงานที่มีอยู่จะเสียหาย
4. Monitoring และ Alerting ถือเป็นสิ่งสำคัญใน Production เพื่อให้สามารถตรวจจับ Error, Case ที่ผิดปกติ และรายงานปัญหาเหล่านี้ได้ทันที ซึ่ง Error เหล่านี้สามารถกระตุ้นให้เกิดการแจ้งเตือน เพื่อให้สามารถตรวจพบและแก้ไขปัญหาได้ (ลดผลกระทบต่อ User และรักษาคุณภาพการบริการในระดับสูง)
5. วิธีการเขียน Code ที่เราเรียนรู้จาก มหาวิทยาลัย หนังสือ หรือ Tutorials นั้นแตกต่างจากการเขียน Code ใน Project ในโลกแห่งความเป็นจริง สำหรับการเรียนรู้ มักจะเน้นที่ตัวอย่างพื้นฐาน เช่น โปรแกรม “Hello World” หรืองานที่ซับซ้อนกว่าเล็กน้อย ในขณะที่ปัญหาที่แท้จริงคือ ความท้าทายในการทำความเข้าใจ Framework และ Methodology เป็นต้น หรือเมื่อนำไปใช้กับ Codebase ขนาดใหญ่และซับซ้อน Code นี้จะสามารถพัฒนา แก้ไข และดูแลรักษาโดยทีมงานได้ง่ายหรือไม่เมื่อเวลาผ่านไป
6. Framework และเทคโนโลยีใหม่ ๆ ส่วนใหญ่ไม่ได้นำเสนอพื้นฐานที่สำคัญ นอกเหนือจากตัวอย่างพื้นฐาน “Hello World” และ Tutorials เพื่อดึงดูด Developer เท่านั้น โดยมีเพียงเล็กน้อยที่จะสร้างมูลค่าที่แท้จริง ดังนั้นเป็นสิ่งสำคัญสำหรับ Developer ที่จะต้องแยกแยะระหว่างความก้าวหน้าที่สำคัญและแนวโน้มที่ทำให้เสียเวลา (ตราบใดที่มีการเปลี่ยนแปลงทางเทคโนโลยีที่สำคัญอยู่เป็นประจำถึง 95%) ดังนั้น ขึ้นอยู่กับคุณแล้วที่จะเรียนรู้ที่จะแยกแยะระหว่างสิ่งที่จำเป็น และอุปกรณ์เสริม
7. ควรใช้เครื่องมือที่มีอยู่ เช่น Google และ StackOverflow เพื่อหลีกเลี่ยงไม่ให้เกิดปัญหา และแสวงหาแนวทางแก้ไขที่ดีกว่า ซึ่ง Developer ควรค้นหา Code ที่มีประสิทธิภาพ และอ่านง่าย แทนที่จะสร้างขึ้นมาใหม่ตั้งแต่ต้น ดังนั้นควรหลีกเลี่ยงการ “สร้างวงล้อใหม่” หรือเพียงเพื่อการฝึกฝน โดยใช้ Libraries และ Code มาตรฐานที่มีอยู่แล้ว และผ่านการทดสอบอย่างดีทุกครั้งที่เป็นไปได้ การเขียน Code แบบกำหนดเองควรเป็นทางเลือกสุดท้าย และเมื่อจำเป็น ควรเขียนให้ชัดเจนและกระชับเท่าที่จะเป็นไปได้
8. บน Google หรือเว็บไซต์ต่าง ๆ มีคำตอบที่ยอดเยี่ยมและมีประสิทธิภาพอยู่แล้ว สำหรับปัญหาต่าง ๆ ที่คุณอาจกำลังประสบปัญหาอยู่ อย่ามั่วรอเป็นวันหรือชั่วโมงเพื่อหาคำตอบ ลองค้นหาว่ามีใครแนะนำวิธีแก้ไขปัญหานั้น ๆ บนออนไลน์ หรือถามหัวหน้าหรือเพื่อนร่วมงานจะดีกว่า
9. ควรให้ความสำคัญกับการเขียน Code ที่ชัดเจน เรียบง่าย และเข้าใจง่าย เนื่องจาก Code นั้นมีการแก้ไขอยู่บ่อยครั้ง ดังนั้น ไม่ควรเขียน Code ที่ใช้ตรรกะที่ซับซ้อนเกินไป หรือมีการคาดเดามากเกินไป เนื่องจากอาจทำให้ผู้อื่นสับสน โดยเฉพาะผู้ที่จำเป็นต้องตรวจสอบหรือแก้ไขในภายหลัง ดังนั้นควรเขียน Code ให้สามารถดูแลรักษาและเข้าใจได้ง่ายในอนาคต
10. Integrated Development Environment (IDE) ที่ดี ช่วยให้สามารถ Navigate ผ่าน Code ได้ทันที ลดความซับซ้อนในการปรับโครงสร้างใหม่ ช่วยระบุ Bug ที่อาจเกิดขึ้น และทำให้การ Run Unit Tests และการ Debug มีประสิทธิภาพมากขึ้น ไม่แนะนำให้ใช้วิธีการพื้นฐาน เช่น การเพิ่ม Print/cout Lines หรือการอัปเดตการเรียกใช้ Method หลายวิธีด้วยตนเอง ดังนั้น Developer ควรใช้ประโยชน์จากเครื่องมือและฟีเจอร์อันทรงพลังของ IDE อย่างเต็มที่ เพื่อปรับปรุง Workflow และประสิทธิภาพการทำงาน
11. Code ที่คุณเขียนเป็นทรัพย์สินส่วนรวม ดังนั้น ทุกคนในทีมมีสิทธิ์ในการแก้ไข ปรับโครงสร้างใหม่ หรือพัฒนา Code เพิ่มเติม ดังนั้น คุณจึงไม่ควรเปลี่ยนแปลง Code เพียงเพื่อให้ตรงกับความต้องการส่วนตัวของคุณเท่านั้น
12. Code มีอยู่ 2 ประเภท 1) Code ใหม่ ที่ออกแบบมาอย่างดี ซึ่งดูสวยงามแต่ไม่ได้ผลเสมอไป 2) Code เก่า ที่ดูยุ่งเหยิง หรือทดสอบได้ไม่ค่อยดี แต่สามารถใช้งานได้จริง ประเด็นสำคัญคือ การแก้ปัญหาของลูกค้าจะไม่ได้เป็นเพียงการใช้การออกแบบที่สะอาดตาหรือ Algorithm พื้นฐานเท่านั้น แต่จำเป็นต้องมีการจัดการกรณีเฉพาะ ข้อยกเว้น และเงื่อนไขทั้งหมดที่มักจะบิดเบือนการออกแบบและทำให้ Code ไม่สามารถอ่านได้ แต่มันเป็นสิ่งจำเป็น และเป็นสิ่งที่ทำให้การพัฒนา Software มีค่าใช้จ่ายสูง
การสร้างโปรแกรมแก้ไขข้อความอย่างง่ายนั้น ค่อนข้างง่าย แต่การสร้างสิ่งที่ครอบคลุมเช่น Microsoft Word ซึ่งตอบสนองความต้องการของ User ทุกคนและรองรับทุกรูปแบบนั้นต้องใช้ทรัพยากรและการลงทุนจำนวนมาก
13. Code ทั้งหมด รวมถึงการทดสอบ และ Code ที่ออกแบบมาเป็นอย่างดี ถือเป็นภาระรูปแบบหนึ่ง เมื่อ Software มีขนาดใหญ่ขึ้น ความซับซ้อนของ Software ก็เพิ่มขึ้นเป็นทวีคูณ ทำให้มีค่าใช้จ่ายในการพัฒนาและบำรุงรักษาสูงขึ้น ทุกฟีเจอร์ไม่ว่าจะใช้งานอยู่หรือไม่ก็ตาม ล้วนเป็นการเพิ่มภาระ
คำแนะนำคือหลีกเลี่ยงการเขียน Code ที่ไม่จำเป็น กำจัดฟีเจอร์ที่ไม่ได้ใช้ และเก็บ Code ให้น้อยที่สุด จำเป็นอย่างยิ่งที่จะต้องแน่ใจว่าฟังก์ชันการทำงานใด ๆ ที่คุณเพิ่มเข้ามา ให้คุณค่ามากกว่าต้นทุนที่จะเกิดขึ้นในแง่ของการพัฒนาและการบำรุงรักษาอย่างมาก
14. ไม่ว่าจะเป็นการออกแบบ และ Documentation มีอยู่มากมายอยู่ในหัวของ Designer เมื่อตัวเลือกการออกแบบและเหตุผลอยู่ในหัวของ Designer คนเดิมเป็นหลักและขาดการสื่อสารที่ดี สมาชิกใหม่ในทีมอาจประสบปัญหาในการทำความเข้าใจตรรกะและการออกแบบของ Software ที่มีอยู่
หากทีมเปลี่ยนแปลงเร็วเกินไปหรือบ่อยเกินไป วิสัยทัศน์และแนวทางที่แตกต่างกันนี้ อาจนำไปสู่ Codebase ที่วุ่นวายและสับสน ซึ่งเปรียบเหมือนเป็น “จานสปาเก็ตตี้” ที่กลายเป็นเรื่องยากสำหรับทุกคนที่จะเข้าใจ การขาดความต่อเนื่องนี้อาจบ่อนทำลายความสอดคล้องและความเสถียรของ Software โดยเฉพาะอย่างยิ่งเมื่อทีมออกแบบเดิมไม่เกี่ยวข้องอีกต่อไป โดยทั่วไปแล้ว Software จะได้รับผลกระทบ
15. Code มักจะไม่ค่อยสมบูรณ์แบบในครั้งแรก และมักจะต้องใช้การจัดการกับปัญหาเดียวกันหลายครั้งเพื่อค้นหาวิธีแก้ปัญหาที่ดีที่สุด แม้ว่าโดยทั่วไป Software จะเขียนเพียงครั้งเดียวและไม่ค่อยเขียนใหม่หรือปรับปรุง แต่การประเมินและปรับแต่งการออกแบบใหม่ก่อนที่จะสรุปผลสามารถนำไปสู่ผลลัพธ์ที่ดีขึ้นได้
โดยส่วนมากไม่ได้กลับมาดูการออกแบบของตนอีกครั้ง ลองอ่านซ้ำและเปลี่ยนดีไซน์ก่อนส่ง แต่การจะทำแบบนี้ได้ก็ต่อเมื่อ Designer คนเดิมยังคงพร้อมที่จะใช้ประสบการณ์และสามารถให้คำแนะนำ ก็จะสามารถปรับปรุงคุณภาพของ Software ได้อย่างมาก
16. ไม่แนะนำให้ทำการเปลี่ยนแปลงแบบกว้าง ๆ หรือทั้งหมดในคราวเดียว แต่ควรปรับปรุงทีละน้อย เพื่อหลีกเลี่ยงการรบกวนฟังก์ชันการทำงานที่มีอยู่ แม้ว่าจะต้องมีการเปลี่ยนแปลงครั้งใหญ่ แต่ก็เป็นการดีกว่าที่จะค่อย ๆ ดำเนินการ ซึ่งลูกค้ามักชอบ Code ที่มีอยู่เดิมและใช้งานได้จริง แม้ว่าจะล้าสมัยและยุ่งเหยิง มากกว่า Code ที่ออกแบบใหม่ โดยใช้เทคโนโลยีล่าสุดที่ไม่ได้ทำงานตามที่ตั้งใจไว้
ดังนั้น การรักษาระบบการทำงานและการปรับปรุงอย่างค่อยเป็นค่อยไป โดยทั่วไปจะปลอดภัยกว่าและน่าเชื่อถือได้มากกว่าการเสี่ยงต่อความล้มเหลวด้วยการเปลี่ยนแปลงครั้งใหญ่
ISM เชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ ได้เปิดทำการมาแล้วกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2024 Blockdit
