ใช้เวลา 6 วันในการเปลี่ยนโค้ดหนึ่งบรรทัด (2015)

 (edw519.posthaven.com)
2 คะแนน โดย GN⁺ 2023-07-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่ออัตราการเดินเครื่องของโรงงานลดลง 10% บริษัทจึงพยายามสะสมสต็อกก่อนช่วงไฮซีซันแทนการเลิกจ้าง และคำขอเพื่อเปลี่ยน ขีดจำกัด backlog 3 เดือน เป็น 4 เดือนก็เริ่มต้นขึ้น
  • หัวหน้าฝ่าย IT มองว่าแค่เปลี่ยน ค่าที่ hardcode ไว้หนึ่งค่าในรูทีนหลักก็พอ แต่ก่อนหน้านั้นต้องสร้าง ticket, ระบุผลกระทบทางธุรกิจ, ขออนุมัติ และปรับลำดับความสำคัญในคิวก่อน
  • โปรแกรมเมอร์เปลี่ยนค่า MonthsOfBacklog จาก "3" เป็น "4" ที่ line 1252 ของ Module ORP572 และผ่านการทดสอบแล้ว แต่ในการ code review กลับถูกกำหนดให้ต้องแก้การละเมิดนโยบายเดิมด้วย
  • ขอบเขตการเปลี่ยนแปลงขยายไปเป็น ขั้นตอนข้างเคียง เช่น การทำให้เป็นเรคคอร์ดในไฟล์ Parameters, การลบคำสั่ง debug, คำเตือนตัวแปรที่ไม่ได้กำหนดค่า, Employee ID ที่ hardcode ไว้, สิทธิ์การเข้าถึง, สภาพแวดล้อมทดสอบ, test plan และลายเซ็นผู้ใช้
  • การเปลี่ยนแปลงที่จำเป็นต่อธุรกิจมีเพียง 1 บรรทัด·1 ไบต์ แต่เวลาที่ผ่านไปทั้งหมดคือ 6 วัน โดยขั้นตอนและนโยบายภายในทำให้ lead time จริงของการเปลี่ยนแปลงเล็ก ๆ เพิ่มขึ้นอย่างมาก

คำขอเปลี่ยนขีดจำกัด 3 เดือนเป็น 4 เดือน

  • Philip ประธานบริษัทบอกว่าโรงงานอยู่ในสภาพ ไม่ได้เดินเครื่อง 10% และอยากผลิต backlog เพิ่มเพื่อสะสมสต็อกก่อนช่วงไฮซีซัน มากกว่าจะเลิกจ้างคน
  • Lee ผู้จัดการฝ่ายปฏิบัติการกล่าวว่า ตามนโยบายบริษัทสามารถสร้างได้สูงสุดเพียง backlog 3 เดือน ดังนั้นหากเปลี่ยนขีดจำกัดเป็น 4 เดือนก็จะมีงานเพียงพอ
  • David หัวหน้าฝ่าย IT เห็นว่าน่าจะแค่เปลี่ยนโค้ดหนึ่งบรรทัดในรูทีนหลักของซอฟต์แวร์ legacy และขอให้ส่ง ticket ไปยัง IT Services
  • Judy ผู้จัดการ IT จัดคำขอเป็น Ticket# 129281 แต่บอกว่าต้องมีส่วน Business Impact และการอนุมัติจาก Director
    • เมื่อ David พูดถึงความเป็นไปได้ที่จะมีการเลิกจ้าง Judy จึงกรอกส่วนนั้นเองและยกระดับให้ดำเนินการแบบเร่งด่วน
    • ผ่านไป 2 วัน คำขอยังคงอยู่ใน Developer Queue ในสถานะ Enhancement รายการแรก ต่อจาก Bug Report 14 รายการ
    • David สั่งให้ทำเครื่องหมายคำขอเป็น urgent และส่งให้ Ed ทันที

