| Topic 53 | Pride and Prejudice |
|---|
คุณทำให้เราประทับใจมานานพอแล้ว
Jane Austen, Pride and Prejudice
Pragmatic Programmer จะไม่เลี่ยงความรับผิดชอบ แต่เรากลับภูมิใจที่ได้รับความท้าทายใหม่ๆ และยินดีที่จะแสดงศักยภาพของเราออกมา หากเรารับผิดชอบงานออกแบบหรืองานเขียน Code เราจะทำมันอย่างสุดฝีมือเพื่อให้เราภูมิใจกับมันได้จริงๆ
| Tip 97 | Sign Your Work |
|---|
เหล่าช่างฝีมือในสมัยก่อนต่างก็ภูมิใจที่ได้ลงชื่อกำกับผลงานของตัวเอง คุณเองก็ควรภูมิใจเช่นกัน
อย่างไรก็ตาม Team โปรเจกต์ต่างๆ ก็ยังคงประกอบไปด้วยผู้คน และกฎข้อนี้อาจจะทำให้เกิดปัญหาได้ในบางโปรเจกต์ แนวคิดเรื่อง Code Ownership อาจจะทำให้เกิดปัญหาในการร่วมงานกัน ผู้คนอาจเริ่มหวงแหนพื้นที่ของตัวเอง หรือไม่เต็มใจที่จะทำงานร่วมกันในส่วนที่เป็นพื้นฐานส่วนกลาง จนท้ายที่สุดโปรเจกต์อาจจะกลายเป็นเหมือนอาณาจักรเล็กๆ ที่แยกตัวออกจากกัน คุณเริ่มมีอคติโดยเข้าข้าง Code ของตัวเองและต่อต้านเพื่อนร่วมงาน
นั่นไม่ใช่สิ่งที่เราต้องการ คุณไม่ควรปกป้อง Code ของตัวเองจนไม่ยอมให้ใครเข้ามายุ่ง ในทางกลับกัน คุณควรให้เกียรติ Code ของผู้อื่นด้วยเช่นกัน กฎทองอย่างการ “ปฏิบัติต่อผู้อื่นเหมือนที่คุณอยากให้เขาทำกับคุณ” และรากฐานความเคารพซึ่งกันและกันในกลุ่ม Developer เป็นเรื่องสำคัญมากที่จะทำให้ Tip นี้ได้ผลจริง
การไม่เปิดเผยชื่อ (Anonymity) โดยเฉพาะอย่างยิ่งในโปรเจกต์ขนาดใหญ่ อาจกลายเป็นบ่อเกิดของความสะเพร่า ข้อผิดพลาด ความเฉื่อยชา และ Code ที่ไม่มีคุณภาพได้ง่ายๆ มันทำให้เรามองตัวเองเป็นแค่ฟันเฟืองเล็กๆ ชิ้นหนึ่ง และมักจะสร้างข้อแก้ตัวที่ฟังไม่ขึ้นในรายงานความคืบหน้าที่ไม่มีวันจบสิ้น แทนที่จะเป็นการเขียน Code ที่ดี
แม้ว่า Code จะต้องมีเจ้าของ แต่ไม่จำเป็นต้องเป็นเจ้าของคนเดียว อันที่จริง แนวคิด eXtreme Programming [84] ของ Kent Beck ก็แนะนำเรื่อง Communal Ownership ของ Code อยู่แล้ว (แต่ต้องมีแนวปฏิบัติอื่นควบคู่ไปด้วย อย่างเช่น Pair Programming เพื่อป้องกันอันตรายจากการไม่เปิดเผยชื่อคนรับผิดชอบ)
เราอยากเห็นความภาคภูมิใจในความเป็นเจ้าของ ประมาณว่า “ฉันเขียนอันนี้เอง และฉันกล้ายืนยันในงานของตัวเอง” ลายเซ็นของคุณควรได้รับการจดจำในฐานะตัวบ่งชี้ของคุณภาพ เมื่อใครเห็นชื่อคุณบน Code ชิ้นหนึ่ง เขาควรคาดหวังได้ว่ามันจะมีความแข็งแรง (Solid), เขียนมาอย่างดี, ผ่านการ Test และมีการทำ Documentation ที่ครบถ้วน นี่แหละคืองานระดับมืออาชีพที่เขียนขึ้นโดยมืออาชีพจริงๆ
A Pragmatic Programmer.
ขอบคุณครับ
Footnotes
เมื่อขนาดของ Team ใหญ่ขึ้น ช่องทางการสื่อสารจะเพิ่มขึ้นในอัตรา 
โดยที่ 
คือจำนวนสมาชิกในทีม ในทีมที่ใหญ่ขึ้น การสื่อสารจะเริ่มล้มเหลวและไร้ประสิทธิภาพ
Burnup chart นั้นดีกว่า Burndown chart แบบที่ใช้กันทั่วไป เพราะด้วย Burnup chart คุณจะสามารถเห็นได้อย่างชัดเจนว่า Feature ที่เพิ่มเข้ามาใหม่นั้นทำให้เส้นชัย (Goalposts) ของเราเลื่อนออกไปอย่างไร
ทีมควรสื่อสารกับภายนอกด้วยเสียงเดียวกัน (One voice) แต่ภายในทีม เราสนับสนุนอย่างเต็มที่ให้มีการโต้แย้งที่สร้างสรรค์และมีชีวิตชีวา เพราะ Developer ที่ดีมักจะมีความหลงใหล (Passionate) ในงานของตัวเอง
Andy เคยเจอทีมที่จัด Daily Scrum Standup ในวันศุกร์ (ซึ่งมันไม่ควรจะเป็นแบบนั้น)
ดูที่ https://en.wikipedia.org/wiki/Cargo_cult
เราเคยเห็นสิ่งนี้มากับตาตัวเอง (First-hand) บ่อยครั้งกว่าที่คุณคิดเสียอีก
https://netflix.github.io/chaosmonkey
หากสนใจการศึกษาที่น่าสนใจเกี่ยวกับความสัมพันธ์ระหว่าง Test Coverage และจุดบกพร่อง (Defects) ลองดูที่ _Mythical Unit Test Coverage_ [ADSS18]
อย่าลืม Topic 3 เรื่อง _Software Entropy_ เป็นอันขาด ย้ำว่าต้องจำให้ขึ้นใจ
http://www.extremeprogramming.org
Copyright © 2020 Pearson Education, Inc.
ในระยะยาว เราเป็นผู้กำหนดชีวิตและหล่อหลอมตัวตนของเราเอง กระบวนการนี้ไม่มีวันสิ้นสุดจนกว่าเราจะตาย และการตัดสินใจเลือกสิ่งต่างๆ ท้ายที่สุดแล้วมันคือความรับผิดชอบของเราเอง
Eleanor Roosevelt
ในช่วงยี่สิบปีก่อนหน้าที่จะออกฉบับพิมพ์ครั้งแรก เราได้ร่วมเป็นส่วนหนึ่งของวิวัฒนาการของคอมพิวเตอร์ จากที่เคยเป็นแค่เรื่องน่ารู้น่าสนใจเล็กน้อย กลายมาเป็นสิ่งจำเป็นพื้นฐานของธุรกิจในปัจจุบัน และในอีกยี่สิบปีให้หลัง Software ก็ได้เติบโตไปไกลเกินกว่าจะเป็นแค่ระบบงานออฟฟิศ และได้เข้าไปครอบครองโลกนี้อย่างแท้จริง แต่นั่นหมายความว่าอย่างไรสำหรับเรากันแน่?
ในหนังสือ _The Mythical Man-Month: Essays on Software Engineering_ [Bro96] Fred Brooks เคยกล่าวไว้ว่า “Programmer ก็เหมือนกับกวี ที่ทำงานห่างจากสสารทางความคิด (Pure thought-stuff) เพียงเล็กน้อยเท่านั้น เขาสร้างปราสาทกลางอากาศจากความว่างเปล่า ด้วยการทุ่มเทพลังแห่งจินตนาการลงไป” เราเริ่มต้นจากหน้ากระดาษที่ว่างเปล่า และเราสามารถสร้างสรรค์สิ่งใดก็ตามที่เราพอจะจินตนาการออก และสิ่งที่เราสร้างขึ้นมานั้นก็สามารถเปลี่ยนโลกได้
ตั้งแต่ Twitter ที่ช่วยให้ผู้คนใช้ในการวางแผนปฏิวัติ ไปจนถึง Processor ในรถยนต์ของคุณที่คอยป้องกันไม่ให้รถลื่นไถล และ Smartphone ที่ทำให้เราไม่ต้องมาคอยนั่งจำรายละเอียดจุกจิกในแต่ละวันอีกต่อไป โปรแกรมของเราอยู่ทุกหนทุกแห่ง จินตนาการของเราเองก็อยู่ทุกหนทุกแห่งเช่นกัน
พวกเราเหล่า Developer ถือว่าได้รับสิทธิพิเศษอย่างมาก เรากำลังสร้างอนาคตขึ้นมาจริงๆ มันคืออำนาจที่มหาศาล และด้วยอำนาจนั้นเองก็นำมาซึ่งความรับผิดชอบที่ยิ่งใหญ่เหนือธรรมดา
เราหยุดคิดถึงเรื่องนี้บ่อยแค่ไหนกัน? บ่อยแค่ไหนที่เราได้พูดคุยกัน ทั้งในหมู่พวกเราเองและกับบุคคลทั่วไป ว่าสิ่งนี้หมายความว่าอย่างไร?
อุปกรณ์ฝังตัว (Embedded devices) ใช้คอมพิวเตอร์มากกว่าที่ใช้ใน Laptop, Desktop และ Data Center เป็นสิบเท่า คอมพิวเตอร์ฝังตัวเหล่านี้มักจะควบคุมระบบที่มีความสำคัญถึงชีวิต ตั้งแต่โรงไฟฟ้าไปจนถึงรถยนต์และอุปกรณ์ทางการแพทย์ แม้แต่ระบบควบคุมความร้อนส่วนกลางหรือเครื่องใช้ไฟฟ้าในบ้านง่ายๆ ก็สามารถคร่าชีวิตคนได้หากมันถูกออกแบบหรือนำไปใช้งานมาไม่ดีพอ เมื่อคุณพัฒนาอุปกรณ์เหล่านี้ คุณกำลังรับความรับผิดชอบที่หนักอึ้งจนน่าตกใจ
ระบบอื่นๆ ที่ไม่ใช่ Embedded จำนวนมากก็สามารถสร้างได้ทั้งคุณประโยชน์มหาศาลและโทษมหันต์ Social Media สามารถส่งเสริมการปฏิวัติอย่างสันติหรือปลุกปั่นความเกลียดชังที่น่ารังเกียจก็ได้ Big Data สามารถช่วยให้การเลือกซื้อของง่ายขึ้น แต่ก็สามารถทำลายร่องรอยของความเป็นส่วนตัวที่คุณคิดว่าคุณยังมีอยู่ได้เช่นกัน ระบบธนาคารมีการตัดสินใจเรื่องการอนุมัติเงินกู้ที่เปลี่ยนชีวิตผู้คนได้ และแทบจะทุกระบบสามารถถูกใช้เพื่อสอดแนม (Snoop) ผู้ใช้งานได้
เราได้เห็นร่องรอยของความเป็นไปได้ที่จะเกิดอนาคตในอุดมคติ (Utopia) และตัวอย่างของผลกระทบที่ไม่ได้ตั้งใจซึ่งนำไปสู่โลกที่เลวร้ายราวกับฝันร้าย (Dystopia) ความแตกต่างระหว่างผลลัพธ์ทั้งสองแบบนั้นอาจจะแนบเนียนกว่าที่คุณคิด และทั้งหมดนี้อยู่ในมือของคุณแล้ว