นิสัยแย่ๆหรือเรื่องไม่ดีของนักพัฒนาซอฟแวร์

30 Jan 2020 TechnologySoftwareSoftware Development

My Life
Photo by Arian Darvishi / Unsplash

พอดีเห็นบทความน่าสนใจดีก็เลยนำมาเขียนบอกเล่าในมุมมองตัวเองบ้างครับ ใครสนใจรายละเอียด บทความ สรุปเรื่อง Bad Habits of Software Developers ไว้หน่อย

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

อ้าว สรุปง่ายหรือยากเนี่ย!

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

สิ่งที่พูดถึงในบทความพี่ปุ๋ยแบบหัวข้อใหญ่ๆ คือ

  1. ไม่มี Code Structure หรือ Code Standard
  2. ยังทำงานกันหามรุ่งหามค่ำ
  3. ขาดการเขียนเอกสารที่ดี
  4. ชอบ copy-and-paste โดยไม่เข้าใจ
  5. ไม่เขียน Test
  6. ทำงานหลาย project พร้อม ๆ กัน

มันทำให้ผมย้อนกลับมา reflect ดูตัวเอง ว่าตัวเองมีนิสัยแย่ๆเรื่องใดบ้าง และเราสามารถแก้ไขได้ยังไงบ้าง


1. ไม่มี Code Structure และ Code Standard

ข้อนี้ต้องบอกเป็นเรื่องดีสำหรับผม ที่สิ่งแรกที่ผมให้ความสำคัญเวลาเริ่มโปรเจ็ค คือโครงสร้าง Structure และ Standard ของมันครับ ผมมักจะมี Template หรือ Code Standard / Naming Convention เป็นพื้นฐานอยู่แล้ว แต่ละโปรเจ็คอาจจะมีกฎ มีอะไรต่างกันบ้าง แต่ก็อิงจากตัว Template เช่นกัน

แม้ว่าจะเป็นแค่โปรเจ็คเล็กๆ หรือทำคนเดียว ไม่มีโปรเจ็คไหนที่ผมไม่คำนึงถึงเรื่องนี้เลย อาจจะมีบ้าง ที่เป็นพวก Hackathon แบบรีบๆ อาจจะไม่ถึงขนาดต้องตาม Standard หรือ Structure สวยหรู ซึ่งบางที Tool หรือ Editor ก็ช่วยเราได้เช่นกัน

และแน่นอน การมี Template หรือ Standard แล้วตอนเริ่มต้น ก็ไม่ใช่ว่าจะต้องใช้แบบนั้นตลอด มันก็เปลี่ยนแปลงได้ตลอดอะแหละ เหมือนใจคน เอ๊ะไม่ใช่ละ ฮ่าๆ ถ้าเราเจอแนวทาง หรือโครงสร้างที่มันดี เราก็เปลี่ยน หรือตกลงกับในทีม สิ่งนี้ทีมรู้สึกว่าทำให้ Productivity ดีขึ้น หรือสิ่งนี้เราทำแนวเดียวกัน จะอ่านง่าย แก้ไขง่ายเป็นต้น

ผมว่ามันก็คงคล้ายๆกับการจัดบ้าน จัดของในบ้านเรานั่นแหละ หากเราวางไม่เป็นระเบียบ รกมากๆ อะไรอยู่ตรงไหนก็หาไม่เจอ จำไม่ได้ หรือบางทีก็ดูยาก โค๊ดก็เช่นเดียวกัน

2. ยังทำงานกันหามรุ่งหามค่ำ

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

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

ส่วนการทำงานดึกๆดื่นๆ บางทีก็เพราะ ตอนกลางคืนมัน Productivity ดีกว่าจริงๆ รวมถึงบางครั้ง กลางคืน ผมมักจะนั่งทำงาน หรือ Research มันก็จะเพลินๆ เวลาลองอะไรใหม่ๆ (แต่จริงๆผมว่าก็เหมือนกับตอนเราทำงานตอนกลางวันนะ เวลาเราทำงานเพลินๆ มันก็นั่งยาวๆ 2-3ทุ่ม เวลาผ่านไปเร็วมาก พอ เทียบตอนกลางคืน เวลาที่ใช้ก็ไม่ต่าง)