กระบวนการที่การเปลี่ยนหนึ่งบรรทัดขยายกลายเป็นการเปลี่ยนขั้นตอน

  • Ed เปลี่ยนตัวแปรที่ hardcode ไว้ MonthsOfBacklog จาก "3" เป็น "4" ที่ Module ORP572 line 1252
    • ผ่าน unit test และรัน batch test 2 รอบ
    • คิวงานของ Operations เพิ่มขึ้น 10% ตามคาด
    • การเปลี่ยนแปลงถูกส่งต่อไปยัง Code Review และ User Acceptance Testing ของ Homer
  • Shirley ผู้รับผิดชอบ code review ระบุว่าตัวแปรที่ hardcode ไว้ขัดกับนโยบายบริษัท และเรียกร้องให้ทำเป็นเรคคอร์ดในไฟล์ Parameters
    • เธอบอกว่าก่อนนำขึ้น production ต้องแก้คำสั่ง Debug เดิม 2 คำสั่ง, คำเตือนตัวแปรที่ไม่ได้กำหนดค่า และ Employee ID ที่ hardcode ไว้ด้วย
    • จุดยืนคือเมื่อ Ed ได้รับมอบหมาย ORP572 แล้ว เขาก็ต้องรับผิดชอบแม้กระทั่งข้อผิดพลาดเดิมที่ละเมิดนโยบายบริษัทฉบับใหม่
  • สภาพแวดล้อมทดสอบก็กลายเป็นปัจจัยทำให้ล่าช้า
    • Homer ใช้งานไม่ได้เพราะกำลังทดสอบการควบคุมการปิดบัญชีสิ้นเดือน จึงต้องใช้ Marge
    • Ed ไม่มีสิทธิ์เข้าถึง Marge และ Joe จาก IT Security บอกว่าจะให้สิทธิ์ไม่ได้หากไม่มีลายเซ็นของ David
  • งานเรคคอร์ด Parameters ขยายออกไปด้วยข้อกำหนดเพิ่มเติม
    • ชื่อ MonthsOfDemand ต้องมีชื่อที่ดีกว่า เพราะโปรแกรมเมอร์ต่างประเทศเข้าใจได้ยาก
    • Parameter record ใหม่ต้องมี audit trail แต่ไม่มีการจัดทำเอกสารนโยบายดังกล่าว และการอัปเดต wiki ก็ล่าช้าไป 3 เดือน
    • Ed เปลี่ยนชื่อเป็น SelectedMonthsOfBacklogDemand และเพิ่ม Module PAR634 เพื่อดูแลเรคคอร์ดดังกล่าวกับ audit trail
  • Tony ผู้รับผิดชอบการทดสอบชี้ว่าเห็น 129281 ใน Marge แต่ไม่มี Test Plan
    • Ed บอกว่าแค่รันทั้งแบบเดิมและแบบใหม่ แล้วตรวจสอบว่าปริมาณรวมในรายงาน WorkOrdersHours เพิ่มขึ้นก็พอ แต่ Tony บอกว่าสิ่งนี้ส่งผลต่อทั้งโรงงาน จึงต้องมี Test Cases ที่ผู้ใช้เลือก, Expected Results, Test Runs ที่จัดทำเป็นเอกสาร และ sign-off จากผู้ใช้
    • อีก 2 วันต่อมา Philip สั่ง David ให้ Tony ย้ายโปรแกรมของ Ed ขึ้น production ทันที
  • เวลาที่ผ่านไปทั้งหมดคือ 6 วัน และการเปลี่ยนแปลง mission critical code มีเพียง 1 บรรทัด·1 ไบต์
    • ใช้ Excedrin ไป 24 เม็ด
    • ระบุว่าเสียเวลาแบบหงุดหงิดกับ Hacker News ไป 14 ชั่วโมง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-17
