[แปล] รู้ไหมว่างานอะไรที่ทำให้โปรแกรมเมอร์ปวดหัวกับมันที่สุด?

วันก่อนเปิดไปเจอ Arg! The 9 hardest things programmers have to do เข้า คิดว่าน่าสนใจดีเลยเอามาแปล

บทความพูดถึงสิ่งที่โปรแกรมเมอร์คือว่ามัน "ยากสุดๆ!!" ซึ่งเป็นการจัดอันดับโหวตกันมาของเว็บฝรั่ง เราก็มาดูกันละกันนะว่า 9 อันดับที่ทำให้โปรแกรมเมอร์ปวดหัวและเสียเวลามากที่สุดคืออะไรบ้าง

9 สิ่งที่ยากที่สุดที่โปรแกรมเมอร์จะต้องทำ

9. Designing a solution

ออกแบบวิธีการแก้ปัญหาตามที่ลูกค้า (หรือบอส) ต้องการ

ให้ requirements (ประมาณลูกค้าบอกว่า "ฉันอยากได้โปรแกรมแบบนี้ๆๆๆๆ อ่ะ") กับโปรแกรมเมอร์จำนวนหนึ่ง สิ่งที่โปรแกรมเมอร์จะต้องทำคือออกแบบโครงสร้างและเลือกวิธีการแก้ปัญหา ซึ่งมันจะประกอบด้วยหลายๆ สิ่งที่ลูกค้าชอบคือว่ามันง่ายมาก ทำไมเหรอ ยากตรงไหนกัน (แน่นอน! ยิ่งลูกค้าคิดว่ามันไม่เห็นมีอะไรเลย มันก็ยากขึ้นเท่านั้น)

โปรแกรมเมอร์จะต้องออกแบบตั้งแต่ tecnical solution ว่าจะใช้แผนการหรือใช้เครื่องมือแบบไหนดี ดีไซน์การเขียนโค้ด และโครงสร้างโปรแกรม แล้วยังมี algorithm และ functionอีก

และเหนือสิ่งอื่นใด ถ้าดีไซน์ไม่ดีตั้งแต่แก้ ทำไปเรื่อยๆ จะต้องมีการ "ชดใช้กรรมของตัวเอง" เกิดขึ้น คือเราดีไซน์มาไม่ดี ทำไปเรื่อยๆ จึงต้องตามแก้โค้ดเก่าๆ ที่เขียนมาด้วย

8. Writing tests

การเขียนเทสเคส

การเขียนโปรแกรมมักจะมาคู่กับการเขียน "เทสเคส" (สำหรับบริษัทใหญ่ๆ นะ) คือเราจะต้องเขียนโปรแกรมชนิดหนึ่ง เอามาเทสว่าโปรแกรมจริงๆ ที่เราเขียนมาเนี่ย มันทำงานถูกต้องมั้ยและบางครั้งมันก็ทำให้งานเราเพิ่มโดยไม่รู้ตัว แถมเทสบางตัวยังไม่ได้เขียนง่ายๆ อีกด้วย

และจะปวดหัวที่สุดเมื่อพบว่าเทสเคสที่เราเขียนขึ้นมา มันมีบั๊ก! แน่นอนว่าเราต้องมาตามแก้บั๊กจากเทสเคส แล้วก็เอาไปเทสหาบั๊กในโปรแกรมเราอีกที วุ่นวายเนอะ?

7. Writing documentation

เอกสารประกอบว่าโปรแกรมที่เราเขียนขึ้นมาใช้งานหรือมีโครงสร้างยังไง

โปรแกรมเมอร์ส่วนใหญ่เป็นสิ่งมีชีวิตที่ไม่ถนัดด้านภาษา (งานสายศิลป์) การเขียนโปรแกรมการจะไม่ใช่งานยากสำหรับโปรแกรมเมอร์บางคนแต่หลังจากเขียนโปรแกรมเสร็จต้องมานั่งทำงานเอกสารต่อว่าโปรแกรมที่คุณเขียนมาเมื่อกี้อ่ะ ทำงานยังไงบ้าง มันเป็นอะไรที่เลวร้ายมากเลยนะ

และหลายๆ ครั้งที่โปรแกรมได้รับการแก้ไขนิด แก้ไขหน่อย ถ้าบริษัทมีระบบว่าต้องทำเอกสารทุกครั้ง ก็แปลว่าคุณแก้โปรแกรมนิด คุณต้องไปนั่งเขียน doc ใหม่ด้วยนะ

6. Implementing functionality you disagree with

เขียนโปรแกรมที่เราไม่เห็นด้วยกับมัน

