เราทุกคนล้วนมีพฤติกรรมทั้งด้านดีและไม่ดี แม้แต่เรื่องของ Programming ก็ไม่มีข้อยกเว้น แต่หากคุณได้รู้ถึงพฤติกรรมที่ไม่ดีของคุณตั้งแต่เนิ่น ๆ คุณจะได้รีบปรับปรุงมัน และหากคุณแก้ไขได้ ไม่เพียงแต่ส่งผลกระทบต่อตัวคุณเองเท่านั้น แต่ยังส่งผลถึงบุคคลรอบข้างที่ทำงานกับคุณด้วย ดังนั้นเรามาดู 6 Programming Habits ที่ลดประสิทธิภาพของคุณ
1. ต้องเข้าร่วมประชุม(บ่อย)
ในบางสถานการณ์ การประชุมก็เป็นตัวทำลาย Productivity ได้เช่นกัน และคงมี Developers หลายคนที่ต้องเข้าร่วมประชุมบ่อย(มาก) เมื่อพูดถึงการประชุม ทำให้แบ่ง Developers ได้เป็น 2 กลุ่ม
Developers กลุ่มแรก จะพยายามเลี่ยงการประชุมให้ได้มากที่สุดเพื่อใช้เวลาอยู่กับ Keyboard เพราะพวกเขาคิดว่าการประชุมส่วนใหญ่มักใช้เวลานานและมันน่าจะดีกว่าที่จะใช้เวลาเหล่านั้นเพื่อทำงานที่ต้องทำจริง ๆ
Developers กลุ่มที่ 2 ค่อนข้างตรงข้ามกับประเภทแรก คือ พวกเขาจะใช้ทุกโอกาสที่มีเพื่อเข้าร่วมประชุมทุกครั้ง
หากคุณพบว่า ตัวเองกำลังอยู่ในกลุ่มที่ 2 คุณจะสูญเสียเวลาไปอย่างมาก แทนที่คุณจะได้มีเวลาเขียน Code และทำงานให้เกิด Productivity
การประชุมส่วนใหญ่มักถูกกำหนดเวลาไว้ที่ 1 ชั่วโมง(ในเบื้องต้น) แม้ว่า Agenda จะถูกจัดให้อยู่ในเวลาน้อยกว่าครึ่งชั่วโมง อันที่จริงเราสามารถขอปฏิเสธเข้าร่วมประชุมได้ในหลาย ๆ โอกาส หรืออาจจะขอให้จัดการประชุมในช่วงบ่ายเพื่อที่คุณจะสามารถทำงานได้ในช่วงเช้า หรืออีกอย่างคือ อาจขอปฏิเสธการประชุมที่ใช้เวลานานมาก ๆ แต่ก่อนที่คุณจะปฏิเสธ ก็ต้องพิจารณาถึงความจำเป็นในด้านอื่น ๆ ประกอบด้วย
2. Over-Engineering
Over-Engineering (การทำอะไรที่เกินกว่าความจำเป็น) เป็นหนึ่งในสิ่งที่ Developers หลายคนมักจะมี เมื่อดูไปที่ Codebase มีแนวโน้มสูงที่คุณมักจะพบ Code บางส่วนที่เป็น Over-Engineering
สิ่งที่เห็นได้จาก Over-Engineering คือ คุณมักออกแบบ Product ของคุณให้มีความซับซ้อนมากเกินความจำเป็น อย่างที่เรามักจะเห็น ๆ กันใน Codebase คือ Developers มีการเพิ่ม Code ในสิ่งที่คิดว่าอาจจะเป็นประโยชน์ต่อพวกเขาในอนาคต โดย Code ส่วนที่เพิ่มเข้ามานี้ อาจไม่เคยถูกใช้งานเลยด้วยซ้ำ เพราะมันมักเป็นการคาดการณ์/คาดเดาของ Developers เอง หรืออีกมุมหนึ่ง สามารถเรียกได้ว่า เป็น Code ที่ที่สร้างขึ้นเพื่อใช้แก้ปัญหาที่ไม่มีอยู่จริง
Over-Engineering อาจทำให้ Developers ไขว้เขวจนลืมไปว่า หน้าที่หลักของ Code นั้น ถูกออกแบบมาเพื่อให้ทำอะไรกันแน่ ซึ่งแน่นอนว่า ต่อไปมันอาจทำให้ใช้งานยาก และไม่ได้ทำรู้สึกว่า Code/Product นั้นดูฉลาดแต่อย่างใด
3. เขียน Data Structures เป็นของตัวเอง
การเขียน Data Structures เป็นของตัวเองนั้น ถูกจัดให้อยู่ในหมวดหมู่ของการ สร้าง/คิดค้นในสิ่งที่มีคนสร้างไว้อย่างดีแล้ว (Reinventing the Wheel) สิ่งนี้บั่นทอนประสิทธิภาพของการทำงานอย่างยิ่ง Data Structures ทั้งหมดที่คุณต้องการมันมีอยู่แล้ว และพร้อมใช้งาน ดังนั้น คุณไม่จำเป็นต้องเสียเวลาสร้างมันขึ้นมาใหม่และ Data Structures ก็ไม่ได้เป็นเพียงตัวอย่างเดียวที่ Developers พยายามที่สร้างขึ้นมาด้วยตัวเอง บ่อยครั้งที่ Developers มักจะสร้าง Code ขึ้นมาใหม่ (ทั้งที่มี Code เดิมอยู่แล้ว)
หากคุณมี Code แบบเดียวกันอยู่แล้ว และคุณก็รู้ว่ามันเสถียรรวมทั้งได้รับการ Maintain อย่างดี คุณก็ควรใช้ Code นั้น บางที Code ที่คุณเขียนขึ้นมาอาจไม่มีอะไรใหม่เพิ่มขึ้นมาเลย หรือที่แย่ไปกว่านั้นคือ Features บางอย่างดันขาดหายไป เวลาคุณเขียน Code ขึ้นมาใหม่ อย่าลืมว่ามันอาจมี Bugs หรือข้อจำกัดบางอย่างเกิดขึ้น
แต่ใช่ว่าการ Reinventing the Wheel จะมีแต่ด้านแย่เสมอไป มันอาจมีประโยชน์ในกรณีที่คุณต้องการทำความเข้าใจในบางสิ่งให้ลึกยิ่งขึ้น แต่บ่อยครั้งที่หลายคนหมดกำลังใจไปซะก่อนเพราะมันใช้เวลาค่อนข้างมาก สำหรับกรณีอื่น ๆ ก็เช่น งานชิ้นหนึ่งมีความสำคัญมากซึ่งหากทำผิดพลาดก็จะส่งผลเสียตามมา ทำให้การ Reinventing the Wheel ไม่ใช่ตัวเลือกที่ดีที่สุดของคุณ
4. ทำอะไรที่ไม่สอดคล้องกัน (Inconsistency)
ความสอดคล้องกัน ถือเป็นกุญแจสำคัญในการพัฒนา Software ปัญหาเกี่ยวกับความไม่สอดคล้องนั้นมาจากความจริงที่ไม่สามารถหลีกเลี่ยงได้ว่า ยิ่งเวลาผ่านไป Software จะยิ่งล้าสมัย ยิ่ง Software มี Code ที่ยาวและซับซ้อน และยิ่งมีคนทำงานกับมันมากเท่าไร ก็ยิ่งมีแนวโน้มจะเกิดปัญหามากขึ้นเท่านั้น
เป็นการดีที่เราได้ทราบว่าความสอดคล้องกัน จะส่งผลกระทบอย่างมากต่อการ Maintain Codebase ของคุณ โดยเฉพาะในระยะยาว หากคุณตัดสินใจที่จะตั้งชื่อตัวแปรของคุณเป็นแบบ Camel Case (เช่น productName, productPrice) ก็ขอให้คุณยึดรูปแบบนั้นให้เหมือนกันหมด หรือหากต้องการใช้ Space แทน Tab ใน Code ของคุณก็ขอให้ทำแบบเดียวกันทั้งหมด
5. ไม่มีการวางแผน
ในช่วงที่เริ่ม Coding Project อาจดูน่าตื่นเต้นในช่วงแรก แต่ความตื่นเต้นนั้นอาจทำให้คุณเสียเวลา หากคุณมุ่ง Code เฉพาะในส่วนของคุณ คุณจะไม่เห็นภาพกว้างของ Project เลย
Code ของคุณควรถูกวางแผนและจัดระเบียบก่อนที่จะเริ่มเขียน คุณจะจัดการปัญหานี้ได้อย่างไร? คุณจะใช้ Structure ไหนในการ Implement? เป้าหมายโดยรวมทั้งหมดที่คุณกำลัง Implement อยู่คืออะไร?
ทั้งหมดนี้เป็นตัวอย่างคำถามที่ยอดเยี่ยมที่ควรจะถามตัวคุณเองก่อนที่คุณจะเริ่ม Coding และคำถามเหล่านี้ทำให้คุณตระหนักถึงความจริงที่ว่ามีหลายอย่างที่ต้องคิดก่อนที่จะเขียน Code
เมื่อคุณล้มเหลวในเรื่องการวางแผน สุดท้ายคุณอาจจะพบว่ามี Features บางอย่างที่ไม่ตรงตามความต้องการของลูกค้า หรือแย่กว่านั้นก็คือ Solution ของคุณไม่ถูกต้อง ซึ่งส่งผลให้คุณต้องกลับมาที่ Code นั้นในภายหลังแล้วทำการแก้ไขมันซะใหม่ ซึ่งบบนี้ถือว่าไม่มีประสิทธิภาพ
6. ไม่รู้จักขอความช่วยเหลือจากผู้อื่น
Developers ทุกคน ไม่ว่าจะมีประสบการณ์มากแค่ไหนก็ตาม ย่อมเคยติดขัดในการทำงานกันมาแล้วทุกคน เมื่อคุณตกอยู่ในสถานการณ์นั้น มันเป็นเรื่องสำคัญที่คุณจะต้องรีบ Feedback ให้คนอื่นที่เกี่ยวข้องได้ทราบ
การขอความช่วยเหลือไม่ได้หมายความว่า คุณเป็นคนไม่มีความสามารถ แต่คนอื่น ๆ จะคิดว่าคุณไม่มีความสามารถ หากคุณกำลังจ้องมองที่หน้าจอของคุณ แล้วดิ้นรนอยู่กับปัญหาเดียว นานเป็นเวลาหลายชั่วโมง
ก่อนที่คุณจะขอความช่วยเหลือจากใคร ก็ควรตรวจสอบให้แน่ใจก่อนว่า คุณได้ตรวจสอบทุกสิ่งเท่าที่คุณรู้ทั้งหมดแล้ว เพราะการที่คุณรบกวน Developers คนอื่นโดยที่ไม่จำเป็นนั้น ไม่ใช่สิ่งที่คุณควรจะทำนัก
บ่อยครั้งที่ Developers คนอื่นไม่สามารถช่วยเหลือหรือผลักดันคุณให้ไปในทิศทางที่ถูกต้อง แต่ด้วยวิธีนี้จะช่วยให้คุณประหยัดเวลาได้มาก เพราะคุณสามารถทำงานของคุณได้อีกครั้งแทนที่จะมานั่งหาคำตอบด้วยตัวเองไปเสียทั้งหมด
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่