เมื่อก่อน ผมเคยทำงานหนักๆอยู่ช่วงนึง คือรับฟรีแลนซ์ แล้วก็ทำงานประจำด้วย 2ที่ เวลา 24 ชั่วโมง 16-18 ชั่วโมง ทำงานอะ คิดดู สุดท้าย คือการจัดการ การแบ่งเวลา มันเสียทั้งงานประจำ ทั้งงานฟรีแลนซ์เลย และคิดว่า คงไม่เอาอีกแล้ว ตอนนั้นทำแค่ 2 เดือน พอเลย รู้เลยว่าร่างกายไม่ไหว และไม่เห็นความจำเป็นต้องทำถึงขนาดนั้น พอโตมาก็ตระหนักได้ว่า ทำงานหนักไม่ได้แปลว่าเราขยัน เราควรทำงานโดยการวางแผนมากกว่า

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

Photo by Pankaj Patel / Unsplash

3. ขาดการเขียนเอกสารที่ดี

จริงๆ แล้วข้อนี้ก็ค่อนข้างสำคัญทีเดียว แต่ในเชิงของนักพัฒนาแล้ว ส่วนใหญ่ เริ่มต้นเลย ผมมักจะเขียน Doc เป็น README.md ง่ายๆไว้อ่าน อาจไม่ได้ละเอียดถึงขนาด Spec / Diagram / Flow อะไรหยุบหยิบ ซึ่งข้อดีของเอกสารนอกจากตัวเราเข้าใจ แล้ว เวลานักพัฒนาคนอื่นมาทำต่อ ก็สามารถอ่านเอกสาร และเข้าใจระบบ หรือโปรเจ็คได้ดีกว่า โปรเจ็คที่ไม่มีเอกสารแน่นอน

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

4. ชอบ copy-and-paste โดยไม่เข้าใจ

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

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

ผมไม่ได้มองแค่ Copy and Paste เท่านั้นนะ มองถึงการลองแนวการเขียน หรือวิธีการเขียน เช่น ระบบ Login ต้องเขียนแบบนี้ แบบนี้ๆ เราก็เริ่มจาก ทำตามคนอื่น จากนั้นก็เรียนรู้ แล้วก็ค่อยๆปรับปรุง แก้ไข พัฒนาตัวเองเรื่อยๆ นั่นเอง

ปัจจุบันถามว่าผม Copy Paste มั้ย ตอบเลยว่า ก็ทำอยู่นะ แต่ เรา Copy โดยเข้าใจมันมากขึ้น ไม่ใช่สมัยก่อน พอเรารู้ว่าเราจะแก้ปัญหายังไง เรารู้ว่ามันทำงานยังไง เรารู้ว่าโค๊ดนี้มันจะแก้ปัญหาอะไร เราก็แค่ copy มัน ไม่รู้จะเขียนหรือทำใหม่ขึ้นมาทำไม จริงมั้ย? เข้าคอนเซป DRY เลย ฮ่าๆ

5. ไม่เขียน Test

จริงๆข้อนี้ก็เป็นหนึ่งในข้อเสียผม อาจจะครึ่งๆละกัน ส่วนใหญ่ผมมักจะเขียนเทส แต่เขียนแบบไม่ได้ละเอียดมาก อาจจะมีแค่ Unit Test และ หรือฟังค์ชั่น ที่มันค่อนข้างซับซ้อน ส่วนโค๊ดอันไหนที่มันไม่ได้ซับซ้อนมาก ที่พอดูด้วยตา อ่านเข้าใจ ผมก็จะไม่เทสมัน แต่เมื่อเวลาพัฒนาไปซักพัก เราเจอส่วนที่ไม่เข้าใจเยอะขึ้น ผมก็จะเอาตรงนั้นไปเขียนเทส และผมก็ไม่ได้ยึดหลักการใดๆในการเขียน ไม่ว่าจะเป็น TDD / BDD การเขียนเทสก่อน ค่อยเขียนโค๊ด พอเทียบ Trade-off ซึ่งมันมีต้นทุน มีข้อดี ข้อเสีย ทุกอย่างอยู่แล้ว ผมจึงมองว่า การเขียนเทสของผม ขอแค่ทำให้เรามั่นใจงาน หรือโปรแกรมของเรา ก็พอแล้ว

