Screen Shot 2558-04-13 at 10.55.23 PM
จาก Bliki เรื่อง CodeAsDocumentation ของคุณ Martin Fowler
ได้ทำการอธิบายได้อย่างน่าสนใจ
ผมจึงนำมาแปลนิดๆ หน่อยๆ ตามที่ผมเข้าใจ

หนึ่งในส่วนหลักของการพัฒนา software
นั้นก็คือการ coding หรือ programming นั้น
ควรถูกยกให้เป็นหัวใจ หรือ ตัวหลักของการพัฒนา software กันเลย
เนื่องจาก เราในสนใจเรื่องนี้กันน้อยมากๆ !!

ลองคิดดูว่า

คุณพัฒนา software ไปเพื่ออะไร ?
ระหว่างการมี process ที่ดี หรือ การได้ software ที่ดีออกมา ?

ส่วนหลักคือ code ที่ออกมา
แต่ไม่ได้บอกว่า code นั่นคือ เอกสารที่ดีนะ !!
แต่หลายๆ คนอาจจะบอกว่า code นั่นแหละคือ เอกสารที่ดีที่สุด
แต่ principle ต่างๆ เช่น Extreme Programming (XP) ไม่ได้กล่าวไว้เช่นนั้น
สิ่งที่กล่าวไว้ก็คือ

“เอกสาร หรือ document จะเป็นส่วนเพิ่มเติม หรือ เติมเต็มให้กับ code ด้วย”

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

ดังนั้น ผลที่ตามมาก็คืออะไรล่ะ ?

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

แต่เรามักจะพบว่า Code มันแย่
ดังนั้น เราจึงได้ code ที่เป็นเอกสารแย่ๆ ออกมา
ซึ่งนั่นอาจจะไม่ใช่ข้อสรุปที่ถูกต้องมากนัก
เนื่องจาก ทำไมเราไม่ทำให้ code มันดีขึ้นล่ะ ?
ไม่ทำให้ code มันอ่านง่าย เข้าใจง่าย และ ชัดเจนล่ะ ?
และเราก็ไม่ทำ เพราะอะไรนะ ?

หรืออาจจะเป็นเพราะว่า …

ตั้งแต่เริ่มเรียนเขียน code ไม่มีใครบอก หรือ สอนเราหรือเปล่า ?
ไม่มีใครบอกว่า การทำให้ code มันดี มีความสำคัญอย่างไร ?
ไม่มีใครบอกว่า การทำให้ code มันดี ทำอย่างไร ?
ไม่มีใครบอกว่า code ที่มันดีๆ มันมีคุณค่ามากน้อยเพียงใด ?
ไม่มีใครพูดเรื่อง code ที่ดีเลยหรือเปล่า ?

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

ดังนั้น สิ่งที่คุณควรทำต่อไป คือ การเรียนรู้ (Learning)

โดยขอแนะนำหนังสือ ที่แจ่มๆ
ซึ่งนักพัฒนาทุกๆ คนควรอ่าน และนำไปใช้งาน ดังนี้

  • Code complete เพื่อทำให้เข้าใจว่าการ coding ที่ดีเป็นอย่างไร
  • Refactoring :: Improving the Design of Existing Code เพื่อทำให้ code มันเข้าใจง่าย อ่านง่ายมากขึ้น
  • จากนั้นให้อ่าน Refactoring to Pattern ต่อเลย ขอบอกว่าแจ่มมากๆ

จากสิ่งที่อธิบายมานั้น ย่อมมีหลายๆ คนที่ไม่เห็นด้วย

แต่ให้จำไว้ว่าทีมคือ เจ้าของ code ไม่ใช่ใครคนใดคนหนึ่ง มันคือของทุกๆ คนในทีม
นั่นคือเรื่อง Collective Code Ownership ที่ทุกๆ คนต้องฝึก และ ปฏิบัติ
สามารถนำพวก pair programming มาใช้ได้นะ

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