ความคิดเห็นใน Hacker News

  • ประเด็นสำคัญคือผู้รีวิวเรียกร้องว่า “ถ้าจะเปลี่ยนตรงนี้ ก็ต้องแก้ปัญหาค้างคาอื่น ๆ ใน codebase ไปพร้อมกันด้วย”
    ในสถานการณ์แบบนี้ควรสวนกลับว่า “แนวทางที่จะยกระดับคุณภาพโค้ดเป็นเรื่องที่ดี แต่ถ้าเปลี่ยน Y จะต้องขออนุมัติ X/Y/Z และต้องใช้เวลาเพิ่มอีกหลายวัน ประเด็นที่คุณพูดถึงควรถูกแยกเป็นงาน หนี้ทางเทคนิค แล้วค่อยจัดการใน PR ถัดไปตามลำดับความสำคัญและทรัพยากรที่มี ตอนนี้มาช่วยกันโฟกัสว่าต้องทำอะไรบ้างเพื่อ deploy PR เฉพาะจุด นี้ก่อน”
    บทเรียนใหญ่ที่สุดคือการทำ PR ที่มีขอบเขตชัดเจนและการโต้กลับเมื่อผู้รีวิวพยายามขยายขอบเขต โดยทั่วไปวิศวกรคนอื่น ๆ ก็รับแนวทางนี้แบบปฏิบัติได้จริง เรื่องนี้ไม่เกี่ยวกับจำนวนบรรทัดเลย เพราะบางครั้งอาจเปลี่ยนแค่การจัด format ของทั้งไฟล์โดยไม่แตะ logic หรือแค่สลับ feature flag ไม่กี่ตัวก็อาจส่งผลกระทบมากได้ ควรทำการเปลี่ยนแปลงแบบโฟกัสทีละอย่างเท่านั้น

    • ไม่เห็นด้วยที่ว่า “ถ้าจะเปลี่ยนตรงนี้ ก็ต้องแก้ปัญหาค้างคาอื่น ๆ ด้วย” คือประเด็นหลัก สิ่งที่แย่ที่สุดในเรื่องนี้คือ การเปลี่ยนโค้ดหนึ่งบรรทัดใช้เวลา 6 วัน และเกือบครึ่งหนึ่งของเวลานั้นผ่านไปก่อนที่วิศวกรจะได้ดู issue ด้วยซ้ำ
      ถ้านี่เป็นงานความสำคัญสูงมากถึงขั้นถ้าไม่รีบทำบริษัทอาจต้องปลดพนักงานจริง ๆ ช่วง 2~3 วันก่อนมีใครมาดูไม่ควรเกิดขึ้นเด็ดขาด แต่ในกระบวนการพัฒนานี้มันกลับดูเหมือนเป็น “เส้นทางด่วน”
      2 วันสุดท้ายก็ดูเหมือนไม่มีอะไรเกิดขึ้น เพราะเห็นว่าแผนทดสอบยังไม่เพียงพอ ส่วน “ถ้าจะเปลี่ยนตรงนี้ ก็ต้องแก้ปัญหาค้างคาอื่น ๆ ด้วย” กินเวลาไปแค่ 2 ชั่วโมง และก่อนจะถึงจุดนั้นก็ยังมีปัญหาหลักของกระบวนการนี้อีกอย่างน้อย 2~3 จุดที่ควรถูกชี้ก่อน
    • ปกติจะหลีกเลี่ยงการปรับปรุงที่ไม่เกี่ยวข้องโดยตรงกับงานตรงหน้า เพราะแม้แต่การเติม semicolon ที่หายไปเพียงตัวเดียว ก็อาจไปเข้าตาผู้รีวิวที่จริงจังเกินเหตุแล้วถูกลากลง โพรงกระต่ายแห่งการแก้ legacy ได้
      แทนที่จะทิ้ง FIXME หรือ TODO ไว้ มักจะสร้าง issue เงียบ ๆ เพื่อไม่ให้ลืม ส่วนนี้ของการรีวิวถือว่าพังไปแล้ว การแก้หนี้ทางเทคนิคไม่ควรเป็นเงื่อนไขของการทำงานให้เสร็จ แต่ควรถูกวางแผนแยกต่างหาก
    • คนที่ชอบ ขยายขอบเขต ไม่รู้ตัวเลยว่ากำลังก่อความเสียหายด้านสถาปัตยกรรมแค่ไหน ถ้าไปยึดติดกับโค้ดบล็อกหนึ่งมากเกินไป คนก็จะพยายามหาทางอ้อมบริเวณนั้น
      พอชั้นพวกนี้ทับถมกันไป สุดท้ายโค้ดก็จะกลายเป็นอะไรที่ในเชิงศีลธรรมแทบไม่ต่างจาก Atlanta, GA ที่ขึ้นชื่อเรื่องถนนวงแหวนเต็มเมือง
    • มองว่าทางออกที่ดีกว่าคือการ ทำกฎให้เป็นอัตโนมัติ
      เมื่อมีกฎใหม่ ระบบอัตโนมัติควรใส่คอมเมนต์ยกเว้นกฎให้กับทุกจุดที่ละเมิดอยู่เดิม และต้องติดตามได้ด้วย ถ้ามีโค้ดที่ต้องรีบขึ้น production และจำเป็นต้องผิดกฎ ก็แค่เพิ่มคอมเมนต์ยกเว้น แล้วใส่ชื่อตัวเองเป็นคนรับผิดชอบแก้ภายหลัง
      เมื่อเวลาผ่านไปก็สามารถสร้างวัฒนธรรมการแก้การละเมิดกฎเหล่านี้แบบแยกจากการพัฒนาฟีเจอร์ได้
    • ถ้าเกิดเรื่องแบบนั้น ก็แค่เพิ่ม TODO ticket เข้าไป ปลดล็อกตัวบล็อก production และระบบก็จะไม่แย่ลงไปกว่านี้ด้วย

  • เห็นด้วย ส่วนใหญ่กระบวนการ code review ของหลายบริษัทเต็มไปด้วย การจับผิดจุกจิก และคอมเมนต์เล็กน้อย
    เคยเสนอว่าให้เลิกคอมเมนต์แบบนี้แล้วใช้ static analysis tool แทนเพื่อให้ feedback เร็วขึ้น แต่คำตอบที่ได้คือการรีวิวแบบนั้นจำเป็นสำหรับทุกคน เพราะมันช่วยให้คนเลื่อนตำแหน่งได้ ทำให้รู้สึกว่าตัวเองช่วยกันป้องกันปัญหาในโค้ด และยังทำให้ผู้บริหารระดับบนมองตัวเลขคอมเมนต์ของผู้รีวิวแล้วรู้สึกว่า metrics ของ code review ดูดี

    • ไม่ชอบการใช้เครื่องมือพวกนี้มากเกินไป เพราะบ่อยครั้งเรากลับทำให้โค้ดแย่ลงเพื่อเอาใจเครื่องมือโง่ ๆ
      ทางแก้จริง ๆ คือยอมรับว่าโค้ดทุกชิ้นไม่จำเป็นต้องดูเหมือนฉันเป็นคนเขียนเอง แล้วถามตัวเองว่า “คอมเมนต์นี้กำลังพูดถึง ข้อผิดพลาดเชิงวัตถุวิสัย ของโค้ดหรือเปล่า?” หลายครั้งคำตอบคือ “ไม่ใช่”
    • บางครั้งตรงนี้มี ภาวะนักโทษ จริง ๆ เวลาที่ senior รีวิว PR ของ junior มักมีจุดที่อาจปรับให้ดีขึ้นได้ แต่ไม่ได้สำคัญมาก
      ถ้าเป็นแค่ชื่อตัวแปรยาวไปนิดหรือช่องว่างระหว่างเมธอดไม่สม่ำเสมอ ตามอุดมคติแล้วมันควรเป็นแค่ “feedback ไว้จำตอนหน้าถ้ากลายเป็นแพตเทิร์น” แต่ในมุมผู้รีวิวอาจถูกมองว่าจำนวนคอมเมนต์ต่อ PR คือมาตรวัดว่าให้คำแนะนำไปมากแค่ไหน หรือกังวลว่าจะมีคนพูดว่า “ใครปล่อยให้ merge อันนี้ได้?” สุดท้ายเลยต้องทิ้งคอมเมนต์ไว้
      ส่วนคนที่ถูกรีวิวก็แก้ตาม เพราะกลัวว่าถ้าไม่จัดการคอมเมนต์จะดูเหมือนไม่ตอบสนองต่อ feedback หรือถ้าเถียงกลับไปผู้รีวิวอาจให้การประเมินไม่ดี จากนั้นก็ต้องรออนุมัติเวอร์ชันอัปเดตอีกครั้ง วงจรความล่าช้าก็เริ่มใหม่
    • ในบางสภาพแวดล้อมก็จริง แต่กระบวนการรีวิวยังช่วยสร้าง ความรู้ร่วมกัน และความเข้าใจต่อทั้งตัวการเปลี่ยนแปลงและ codebase ด้วย
    • การจับผิดจุกจิกมีอยู่จริงแน่นอน อาจเป็นเพราะรู้สึกว่าต้องหาอะไรผิดในโค้ดให้เจอ
      แต่บางเรื่องที่บางคนมองว่าเป็นแค่เรื่องเล็กน้อย จริง ๆ แล้วอาจไม่เล็กน้อยเลยก็ได้ อาจเป็นเพราะเขามองไม่เห็นปัญหาด้วยตาตัวเอง ยังไม่เข้าใจปัญหา หรือไม่สามารถวางอารมณ์ลงแล้วกลับมาคิดกับโค้ดที่ตัวเองเขียนอย่างเป็นกลางได้
      เราทุกคนคงเคยผูกพันกับโค้ดที่ตัวเองเขียน และอาจเคยคิดว่ามันสง่างามที่สุดในโลก แต่บางครั้งเราก็ต้องยอมรับว่าตัวเองผิด ว่ามันอ่านยาก มีข้อบกพร่อง และเป็นผลเสียต่อ codebase
      ฉันเคยชี้ race condition ที่อาจเป็นปัญหาจริงในโค้ดของคนที่ senior กว่าฉัน แล้วกลับถูกมองว่าเป็นคนจับผิด สำหรับฉัน race condition คือปัญหาระดับพื้นฐานของโค้ดที่ต้องแก้ แต่สำหรับเขามันยังยอมรับได้ เพราะยังไม่เคยเห็นมันพังต่อหน้าต่อตาแบบชัด ๆ
    • static analysis tool กับการรีวิวโดยเพื่อนร่วมงานจับปัญหาคนละประเภทกันได้ คล้ายกับที่ภาษาแบบ static compile จับบั๊กบางอย่างที่ภาษา dynamic จับไม่ได้ แต่ก็จับไม่ได้ทั้งหมด
      ฉันชอบการรีวิวโดยเพื่อนร่วมงานมาก และปกติจะโฟกัสที่ “โค้ดนี้จะไม่ทำงานตามที่คาด”, “ทำแบบนี้แล้ว implementation จะตันหรือมีต้นทุนสูงขึ้นมาก”, “มันอาจทำงานได้ แต่เข้าใจยากและจะส่งผลเสียต่อการบำรุงรักษา ลองใช้วิธีอื่นหรือเพิ่มคำอธิบาย”, “โค้ดโอเค แต่ยังอ่านง่ายขึ้นหรือทำงานได้ดีกว่านี้ได้ เรื่องนี้ไม่ถึงขั้นทำให้รีวิวไม่ผ่าน แต่เป็นข้อสังเกตที่ควรจำไว้ในโค้ดครั้งหน้า”

  • “Julie: ติดต่อ Joe จากทีมรักษาความปลอดภัยไอที เขาจะให้สิทธิ์เอง อีก 2 ชั่วโมงค่อยว่ากัน” นี่ไม่สมจริงสุด ๆ ทีมความปลอดภัยไม่มีทางตอบเร็วขนาดนั้น

    • ยกเว้นกรณีที่รัน npm install แล้วมีการแจ้งเตือนความปลอดภัยระดับ P1 เด้งขึ้นมา
    • ทีมความปลอดภัยของเราจริง ๆ ตอบเร็วกว่านั้นอีก ปฏิเสธทุกคำขอแบบอัตโนมัติ แต่ปฏิเสธทันที
    • ที่ที่ฉันทำงานอยู่ประสบการณ์ต่างออกไปมาก ถ้าส่งทิคเก็ตขอสิทธิ์เข้าถึงระบบบางอย่างให้ใครสักคน ไม่ว่าจะตั้งลำดับความสำคัญยังไง ปกติก็จัดการให้ภายในไม่กี่นาที
      บางทีก็อดคิดไม่ได้ว่าพนักงานเฮลป์เดสก์แย่งหยิบทิคเก็ตทันทีที่เข้ามาเพื่อปิดให้เร็วและดันตัวชี้วัดส่วนตัวตัวเอง
    • ใช้เวลาหลายสัปดาห์กว่าจะเพิ่มใครสักคนเข้า AD group ที่จำเป็นสำหรับสิทธิ์แก้ไขวิกิ

  • ถ้าพูดตามชื่อเรื่องว่า ใช้เวลา 6 วันเพื่อเปลี่ยนโค้ด 1 บรรทัด มันก็ดูน่ากลัวจริง
    แต่ระบบก็ถูกปรับปรุงดีขึ้นในบางแง่ การตั้งค่าถูกทำให้ปรับได้จากตารางพารามิเตอร์แทนการฮาร์ดโค้ด และยังมีฟังก์ชันตรวจสอบย้อนหลังเพื่อติดตามการเปลี่ยนค่าพวกนั้นด้วย
    ไม่ได้จะปกป้องระบบราชการนะ ฉันเกลียดด้านนั้นขององค์กรใหญ่จากใจจริง แค่อยากชี้ให้เห็นว่านอกจากเป้าหมายแรกแล้ว ช่วงเวลา 6 วันนั้นก็สร้างคุณค่าเพิ่มอย่างอื่นด้วย
    เพราะงั้นในประมาณการก็ควรเผื่อ ต้นทุนแฝง พวกนี้ไว้บ้าง และถ้าจะให้ story point ก็ควรคิดต้นทุนเชิงกระบวนการแบบนี้ด้วย

    • เหตุผลเดียวที่ตารางพารามิเตอร์มีประโยชน์ ก็เพราะมีอุปสรรคต่อการแก้โค้ดเยอะเกินไป เช่นเดียวกัน การตรวจสอบย้อนหลังของการตั้งค่านี้ก็ดูเหมือนไม่จำเป็น แต่ก่อนมันอยู่ในโค้ดอยู่แล้ว ดังนั้นการจัดการซอร์สก็คือ audit trail โดยตรง
      สุดท้ายแล้วผลลัพธ์สองอย่างนี้ก็คือ “ความสำเร็จ” จากการเลี่ยงพิธีรีตองรอบการแก้โค้ด และ “ความสำเร็จ” จากการได้ฟังก์ชันที่สูญเสียไปเพราะความสำเร็จข้อแรกกลับคืนมา เนื่องจากจากนี้การเปลี่ยนนี้จะไม่อยู่ในโค้ดอีกต่อไป
    • จริง แต่พวกเขาก็ทำอะไรที่เสี่ยงกว่าคำขอเดิมมากด้วย ผมมองว่าการดันค่าที่ฮาร์ดโค้ดไว้ออกไปเป็นพารามิเตอร์ในสถานการณ์ที่มีเหตุขัดข้องฉับพลันหรือปัญหา production จริง ๆ เป็นเรื่องไม่ฉลาด มีหลุมพรางแฝงอยู่มากกว่าเยอะ
      สิ่งที่ควรพูดคือ “นี่เป็นเรื่องด่วน ช่วยรับ PR ที่เปลี่ยนแค่ตัวอักษรเดียวก่อน ส่วนการปรับปรุงที่คุณขอไว้เราทำเป็นทิคเก็ตติดตามแล้ว ขอแก้ปัญหา production ก่อน ที่เหลือค่อยตามเก็บทีหลัง”
      ฝั่ง reviewer แค่พูดว่า “LGTM!” ก็พอแล้ว ถ้าวิศวกรส่วนใหญ่ในองค์กรยังเดินเกมระหว่างกฎกับแนวปฏิบัติไม่เป็น องค์กรนั้นก็บ้าไปแล้ว และนี่แหละคือจุดที่ ความเป็นซีเนียร์ มีค่า
    • ขั้นแรกคือการประเมินลำดับความสำคัญที่แท้จริง ทุกคนควรรู้ว่างานนี้ถ้าล่าช้าจะกระทบต่อการจ้างงานของผู้คนมากแค่ไหน
      ถ้ารอได้เป็นสัปดาห์โดยไม่กระทบงานของใคร ก็ทำตามกระบวนการหรือเปลี่ยนให้น้อยที่สุดก็พอ แต่ถ้าคนกำลังถูกพักงานโดยไม่รับค่าจ้างเพราะปัญหาไอที ทุกคนที่จำเป็นต้องเกี่ยวข้องควรอยู่ในห้องเดียวกัน ไม่ว่าจะห้องจริงหรือห้องเสมือน จนกว่าปัญหาจะถูกแก้
      ตรงนี้ไม่มีบริบทนั้นให้เห็น แต่ถ้า Ed กับสายอนุมัติทั้งหมดไม่รู้บริบทนี้ นั่นคือ ความล้มเหลวของระบบ ถ้ารู้ว่าค่าเช่าบ้านของใครสักคนแขวนอยู่กับเรื่องนี้ คนระดับซีเนียร์ก็คงเสนอให้สร้างทิคเก็ตที่สองเพื่อมาแก้ต่อทันที ไม่อย่างนั้นนั่นก็เป็นปัญหาที่ผู้บริหารต้องจัดการ
    • “ใช้เวลา 6 วันเพื่อเปลี่ยนโค้ด 1 บรรทัด” ก็เป็นเพียงการบอกข้อเท็จจริง สิ่งที่ว่าระบบดีขึ้นระหว่างทางนั้นไม่ใช่ ข้อกำหนดบังคับ
    • ข้อกำหนดเรื่องการตรวจสอบย้อนหลังน่าจะตอบโจทย์ได้ด้วย ประวัติเวอร์ชัน ของไฟล์ที่มีค่าฮาร์ดโค้ดนั้นอยู่แล้ว ถ้าไม่ได้ใช้ version control ก็แปลว่ามีปัญหาอื่นที่ใหญ่กว่าอีก

  • เรื่องนี้ถือว่าเป็นกรณีที่การเปลี่ยนค่าฮาร์ดโค้ดหนึ่งบรรทัดจบลงได้ค่อนข้างดี
    ลองนึกภาพสถานการณ์ที่มีใครสักคนเก็บจำนวนเดือนของ backlog ไว้ในค่า 2 บิตเพื่อให้ดูฉลาดและเก่ง ทั้งที่มันเก็บได้แค่ 0, 1, 2, 3 เท่านั้น ระหว่างการทดสอบปัญหาอาจไม่โผล่ เพราะมันซ่อนอยู่ลึกลงไปหลายชั้นในบริการย่อยที่ไม่เคยถูกทดสอบ หรือบริการอัตโนมัติแบบ low-code
    ถ้าเปลี่ยนค่านั้นเป็น 4 backlog อาจกลายเป็น 0 ก็ได้ ไม่มีใครรู้ว่าผลจะออกมาอย่างไร บริการนั้นอาจยกเลิกงานทั้งหมดในคิว production หรืออาจส่งอีเมลหาลูกค้าว่างานถูกยกเลิกแล้วก็ได้
    มันดูเหมือนเป็นการเปลี่ยนง่าย ๆ จากภายนอก แต่ถ้าการเปลี่ยนนโยบายถูกโยนมาให้ทีมซอฟต์แวร์แบบเร่งด่วน ฝ่ายบริหารก็ควรวางแผนให้ดีกว่านี้ ไม่ใช่มาเขย่าลำดับความสำคัญของงานแบบตามอำเภอใจ

    • ในการเปลี่ยนที่ร้องขอมา ไม่มีอะไรเกี่ยวกับ การทดสอบเพิ่มเติม หรือการลดความเสี่ยงเลย
      ตรงกันข้าม กลับเพิ่มความเสี่ยงด้วยการบังคับให้รีแฟกเตอร์ส่วนรอบข้างหลายจุดให้เป็น “ต้นทุน” ของการเปลี่ยนนี้
    • มีสารพัดวิธีที่มันจะพังได้ คำถามจริง ๆ อาจเป็นว่า ถ้ามันพังแล้วความรับผิดชอบจะตกไปที่ไหน
      ถ้าหัวหน้าคนใหญ่พูดว่า “ผมตัดสินใจยอมรับความเสี่ยงและเดินหน้าต่อ และผมจะรับผลลัพธ์ด้วย” แบบนั้นก็ดี แต่ไม่ดีแน่ถ้าปล่อยให้โปรแกรมเมอร์เป็นคนรับเต็ม ๆ
    • ผมคิดว่าพวกเขาก็ทำตามคนและกระบวนการที่ถูกต้องแล้ว เพียงแต่ถ้ารวมพวกลีดมาเข้าประชุมและจัดลำดับความสำคัญของงานให้ตรงกัน ก็น่าจะประหยัดเวลาได้มาก
      ถ้าเป็นอัปเดตที่สำคัญและไวต่อเวลาในฟังก์ชันหลัก ผู้รับผิดชอบงานปฏิบัติการก็ควรรู้ เวลาเฉลี่ยในการ deploy ของซอฟต์แวร์ และควรตั้งทีมเฉพาะกิจเพื่อเร่งดำเนินการ แทนที่จะใส่เข้าไปใน pipeline พัฒนาปกติด้วย priority สูงเฉย ๆ
    • นึกถึง Knight Capital ขึ้นมาเลย

  • code review เริ่มต้นมาจากเจตนาดี แต่สุดท้ายมักมี ผู้เฝ้าประตู บางคนเข้ามาจับจองบทบาท แล้วเริ่มปฏิเสธทุกอย่างด้วยเหตุผลเล็กน้อยจุกจิก
    เจ้าตัวจะบอกว่าสนใจการรักษา “คุณภาพโค้ด” แต่ไม่มีอะไรแย่ไปกว่าการปล่อยให้โค้ดที่แก้บั๊กเสร็จแล้วค้างอยู่นาน หรือทำให้ฟีเจอร์ออกช้าจนไม่มีใครได้ลองใช้
    ผมแนะนำกระบวนการที่เปิดให้คอมเมนต์ได้ แต่ reviewer ไม่มีสิทธิ์ขวางการ commit ต้องเชื่อใจว่านักพัฒนาแต่ละคนจะระมัดระวังและเปลี่ยนแปลงให้เหมาะกับงาน จะใช้ CI ด้วยก็ได้ และขึ้นอยู่กับทีม มันก็เวิร์กได้ดีพอสมควร

    • ถ้าอย่างนั้นผู้นำสายวิศวกรรมก็ควรหยุดคนคนนั้น ความผิดปกติแสดงออกได้หลายแบบ และการรีวิวที่กระตือรือร้นเกินเหตุก็เป็นหนึ่งในนั้น
      การเปลี่ยนกระบวนการเพื่อให้มองข้าม reviewer ที่มีพฤติกรรมผิดปกติได้ เป็นมาตรการแค่ครึ่ง ๆ กลาง ๆ อย่างดีที่สุด
      เรื่องการบล็อกนี่ผมก็มีความรู้สึกสองด้าน เข้าใจดีว่าป้ายบล็อกสีแดงตัวใหญ่ทำให้หงุดหงิด เลยหลายครั้งจะเลือกไม่บล็อก แต่ขอให้แก้ไขแบบ “soft block” แทน อย่างไรก็ตาม ถ้า PR หลุดทิศหลุดทางไปไกลมาก โดยเฉพาะเวลาเป็นนักพัฒนาจูเนียร์ ผมคิดว่าการส่งสัญญาณที่ชัดเจนก็เหมาะสม
    • วิธีนี้จะเวิร์กเมื่อ ขอบเขตการทดสอบ และคุณภาพของการทดสอบสูง และสิ่งนั้นก็ไม่ได้เกิดขึ้นเองแบบปาฏิหาริย์ เพียงเพราะปล่อยให้นักพัฒนาเคลื่อนที่ด้วยความเร็วที่ผู้จัดการอยากได้ในตอนนี้
    • ผมเกลียดกฎที่ว่า “การเปลี่ยนโค้ดทุกครั้งต้องมี reviewer” มันเป็นตัวถ่วงชั้นยอด และก็ไม่ได้แปลว่าจะนำไปสู่โค้ดที่ดีกว่าเสมอไป

  • นี่เป็นเรื่องเชิงเมตาเกี่ยวกับคนงานโรงงานและนักพัฒนาซอฟต์แวร์
    ผู้นำบริษัทนี้ยินดีจะไล่คนงานโรงงานออกเพราะมีการใช้งานต่ำกว่าเต็มประสิทธิภาพ 10% พวกเขาอาจปรับตัวแปรบางอย่างเพื่อเพิ่มผลิตภาพได้ แต่สุดท้ายตัวเลือกก็คือใช้งานเต็มที่หรือไม่ก็ว่างงาน น่าจะเป็นไปได้เพราะคนงานเหล่านี้ทดแทนกันได้ จ้างกลับมาใหม่ได้ในช่วงพีค และกำไรที่สร้างได้ต่อพนักงานไม่มากพอจะยอมให้เกิดความไร้ประสิทธิภาพ
    ผมทำงานเป็นนักพัฒนาซอฟต์แวร์ ฝั่งเราต้องใช้งานต่ำกว่าศักยภาพเกิน 90% มาก ๆ ถึงจะเริ่มคิดจะปล่อยใครออก หลายคนทำงานแค่สัปดาห์ละ 4 ชั่วโมง ไม่มีใครมาจับเวลาเป็นนาทีหรือควบคุมแม้แต่ช่วงพักเข้าห้องน้ำของเรา
    ตอนนี้เป็นช่วงของการ นำซอฟต์แวร์ไปใช้เป็นสินทรัพย์ทุนในวงกว้าง และมันจะไม่เป็นแบบนี้ตลอดไป สักวันหนึ่งโครงสร้างพื้นฐานหลักของโลก IT จะถูกสร้างเสร็จ และอุตสาหกรรมจะเปลี่ยนเข้าสู่โหมดบำรุงรักษา พวกเราส่วนใหญ่จะไม่จำเป็นอีกต่อไป จะถูกแทนที่ได้ และกำไรที่เราสร้างได้ในโหมดบำรุงรักษาจะน้อยนิดเมื่อเทียบกับที่เห็นในตอนนี้
    ถ้ารับรู้ได้ว่าผลิตภาพส่วนบุคคลของคนงานโรงงานต่ำ พวกเขามักถูกไล่ออกภายในไม่กี่นาทีหรือไม่กี่ชั่วโมง ผมคิดว่าสิ่งนี้จะเริ่มเกิดกับนักพัฒนาซอฟต์แวร์ภายในช่วงชีวิตของพวกเรา

    • คำว่า “คนงานพวกนี้ทดแทนกันได้และจ้างกลับมาใหม่ได้ในช่วงพีค” นี่แหละคือความต่าง โรงงานถูกออกแบบให้เป็น ระบบของกระบวนการ ที่ดึงการตัดสินใจและความผันแปรออกไปจากแต่ละคน
      คุณก็ควรประเมินด้วยว่าเรื่องแบบนั้นเป็นไปได้มากน้อยแค่ไหนกับชุดทักษะของตัวเอง
      ผมเห็นด้วยกับประเด็นหลักที่ว่าการนำซอฟต์แวร์ไปใช้เป็นสินทรัพย์ทุนในวงกว้างจะไม่คงอยู่ตลอดไป ไม่ใช่ทุกบริษัทจะต้องการวิศวกรเพื่อพัฒนาซอฟต์แวร์ใหม่อยู่เสมอ มันใกล้เคียงกับธุรกิจเชิงสร้างสรรค์ที่มีช่วงบูมและช่วงซบเซาอย่างการสร้างภาพยนตร์มากกว่า ถ้าคุณเลือกทำ development มากกว่า IT ก็ต้องยอมรับความเสี่ยงนั้น เพียงแต่ผมไม่รู้ว่าทำไมตอนนี้ถึงต้องเป็นจุดสูงสุด

  • จากประสบการณ์ส่วนตัว ผมเคยทำงานอยู่หลายปีในทีมที่มี code review แบบเป็นทางการ แล้วก็ย้ายไปทีม/บริษัทที่ไม่มี code review ใคร ๆ ก็ commit และ merge เข้า branch ไหนก็ได้อย่างอิสระ
    ตอนเข้าทำงานใหม่ ๆ ก็มีความรู้สึกปน ๆ กันอยู่บ้าง แต่ในทางปฏิบัติแล้วมันสดชื่นมากและรู้สึกได้รับอำนาจ จนทำงานได้อย่างมีประสิทธิภาพภายในไม่กี่วัน

    • ผมเคยอยู่ทีมที่ทำ “Catholic code review” หรือก็คือ push and pray
      เมื่อดูจากเป้าหมายของทีม วิธีที่ไม่มี code review นั้นเหมาะมาก เพราะเราเป็นกลุ่มวิจัยและพัฒนาที่มีเป้าหมายหลักคือสาธิต “ฟีเจอร์ใหม่สุดเจ๋ง” ให้ผู้บริหารดู คำขอแบบเร่งด่วนเข้ามาบ่อย แต่โค้ดที่ถูกทิ้งก็มีมากเช่นกัน
      พอสาธิตเสร็จ ผู้บริหารก็บอกว่า “ดูดีนะ แต่ไม่มีศักยภาพทางธุรกิจ” แล้ว repository นั้นก็ไม่ถูกแตะอีก แน่นอนว่าบางครั้งสิ่งที่เราสร้างก็ได้กลายเป็นผลิตภัณฑ์จริง และตอนนั้นทีมย่อยอีกทีมก็จะต้องรับผิดชอบเปลี่ยนโค้ดลวก ๆ ของเราให้เป็นคุณภาพระดับ production พวกเขาเกลียดพวกเราแบบเดือดพล่านจริง ๆ
    • ผมเคยเห็นว่าวิธีนี้ใช้ได้ดีมากในทีมเล็ก ๆ ที่มีความไว้ใจกันสูงและมี test coverage ราว 80% มันเป็นกระบวนการที่ไม่มี PR ถ้าเทสต์ผ่าน ถ้ามีการเดโม UX ให้ผู้มีส่วนได้ส่วนเสียแล้วสำเร็จ และตัวเองพอใจ ก็ merge เข้า master ได้เลย
      สมาชิกใหม่จะมีเมนเทอร์นั่งข้าง ๆ ในช่วง 2-3 เดือนแรก คอย pair และช่วยดูโค้ดให้บ่อย ๆ
      เป็นโปรเจกต์อายุ 2.5 ปี ขึ้นใช้งานจริงในเดือนที่ 20 ทำเสร็จตามกำหนดและตามงบ พร้อมส่งมอบฟังก์ชันได้มากกว่าขอบเขตเดิม หลายวันเราจะยืนถกกันหน้าไวต์บอร์ด 2-3 ชั่วโมง มันไม่เป็นทางการ และก็ไม่ใช่ว่าทุกคนจะเข้าร่วมทุกครั้ง
      แปลกดีที่ระหว่างโปรเจกต์นี้ PM เปลี่ยนไปถึงสามคน มีกฎเข้มงวดว่าห้ามส่งอีเมลหรือสื่อสารติดต่อกันนอกจากใน standup และจากสามคนนั้นมีสองคนที่ “ทำงาน” ภายใต้รูปแบบนี้ได้ หัวหน้า IT ของสนามบินเพิ่งมารู้หลังจากผ่านไป 2 ปีว่าเราไม่จำเป็นต้องมี PM เลย
      มีกฎว่าถ้าจะทำงานใหม่ใน codebase ต้องคุยกับนักพัฒนาอย่างน้อยอีกหนึ่งคน เรานั่งห่างกันแค่ไม่กี่ฟุตในห้องทำงานส่วนตัวขนาดใหญ่ที่มีไวต์บอร์ดใหญ่ ๆ เราจัดการสตอรีด้วยบัตรดัชนีที่แปะไว้บนไวต์บอร์ดเฉพาะ และถ้าอธิบายสาระสำคัญลงบนนั้นไม่ได้ ก็ต้องหั่นให้เล็กลงอีก
      แต่ละคนประกอบเครื่องของตัวเองได้และใช้จอได้เท่าที่ต้องการ มันเป็นระบบเรียกเก็บเงินและค่าธรรมเนียมของสนามบินนานาชาติขนาดใหญ่ หัวหน้าฝ่ายบัญชี ไดเรกเตอร์ และผู้ใช้อีกหลายคนอยู่ห่างไปแค่ไม่กี่ประตู พวกเขาแทบไม่เคยพลาด standup และมีนโยบายให้ถามสดได้ตลอดเวลา
      standup โดยปกติไม่ใช่การรายงานสถานะ แต่เป็นการคุยกันแบบไม่เป็นทางการ การสาธิต และถามตอบ เรื่องอัปเดตสถานะดูจากการ์ดบนไวต์บอร์ดก็พอ
      ระบบสุดท้ายช่วย เพิ่มรายได้ 8% ตั้งแต่เดือนแรกและทุกเดือนหลังจากนั้น ผู้อำนวยการฝ่ายบัญชีต้องไปอธิบายต่อหน้าบอร์ดของหน่วยงานสนามบิน ข้อพิพาทและการปรับยอดการเรียกเก็บเงินกับสายการบินลดจากเดือนละ 9 วันเหลือ 1 วัน และภาระงานออกบิลรายเดือนลดจาก 18 วันเหลือ 5 วัน สามารถส่งต่องานจากนักบัญชีอาวุโสหลักไปให้นักบัญชีรุ่นน้องที่มีประสบการณ์ 3 ปีเพียงคนเดียวได้
      บั๊กใน production มี 6 เคสในปีแรก และมีใบแจ้งหนี้ผิดพลาด 0 ใบ หลังจากนั้นไม่มีข้อมูล ความพยายาม rewrite ก่อนหน้านี้ล้มเหลวหลังจาก 3 ปี
    • พูดตามตรง ในมุมของ security และ audit มันฟังดูเหมือนฝันร้ายเลย ถึงอย่างนั้น ถ้าเป็นเอเจนซีหรือที่คล้ายกันที่ทำโปรเจกต์เล็ก ๆ ก็พอจะนึกภาพออก

  • การใช้กระบวนการ code review ไปจับการเปลี่ยนแปลงไว้เป็นตัวประกันจนกว่าจะเหมาะกับทีมที่มี churn สูงและเปลี่ยนแปลงตลอดนั้นเป็น ความบกพร่องเชิงหน้าที่
    นโยบาย “อัปเกรดไปพร้อมกัน” ทิ้งหางยาวของการเปลี่ยนผ่านที่ค้างครึ่ง ๆ กลาง ๆ ไว้ ทำให้นักพัฒนาใหม่ปรับตัวเข้ากับ codebase ได้ยากขึ้น ไม่มีอะไรรับประกันได้เลยว่าโฟกัสของผลิตภัณฑ์จะผ่านทุกส่วนของ codebase อย่างสม่ำเสมอ ดังนั้นการเปลี่ยนผ่านจึงไม่มีวันจบ บางส่วนของผลิตภัณฑ์ถูกปล่อยทิ้งไว้เป็นปี ๆ
    ถ้าการเปลี่ยนไปใช้นโยบายใหม่สำคัญจริง ก็ควรตัดมันออกมาเป็นโปรเจกต์เฉพาะที่โฟกัสกับมัน แต่ถ้าไม่ทำ ก็แปลว่ามันไม่ได้สำคัญ

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

  • การอ่านสิ่งนี้ว่าเป็นปัญหาเรื่อง code review เป็นการตีความผิด ปัญหาคือบริษัทให้ความสำคัญกับกระบวนการที่เต็มไปด้วยกำแพงภายในมากกว่าหลักการ
    ทุกกระบวนการต้องมี ทางหนีทีไล่ ถ้าเป็นการเปลี่ยนแปลงเพื่อป้องกันการเลิกจ้าง ทางหนีทีไล่ทั้งหมดก็ควรถูกเรียกใช้