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

ไม่ค่อยได้เขียนเล่าถึงการทำงานเลย 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 ต่อไป

โลกสวยด้วยความอยุติธรรม

พอดีน้องหยีโพสลิงค์กระทู้พันทิพย์น่าสนใจอันนึงบน Facebook ที่มีหัวข้อว่า
 ทฤษฏีลูกเป็ดตัวสุดท้าย .. คนโสดควรอ่าน ^____________^
ลองอ่านกันดูเองนะครับ

พอผมอ่านจบ เลื่อนลงไปอ่าน comment ของเพื่อนอรุชแล้วรู้สึกว่าตรงความคิดมาก อรุช บอกว่า

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

ผมคิดว่าอย่างงี้ครับ

ชอบ ความเห็นของอรุชมาก จนแค่กดไลค์ไม่พอ

บทความนี้เป็นการปลอบใจที่ฟังเข้าหู แต่ควรใช้กับคนระดับจะกินยาฆ่าตัวตายเท่านั้น
แนวคิดว่า “สิ่งที่ฉันไม่ได้เป็นสิ่งที่ไม่คู่ควรกับฉัน” มันไม่ใช่วิธีคิดที่ถูกที่ควรเอามาสอนคนเลย

น้องหยีก็มาบอกว่า

ฮ่า ๆ มันก็เป็นแค่คำปลอบใจอ่ะ, อ่านละโลกสวยดีนะ

ผมโพสไปอีกว่า

โลกเราจะสวยตลอดเวลา ถ้าเราเข้าใจความอยุติธรรมของโลกครับ

แล้วน้องบอกว่าไม่เข้าใจ ผมเลยอธิบายเพิ่ม

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

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

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

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

เราจึงควรสอนคนให้อยู่กับความทุกข์ ไม่ใช่หาเรื่องเบี่ยงเบนความทุกข์ครับ (อย่างที่บอกว่า ยกเว้นเคสร้ายแรงจริงๆ บางครั้งก็ต้องใช้วิธีการหลอกบ้าง)

[Presentation review] How To Approach Refactoring

เนื้อความไม่มีอะไรใหม่ แต่ผู้พูด พูดได้ดี สนุกและเข้าใจง่ายมาก

ข้างล่างนี้ เป็นข้อความที่ฟังแล้วโดนใจ

To write a good code, we need to understand that we can’t write a good code at the first sit.

– ลด Ego ตัวเองให้หมด รับฟัง comment คนอื่นอยู่เสมอ แล้ว code คุณจะออกมาดี

A software that need to be maintained is a successful software, otherwise you threw it away.

I became a programmer because scientific programming, I’m still a programmer today because the art of programming.

– อันนี้ส่วนตัวโดนเต็มๆ สำหรับผมการเขียนโปรแกรมยังสนุกอยู่เพราะมันไม่มีวิธีการตายตัว

ช่วงตั้งแต่นาทีที่ 34:20 เค้าอธิบายถึงเรื่อง long method มีวิธีการอธิบายกับเพื่อนร่วมงานที่ชอบเขียน method ยาวๆ ได้น่าสนใจทีเดียว