คนส่วนใหญ่ซึ่งไม่ใช่โปรแกรมเมอร์?รู้ว่างานพัฒนาซอฟแวร์คืองานยาก แต่คงนึกภาพการทำงานไม่ออก

โดยโปรแกรมเมอร์ใน Quora และ Ubuntu Forums ได้ร่วมกันแชร์ความรู้สึกว่า งานยากสุดที่ต้องทำคืออะไร และทาง IT Word ได้ประมวลผลออกมาเป็น “9 งานยากสุดของโปรแกรมเมอร์”?ซึ่งข้อมูลคิดมาจาก 4,522 โหวต

จริง ๆ แล้ว ผลสำรวจออกมาตั้งแต่เดือนตุลาคม ปี 2013 แต่เท่าที่อ่านดู ก็ไม่ล้าสมัยเลยทีเดียว

เชื่อหรือไม่ ผลสำรวจ การเขียนโปรแกรมไม่ใช่งานยากที่สุด?แต่เป็นการตั้งชื่อยากสุด ซะงั้น …

Photo Credit By :http://jasonshultz.com/programmings-hardest-tasks/

1) การตั้งชื่อ (49%)

การตั้งชื่อพวก variables, procedures, functions, classes, objects, database components และอื่น ๆ
แม้ว่าโปรแกรม จะมีขนาดเล็กก็ตาม แต่การตั้งชื่อสามารถตั้งได้หลากหลาย
ซึ่งจะทำยังไง ให้การตั้งชื่อ มันใช้ได้ทั้งโปรแกรมและมีความกระชับ
นับว่าเป็นงานท้าทายสำหรับโปรแกรมเมอร์ (เรียกว่าคะแนนทิ้งข้ออื่นขาดลอยทีเดียว)

2) อธิบายให้คนอื่นรู้ว่า เราทำอะไร (หรือไม่ทำอะไร) (16%)

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

3) การประมาณเวลางานที่จะเสร็จ (10%)

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

4) การทำงานร่วมกับผู้อื่น (8%)

ถ้าให้โปรแกรมเมอร์ไปเก็บ Requirements จากลูกค้า หรือเตรียมทำรายงานความคืบหน้าเสนอผู้บริหาร
รวมทั้งทำงานกับ Tester และปรึกษาหารือกับคนอื่นในโปรเจค ก็จะมีปัญหา
เพราะการอธิบายเรื่องเทคนิค แก่คนอื่นที่ไม่รู้เทคนิค ยิ่งต้องมาทำงานด้วยกันแล้ว นับว่าเป็นอุปสรรคอย่างหนึ่ง
และบางครั้งความคิดเห็นก็ขัดกันกับทีม QA และโปรแกรมเมอร์คนอื่น ๆ

5) การแก้ไขโค้ดคนอื่น (8%)

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

6) สร้างฟังก์ชันที่เราไม่เห็นด้วย (3%)

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

7) การเขียนเอกสาร (2%)

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

8) การเขียน Test (2%)

การเขียน Unit Test (เป็นกระบวนการทดสอบโปรแกรม ในส่วนของโค้ดเพียงบางส่วนเล็ก ๆ เพื่อให้แน่ใจว่าฟังก์ชั่นทำงานถูกต้อง)

การเทสเหล่านี้ ช่วยให้เจอบั๊ก ตั้งแต่เริ่มต้นกระบวนการพัฒนาซอฟแวร์ และอำนวยความสะดวกกับการทำ Regression Testing เมื่อโค้ดมีการแก้ไขหรืออัพเดตภายหลัง

กระบวนการพัฒนาซอฟแวร์บางอย่าง เน้นให้เทสก่อนเขียนโค้ด ในขณะที่บางวิธีให้เขียนเทสหลังโค้ดเสร็จ

ซึ่งกระบวนการพวกนี้ มันน่าเบื่อ เพราะต้องเลือกเขียนเทสเคส แถมต้องเขียนโค้ดด้วย จนรู้สึกว่างานมันเพิ่มขึ้น นอกจากสร้างโปรแกรม

9) การออกแบบ เพื่อแก้ปัญหา(2%)

ถ้าให้ Requirements มา แล้วให้แก้ปัญหาด้านเทคนิค ไม่ว่าจะเป็นการออกแบบ และการวาง Architect ของระบบ รวมทั้งการออกแบบฐานข้อมูล โครงสร้างโค้ด อัลกอริทึมการทำงาน และ Flow ของโปรแกรม ซึ่งมีทั้ง Business logig และมี Use Case ร่วมด้วย

แน่ใจหรือว่า การออกแบบเพื่อแก้ไขปัญหา ของเหล่าโปรแกรมเมอร์ จะตรงกับ Requirements ของลูกค้า มีความสมเหตุสมผล และสร้างโปรแกรมได้ทันเวลา

อ้างอิง?http://www.itworld.com/

เขียนโดย แอดมินโฮ โอน้อยออก