6. ทำงานหลาย project พร้อม ๆ กัน

ข้อนี้ต้องบอกเลยว่าเป็นเรื่องของ Management ล้วนๆเลย และที่ผมพบเจอมา ก็จะเจอลักษณะคล้ายๆกันหมดเลย คือ ไม่มีการจัดเรียงลำดับความสำคัญ ทุกอย่างด่วน ทุกอย่างสำคัญหมดเลย และถ้าเลือกได้ คุณคิดว่า สำคัญ กับ ด่วน อันไหนควรทำก่อน?

แต่ถ้ามองในเรื่องการทำงานหลาย Project ไม่ได้มองด้าน Management อย่างน้อย ผมก็ว่ามันเป็นข้อดีสำหรับผม คือทำให้เราได้เปลี่ยนบรรยากาศ​ได้เปลี่ยน Role ตัวเอง เพราะแต่ละโปรเจ็ก ทั้งตัวโค๊ด ทั้ง Business ย่อมแตกต่างกัน และมีสิ่งที่ต้องเรียนรู้ ตลอด เราเป็นนักพัฒนา เราไม่จำกัดว่าควรจะรู้แค่ Software อย่าง ถ้าเราทำโปรดักเกี่ยวกับประกัน เราก็ต้องรู้ระดับนึง ว่ามันทำยังไง โปรเซสเป็นยังไง จริงไหม? แต่ไม่รู้ก็ได้ แต่มันจะทำให้เราพัฒนาโปรแกรมได้ดีกว่ามั้ย ถ้าเรารู้มัน ซึ่งมันก็ไม่ได้เสียหายอะไรที่ได้รู้เรื่องอื่นๆ เพิ่มนี่นา

เรื่องการ Management ผมพบว่า เป็นปัญหา Classic เอาไปเขียนเป็นบทความ คงได้เยอะแยะมากมาย มีหลายปัจจัย บางครั้ง ทำไมต้องทำหลายโปรเจ็ค เพราะ Resource ไม่พอ เรามีคนไม่พอ หรือเรามีพอ แต่คนเราไม่ได้คุณภาพ? แล้วถ้าเราคนไม่พอ ทำไมเราต้องรับงานมาหลายโปรเจ็ค? เพราะเราต้องการเงิน ขาดเงิน เร่งทำยอด? สุดท้าย มันก็เกี่ยวข้องกันไปหมด แต่เราก็น่าจะพอรู้ว่าสิ่งไหนจะกระทบเรามากที่สุด และถ้าเราจัดลำดับความสำคัญมันได้ รู้ว่าอะไรควรทำก่อน มันก็น่าจะแก้ปัญหาเหล่านี้ได้

สรุป

หลังจากที่ผมอ่านนิสัยแย่ๆ Bad Habits of Software Developers และมองย้อนดูตัวเอง ก็ทำให้เราตระหนักได้ว่า เราก็มีทำนิสัยแย่ๆเหมือนกัน และก็รู้ว่าสิ่งไหนที่เราควรจะหลีกเลี่ยง และเราสามารถหลีกเลี่ยง หรือแก้ปัญหา หรือแก้ไขนิสัยแย่ๆ เราได้หมด ผมว่าทุกคนตระหนักเข้าใจถึงปัญหากันหมดแหละครับ แต่จะมีคนที่ลงมือแก้ปัญหากันจริงๆซักกี่คน?

สวัสดี

❤️Happy Blogging


📝 Day 29 of #365DaysOfBlogging

#เขียนบล็อก #ฝึกสร้างนิสัย #GoodHabit #Blogging


Chai Phonbopit

เป็นนักพัฒนาซอฟแวร์ เวลาว่างนอกจาก Coding ก็จะเขียนบล็อกเกี่ยวกับสอนทำเว็บไซต์ สอน Programming ที่ devahoy.com ชื่นชอบการพัฒนาตัวเองและเชื่อว่าการสอนเป็นหนึ่งในวิธีการเรียนรู้ที่ดีที่สุด ❤️🎒🍣🎸⚽️

แสดงความคิดเห็น