See the original English version of this article here
ในการเขียน Program นั้น มีบทเรียนมากมายให้คุณได้เรียนรู้จากการประสบการณ์การทำงานจริง และในบทความนี้คุณ Juan Cruz Martinez จะมาบอกถึง 9 บทเรียนชีวิต Programmer ที่ได้สัมผัสด้วยตัวเอง มาให้คนไอทีให้ทราบกัน
1. สิ่งที่ ราคาถูกที่สุด เร็วที่สุด และน่าเชื่อถือที่สุด ไม่มีอยู่จริง
นี่คือสิ่งที่ Gordon Bell เคยกล่าวไว้ บทเรียนที่จะกล่าวถึงคือ คุณควรพยายามทำให้ System หรือส่วนของ Software ของคุณให้เรียบง่ายที่สุดเท่าที่พอจะทำได้ และพยายามลดความซับซ้อน เพื่อลดจำนวน Bugs ที่อาจจะเกิดขึ้นด้วย
2. Voodoo Coding
บางครั้งคุณก็สามารถแก้ Bugs ได้ โดยที่ไม่ทราบสาเหตุอย่างแท้จริงว่าทำไมถึงแก้ Bugs ได้ Programmer ส่วนใหญ่น่าจะเคยเจอสถานการณ์นี้ อันที่จริงคุณควรจะเข้าใจ Code ของคุณเสียก่อน แล้วลองหาดูว่าเหตุใดสิ่งที่คุณได้ลองทำ (ไม่ว่าจากการคาดเดา ลองผิดลองถูก ถามคนอื่น หรือ Copy & Paste) ถึงสามารถแก้ไขปัญหาหรือ Bugs เหล่านั้นได้
Mindset นี้อาจช่วยสอนคุณได้มากกว่าสิ่งที่เขียนไว้ในหนังสือ และจงอย่าอายที่จะถามคนอื่นถ้ามันเป็นเรื่องที่จำเป็นต้องถาม ในบางครั้งคุณจะเห็นได้ว่า คนอื่นก็จะกลับมาถามสิ่งต่าง ๆ จากคุณเช่นกัน
เช่นเดียวกันกับ Code ที่ Copy-Paste มา แน่นอนว่าพวกเราแทบทุกคนเคยใช้ Stack Overflow หรือหาข้อมูลจาก แหล่งข้อมูลต่าง ๆ ซึ่งคุณไม่จำเป็นต้องรู้สึกอายในเรื่องนี้เลย แต่ตราบใดที่คุณไม่เข้าใจ Code ที่เขียนอยู่อย่างแท้จริง ก็อย่าเพิ่งใช้วิธีข้างต้นหรือขอความช่วยเหลือจากคนอื่น
การสร้างหรือใช้งาน Code ที่คุณไม่เข้าใจ เรียกอีกอย่างว่า Voodoo Coding มันเป็น Bugs ที่รอวันจะเกิดขึ้น
3. Code ไม่เคยโกหก และบางครั้งก็ควร Comment
อันที่จริง Comment ก็ถือเป็นส่วนที่สำคัญ แต่คุณก็ไม่จำเป็นต้อง Comment ใด ๆ หากคุณเขียน Code ที่สามารถอธิบายตัวมันเองได้เป็นอย่างดีอยู่แล้ว
การ Comment ใน Code มักเป็นจุดที่ถูกมองข้ามในขณะที่คุณเปลี่ยนแปลงแก้ไข Code ทำให้บางกรณี Comment กลับกลายเป็นสิ่งที่ไม่ตรงกับความเป็นจริง เนื่องจากคุณแก้ไข Code แล้ว แต่ลืมแก้ไข Comment เดิมที่เคยถูกเขียนไว้
เรามาดู 3 สิ่งที่จะช่วยให้คุณเขียน Code ที่อธิบายตัวมันเองได้:
-
- ใช้ Comment ภายใน Code ของคุณ
- เขียนอธิบาย ใน Document ที่แยกออกมาต่างหาก
- เขียน Code เหล่านั้นด้วยตัวคุณเอง
- แต่จะขออธิบายเพิ่มเติมในประเด็นสุดท้ายให้ชัดเจนยิ่งขึ้น:
การมีการออกแบบที่ดี จะช่วยทำให้ Codebase ของคุณ ใช้งานง่ายและมี Structure ที่มี Logic ถูกต้องเหมาะสม
อย่าพยายามประหยัดการใช้ตัวอักษรจนเกินไป บางครั้งก็ควรใช้ชื่อเต็ม ๆ สำหรับ Variables, Classes และ Functions ของคุณ เช่น แทนที่จะใช้ wm ก็ให้ตั้งชื่อเป็น windowManager แทนที่จะเรียกว่า rf ให้เรียกว่า readFileToString เพราะชื่อแบบนี้จะช่วยให้คุณเข้าใจมากกว่า ในกรณีที่คุณหรือคนอื่น ๆ กำลังทำความเข้าใจว่า Code ทำงานอย่างไร หลังจากที่ไม่ได้แตะ Code นี้มาเป็นเวลานาน ๆ
แยกย่อยการทำงานให้มากที่สุดเท่าที่จะทำได้ลงใน Function และทำให้ Function เหล่านั้นทำหน้าที่เพียงแค่อย่างเดียว และตั้งชื่อ Function ตามหน้าที่ของมัน เช่น สร้าง Function ที่ชื่อว่า readFileToString (String fileName) เพราะแม้จะไม่ได้อ่าน Code โดยละเอียด แต่ชื่อดังกล่าวก็ทำให้รู้ได้ว่ามันทำอะไร และถ้าจำเป็นจริง ๆ คนอ่าน Code ก็สามารถลงไปดูรายละเอียดใน Code ได้ นั่นหมายถึงว่า Code ดังกล่าวสามารถอธิบายตัวมันเองได้ว่ามันทำอะไร
4. Regular Expressions
เมื่อเจอกับปัญหา บางคนอาจคิดว่า “ฉันรู้ ฉันจะใช้ Regular Expressions” ตอนนี้กลายเป็นว่า พวกเขามีปัญหา 2 อย่าง
มันอาจดูตลก แต่ก็เป็นเรื่องจริง เพราะบางครั้ง Regular Expressions ก็สร้างปัญหาให้คุณได้ คุณอาจจะคิดว่าคุณสามารถทำได้อย่างถูกต้องสำหรับกรณีนี้ แต่มันอาจจะใช้ได้เพียงแค่ 70% ของกรณีอื่น ๆ ที่คุณเจอก็เป็นได้
นี่เป็นเพียงความคิดเห็นเท่านั้น คือ ถ้าไม่จำเป็นจริง ๆ ก็ขอแนะนำให้หลีกเลี่ยงการใช้ Regular Expressions บ่อยครั้งที่การใช้งาน Functions ต่าง ๆ ร่วมกันอย่าง Split, substring, endsWith, indexOf และอื่น ๆ ก็อาจได้ผลลัพธ์ที่ต้องการและช่วยทำให้ Code ของคุณอ่านได้ง่ายขึ้น
5. Software Is Like Cathedrals
The Cathedral and the Bazaar เป็นหนังสือที่เปรียบเทียบ Development Models ที่แตกต่างกัน 2 แบบ ดังที่ Wikipedia กล่าวไว้:
“Cathedral Model: เป็นแนวคิดที่ว่า Software ที่สำคัญ ๆ ควรถูกสร้างและจำกัดไว้สำหรับกลุ่ม Software Developers กลุ่มหนึ่งโดยเฉพาะเท่านั้น
Bazaar Model: Code ของ Software ควรได้รับการพัฒนาผ่าน Internet ในมุมมองที่เป็นของสาธารณะ โดย Linus Torvalds หัวหน้าโครงการ Linux kernel ถูกมองว่าเป็นผู้คิดค้น Process นี้”
ทั้ง 2 Models มีทั้งข้อดี-ข้อเสีย อย่างไรก็ตาม เป็นที่ยอมรับกันโดยทั่วไปว่า Software เป็นสิ่งที่ต้องมี Development Process ที่ซ้ำ ๆ โดยที่ Function การทำงานจะค่อย ๆ ถูกเพิ่มเข้ามาทีละน้อย โดยเฉพาะอย่างยิ่ง End-User จะมีส่วนร่วมใน Development Process ตั้งแต่ช่วงต้น ๆ
6. ราคาถูก, เร็ว, เชื่อถือได้: คุณเลือกเอาแค่ 2 อย่าง
เชื่อว่า นี่คือสิ่งที่หลายคนคงจะเข้าใจว่ามันหมายถึงอะไร
คุณต้องการทั้ง เชื่อถือได้และรวดเร็ว: คุณสามารถทำได้ แต่คุณจะต้องแลกกับการจ้าง Developers ที่เก่งมาก ๆ
คุณต้องการทั้ง ราคาถูกและเร็ว: แน่นอนว่าทำได้ แต่อย่าคาดหวังในเรื่องความน่าเชื่อถือหรือถูกต้อง ให้มากนัก
คุณต้องการทั้ง เชื่อถือได้และราคาถูก: ถ้าคุณโชคดีคุณก็อาจได้ทั้ง 2 สิ่งนี้ แต่คุณอาจต้องใช้เวลามากขึ้นในการค้นหา Developers ที่สามารถทำได้ในราคาถูก หรือบางทีจะต้องมีการทำซ้ำ ๆ หลายครั้ง (ดังนั้น จึงต้องใช้เวลามากขึ้น) เพื่อให้มันถูกต้องและน่าเชื่อถือ
7. มี 2 สิ่งที่ยากใน Software Engineering
0. Naming things
1. Cache invalidation
2. Off-by-one errors
มนุษย์เรามักจะเริ่มนับจากหนึ่ง แต่ในทาง Computer จะเริ่มต้นที่ศูนย์ ข้อเท็จจริงง่าย ๆ นี้ เป็นสาเหตุของการเกิด Bugs และปัญหาต่าง ๆ ได้อีกมากมาย เป็นไปได้ว่าคุณก็อาจเป็นต้นเหตุของ Errors บางอย่างอยู่ก็ได้ หรือไม่ สักวันก็อาจมีใครสักคนที่ทำให้คุณมีส่วนร่วมในการทำให้เกิด Errors ได้เช่นกัน
8. Programmer ที่ดีจะมองหาทางเลือกหลายทาง ก่อนจะเลือกทางที่เหมาะที่สุด
Software ที่ดีที่สุด จะสามารถจัดการกับ Errors ทั้งหมดได้
Software ส่วนใหญ่ถูกเขียนขึ้นเพื่อให้เกิด “Happy Flow” ซึ่งทุกอย่างสามารถทำงานได้ตามที่คาดหวังไว้ และ Users ก็ทำในสิ่งที่ควรทำเท่านั้น แต่ในโลกของความจริงนั้นช่างยุ่งเหยิง และเมื่อเวลาผ่านไป สิ่งต่าง ๆ ที่มีแนวโน้มผิดพลาด ก็จะเกิดความผิดพลาดขึ้น คุณควรพยายามหา Errors ให้ได้มากที่สุดเท่าที่จะทำได้โดยเฉพาะอย่าง
ยิ่งเมื่อ Software ของคุณ ตอบสนอง Function การทำงานที่สำคัญ ๆ
9. การวัดความคืบหน้าของการเขียน Program ตามจำนวนบรรทัดของ Code ก็เหมือนกับการวัดความก้าวหน้าของการสร้างเครื่องบินตามน้ำหนัก
จำนวนบรรทัดของ Code ไม่ได้แปรผันโดยตรงกับความคืบหน้าใด ๆ และด้วยเหตุผลเดียวกัน การที่คุณเขียน Code มากกว่าคนอื่น ก็ไม่ได้หมายความว่า คุณมี Productivity มากกว่าคนอื่นแต่อย่างใด
Code ที่ดีที่สุด จะใช้จำนวนบรรทัดน้อยที่สุดเพื่อให้งานสำเร็จได้ และมันก็ไม่ใช่เรื่องง่ายที่จะเขียนได้แบบนั้นด้วย นี่คือ Software Principle ที่รู้จักกันดีที่เรียกว่า KISS – ย่อมาจาก “Keep It Simple, Stupid”
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 แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://medium.com/