ประสบการณ์ที่เก็บได้ตามทาง

ไม่ค่อยได้เขียนเล่าถึงการทำงานเลย blog นี้ขอเล่าๆ เรื่อยๆ ถึงสิ่งที่ตกผลึกช่วงนี้ละกันนะครับ

สาเหตุ code เน่าที่เห็นบ่อยๆ

1. Copy-Paste แล้วไม่ DRY code

คนที่มีความใส่ใจใน code บ้างจะรู้ถึงจุดนี้ และก็จะแก้โดยการ extract method/function ซึ่งก็ถือว่าโอเคในระดับนึง แต่หลายๆ ครั้งเราก็จะมอง duplication ระหว่างไฟล์กันไม่ออก และ extract กันไม่เป็น แต่บางครั้งทำแล้วก็ไปเจอข้อ 2 อีก

2. เพิ่มfeature/แก้ bug โดยการมองหาจุดเหมาะๆใน code แล้ว แทรก code เข้าไปดื้อๆ

วิธีการแบบนี้เป็นวิธีการที่เห็นได้บ่อยทีเดียว

ถ้าทำบ้าง ก็พอรับได้ แต่ถ้าเป็น code ที่โดนเรียกใช้จากหลายจุดแห่ง แล้วเรามีการลงไปเพิ่ม codition ให้ support ความแตกต่างของแต่ละจุดเยอะขึ้นๆ เมื่อไหร่ จับต้นชนปลายไม่ถูกแน่ครับ อาการนี้แก้ได้ด้วย การ refactor เป็นวิธีที่ทุกคนรู้จักกันดี Strategy pattern ครับ ดึงส่วนต่างออกมารวมกันเป็นกลุ่มก้อนไว้ซะ

 

Rewrite code ความพ่ายแพ้ในกระบวนการพัฒนาซอฟแวร์

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

ผมเชื่อว่าถ้าเรามีทักษะการ Refactoring ที่ดีพอ, automate regression test ที่ครอบคลุมและ knowledge transfer ที่ดีในองค์กรแล้ว เราจะสามารถ maintain และ evole code เดิมๆ ของเราไปได้เรื่อยๆ โดย code อยู่ในสภาพที่ดี ไม่ใช่ legacy code ที่ไม่อยากไปแตะต้องด้วย

 

การพัฒนาโปรแกรม ให้ไม่นำชีวิตไปสู่ความลำบาก สอนกันไม่ได้

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

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

ส่วนการให้เรียนรู้ด้วยวิธีการสอน ผมเห็นมาแยกได้เป็น 2 กลุ่มดังนี้

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

 

การต่อสู้เพื่อสิ่งที่(เราคิดว่า)ถูกต้องในการทำงาน

ผมเป็นคนไม่ชอบการทะเลาะทุกประเภท จึงพยายามหลีกเลี่ยงมาโดยตลอดด้วยการเป็นฝ่ายยอม แต่แล้วจนวันหนึ่งผมก็รู้ว่าการกระทำแบบนี้ถือเป็นการกระทำที่ไม่เป็นมืออาชีพ (เคยพูดถึงนิดหน่อยแล้วที่ วิถีมืออาชีพ)

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

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

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

 

ทักษะการพูดอันต้อยต่ำ

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

  • ทักษะการพูดภาษาอังกฤษที่ห่วย
  • การเรียงร้อยประโยค จับประเด็นสำคัญ
  • ความน่าศรัทธา
  • น้ำเสียงอารมณ์ พูดเล่นพูดจริง

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


คุณภาพของ code แปลผกผันกับขนาด story

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

กลายเป็นว่าเราก็จะแก้ๆ ให้ code พอผ่าน test ด้วยมือนิดหน่อย แล้วก็ปิดงานทันที ไม่ได้ปัดกวาดหรือเช็คกรณีต่างๆ ที่ต้อง test อย่างละเอียดเลย

เรื่องนี้ต้องใช้ 2 วิธีร่วมกันแก้

  • พยายามเขียน story เล็กๆที่สุดเท่าที่จะทำให้มันยังคงความครบถ้วนสมบูรณ์ในตัวเองอยู่ได้ โดยปกติแล้วมันมักจะใหญ่เกินอยู่เสมอๆ
  • สร้างคำว่า ‘เสร็จ’ เล็กๆ ส่วนตัวขึ้นมา โดยทำเป็น task เล็กๆ ใน story ที่สามารถ ทำ, เขียน test และ refactor ได้ พอทำเสร็จแล้วก็ commit มันเข้าไปซะ ถึง feature หลักจะยังไม่เสร็จก็ตาม แล้วก็ไปเดินเล่นพักหน่อย แล้วก็กลับมาเริ่มทำ task ต่อไป
Advertisements

One thought on “ประสบการณ์ที่เก็บได้ตามทาง

  1. Pingback: ย้อนกลับไปมองความคิดในเรื่องการพัฒนาซอฟแวร์ | Tap

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s