2 คะแนน โดย GN⁺ 2023-07-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โรงงานถูกใช้งานไม่ถึง 10%
  • นโยบายบริษัทจำกัดการสร้างแบ็กล็อกไว้ไม่เกิน 3 เดือน
  • หากเปลี่ยนนโยบายเป็น 4 เดือน ปัญหาก็จะได้รับการแก้ไข
  • การเปลี่ยนค่าตั้งของซอฟต์แวร์เลกาซีต้องแก้โค้ด 1 บรรทัด
  • กระบวนการนำการเปลี่ยนแปลงไปใช้รวมถึงการส่งทิคเก็ต กรอกส่วนที่จำเป็นให้ครบ และขออนุมัติจากผู้อำนวยการ
  • การเปลี่ยนแปลงนี้เร่งด่วนเพื่อหลีกเลี่ยงการเลิกจ้าง
  • โปรแกรมเมอร์แก้โค้ดได้สำเร็จ แต่เกิดปัญหาจากตัวแปรที่ฮาร์ดโค้ดไว้และข้อผิดพลาดอื่น ๆ
  • โค้ดต้องผ่านการตรวจทานแบบ copy review และการทดสอบ ก่อนจึงจะย้ายขึ้นโปรดักชันได้
  • การเข้าถึงสภาพแวดล้อมทดสอบที่จำเป็นล่าช้าเนื่องจากปัญหาด้านสิทธิ์และความพร้อมใช้งาน
  • ระเบียนพารามิเตอร์ต้องเปลี่ยนชื่อและต้องมี audit trail
  • โปรแกรมเมอร์ดำเนินการเปลี่ยนแปลงที่จำเป็นและส่งโค้ดกลับไปเพื่อตรวจทานอีกครั้ง
  • การทดสอบต้องมีแผนทดสอบที่เหมาะสม ซึ่งรวมถึง test case ที่ผู้ใช้เลือกและผลลัพธ์ที่คาดหวัง
  • หลังจาก 6 วัน โปรแกรมจึงได้รับอนุมัติให้ย้ายขึ้นโปรดักชัน

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

 
GN⁺ 2023-07-17
ความคิดเห็นจาก Hacker News
  • ปัญหาหลักคือการปฏิเสธเมื่อผู้รีวิวขอการเปลี่ยนแปลงที่ไปกระทบส่วนอื่นของ codebase
  • การทำ pull request ให้โฟกัสและการต่อต้าน scope creep เป็นบทเรียนสำคัญ
  • กระบวนการ code review อาจเต็มไปด้วยการทักท้วงจุกจิกและคอมเมนต์เล็กน้อย
  • ทีมความปลอดภัยอาจไม่ตอบคำขอสิทธิ์อย่างรวดเร็ว
  • ชื่อบทความอาจทำให้เข้าใจผิด และในช่วง 6 วันนั้นมีการปรับปรุงเพิ่มเติมด้วย
  • การเปลี่ยนแปลงเพียงหนึ่งบรรทัดอาจก่อให้เกิดผลลัพธ์ที่ไม่คาดคิด
  • กระบวนการ code review อาจกลายเป็นด่านเฝ้าประตูและทำให้ความคืบหน้าล่าช้า
  • การอนุญาตให้คอมเมนต์ได้โดยไม่บล็อก commit อาจนำไปสู่การพัฒนาที่มีประสิทธิภาพมากกว่า
  • การย้ายจากทีมที่ทำ code review อย่างเป็นทางการไปยังทีมที่ไม่ทำอาจให้ความรู้สึกสดชื่นและเพิ่มอำนาจในการตัดสินใจ
  • วิธีการบริหารคนงานในโรงงานกับนักพัฒนาซอฟต์แวร์มีความแตกต่างกัน
  • การกักการเปลี่ยนแปลงไว้ตามอุดมคติของทีมที่เปลี่ยนไปนั้นไม่ก่อให้เกิดประโยชน์
  • ปัญหาอยู่ที่กระบวนการของบริษัท ไม่ใช่ที่ตัว code review เอง