งานของเราต้องจัดการเขียนโปรแกรมที่เราไม่เห็นด้วยกับมันเลย โปรแกรมเมอร์อาจจะมองว่าโปรแกรมที่ลูกค้าอยากได้นักหนาเนี่ยมันไร้สาระมาก เขียนไปก็ใช้ไม่ได้ (แต่ลูกค้าจะเอา) แต่ก็ต้องก้มหน้าเขียนต่อไปด้วยความหงุดหงิด ไม่ว่าด้วยเหตุผลอะไร...ก็เขาเป็นคนจ่ายเงินนี่นา

5. Working with someone else’s code

ไปทำงานกับโค้ดของคนอื่น

โปรแกรมเมอร์แต่ละคนมักมีสไตล์การเขียนโค้ดที่แตกต่างกัน ถ้าเราไปเจอคนที่มีสไตล์การเขียนคล้ายๆ เราสัก 80% นี่ถือว่าโชคดีมากแล้วนะ

แต่โปรแกรมเมอร์ก็มักจะได้รับคำสั่งให้ไปแก้หรือไปเขียนโค้ดต่อจากโปรแกรมเมอร์คนอื่น มันไม่ใช่เรื่อยสนุกเลยนะ ประมาณว่าโดนสั่งให้ไปเขียนเรียงความต่อจากที่คนอื่นเขียนไว้แล้วประมาณครึ่งหน้าแล้วให้สำนวนการเขียนเหมือนที่เขาเคยเขียนมาแล้วด้วยนะ

4. Dealing with other people

คุยกับคนอื่น

แผนกอื่นๆ ในออฟฟิศมักจะบอกว่าคุยกับโปรแกรมเมอร์ไม่รู้เรื่อง รู้มั้ยว่าโปรแกรมเมอร์ก็คิดในใจว่าฉันคุยกับพวกแกก็ไม่รู้เรื่องเหมือนกันนั่นแหละ แม้แต่คุยกับเพื่อนโปรแกรมเมอร์ด้วยดันบางคนฉันยังคุยกับมันไม่รู้เรื่องเลย

สาเหตุก็เพราะสกิลด้านการใช้เหตุผลและโลจิคของโปรแกรมเมอร์มีเยอะ ดังนั้นสกิลด้านการสื่อสารเลยไม่ค่อยเยอะเท่าไหร่ (ฮา)

3. Estimating time to complete tasks

ประมาณว่าฉันจะใช้เวลาเท่าไหร่ในการทำงานนี้

ไม่ว่าใครก็ตามนะ สำหรับข้อนี้ ... การประเมินเวลาว่าเราจะใช้กี่ชั่วโมงหรือกี่วันในการทำงานที่ไม่เคยทำมาก่อนเป็นเรื่องยากมากที่จะกะให้ตรงได้ การเขียนโปรแกรมก็เหมือนกัน ไม่ใช่ว่าคุณบอกว่าเอาได้โปรแกรมแบบนี้ แล้วจะให้โปรแกรมเมอร์ตอบคุณได้ทันทีนะว่าฉันต้องใช้ทั้งหมด 5 วันในการทำ

2. Explaining what I do (or don’t do)

อธิบายว่าฉันกำลังทำอะไรอยู่ (หรือไม่ได้ทำอะไรอยู่) หืม..?

ยิ่งโค้ดซับซ้อน มันก็ยิ่งอธิบายยากขึ้นว่าโค้ดชุดนี้เอาไว้ทำอะไร ยิ่งมันผ่านการแก้บั๊กมาแล้ว 6 รอบ โครงสร้างโค้ดคุณเละไปแล้ว และตามข้อที่ 4 คือโปรแกรมเมอร์ไม่ถนัดในการสื่อสารกับคนอื่น บางทีกว่าจะอธิบายโค้ดให้เพื่อนเข้าใจว่าฉันเขียนอะไรมาก็ปาเข้าไปครึ่งวันได้

1. Naming things

ตั้งชื่อ...

คุณไม่ได้อ่านผิดหรอก "การตั้งชื่อ" ได้อันดับหนึ่งจริงๆ อย่าคิดว่ามันเป็นเรื่องง่ายๆ นะในการตั้งชื่อพวกตัวแปรในโปรแกรมเรา การตั้งชื่อที่คนอื่นมาอ่านโค้ดเราแล้วเขาเข้าใจได้ทันทีว่าตัวแปรนี้เก็บค่าอะไรอยู่โดยไม่ต้องสกรอลล์เมาส์กลับขึ้นไปดูข้างบนเป็นเหตุการที่ไม่ค่อยเกิดขึ้น

ตามหลักการแล้ว จะสร้างตัวแปรคุณต้องตั้งชื่อที่สื่อความหมาย แต่หลายๆ ครั้งมันก็รู้แค่ว่าตัวแปรนี้เราเก็บค่าประมาณนี้อยู่ แต่ดันไม่รู้จะใช้คำศัพท์ไหนมาเรียกมันดี

ส่วนใหญ่ (ยิ่งเวลารีบๆ) ตัวแปรในโปรแกรมเลยจบที่ x, y, z, a, b, c, i, j, num, count เป็นต้น (ฮา)