ข้อผิดพลาดที่วิศวกรมักทำในโค้ดเบสขนาดใหญ่ที่มีอยู่เดิม

• การทำงานกับโค้ดเบสขนาดใหญ่เป็นหนึ่งในงานที่ยากที่สุดสำหรับวิศวกรซอฟต์แวร์ เป็นประสบการณ์ที่หาได้ยากจากโปรเจ็กต์ส่วนตัวหรือโปรเจ็กต์โอเพนซอร์ส
  • โค้ดนับล้านบรรทัด, วิศวกร 100-1000 คนทำงานพร้อมกัน, และโค้ดเบสที่มีอายุอย่างน้อย 10 ปีขึ้นไป
  • ต้องใช้ทักษะเฉพาะในการทำความเข้าใจสภาพที่ความซับซ้อนและกาลเวลาได้ทับถมกันมา

ความผิดพลาดที่ใหญ่ที่สุดคือการขาดความสม่ำเสมอ

• ความผิดพลาดที่พบบ่อยที่สุดคือการมองข้ามโค้ดเบสเดิมแล้วไปสร้างฟีเจอร์ของตัวเองขึ้นมา ซึ่งทำให้ไม่สามารถรักษาความสม่ำเสมอไว้ได้และยิ่งเพิ่มความสับสนให้กับโค้ดเบส
  • โดยมากมักพยายามลดการปฏิสัมพันธ์กับโค้ดเบสเดิมให้เหลือน้อยที่สุด เพื่อรักษาโค้ดที่สะอาดของตัวเอง และแยกทำอย่างอิสระเพื่อหลีกเลี่ยงโค้ด "legacy" เดิม
• ความสม่ำเสมอช่วยลดความซับซ้อนของโค้ดเบส และทำให้การปรับปรุงในอนาคตทำได้ง่ายขึ้น
• ตัวอย่างเช่น เมื่อสร้าง API endpoint การทำตามวิธี authentication ที่มีอยู่เดิมเป็นสิ่งสำคัญ สิ่งนี้ช่วยให้สามารถเดินผ่านสนามทุ่นระเบิดของโค้ดเบสได้อย่างปลอดภัย
• หากไม่มีแพตเทิร์นที่สม่ำเสมอ จะต้องอัปเดตโค้ดทั้งหมดด้วยมือ ซึ่งจะยิ่งยากขึ้นเรื่อย ๆ

องค์ประกอบสำคัญอื่น ๆ

• ทำความเข้าใจว่าบริการถูกใช้งานจริงอย่างไร
  • ระบุ API endpoint หลักที่ถูกใช้งานบ่อยที่สุดและเส้นทางสำคัญ (hot path)
  • การเปลี่ยนแปลงโค้ดที่ถูกใช้งานบ่อยต้องทำอย่างระมัดระวัง
• ความสำคัญของการทดสอบและการมอนิเตอร์
  • ในโปรเจ็กต์ขนาดใหญ่ไม่สามารถทดสอบได้ทุกสถานะ จึงทดสอบเฉพาะเส้นทางหลัก
  • เขียนโค้ดแบบป้องกันไว้ก่อน และพึ่งพาการทยอยปล่อยใช้งานกับการมอนิเตอร์
• หลีกเลี่ยงการเพิ่ม dependency
  • dependency ก่อให้เกิดปัญหาด้านความปลอดภัยและเพิ่มต้นทุนการบำรุงรักษา
  • หากจำเป็นจริง ๆ ให้เลือก dependency ที่เชื่อถือได้
• ลบโค้ดอย่างระมัดระวังแต่เชิงรุก
  • วิเคราะห์ข้อมูลโปรดักชันเพื่อนำการเรียกใช้งานออกอย่างปลอดภัยก่อน แล้วจึงลบโค้ด
  • การกำจัดโค้ดที่ไม่จำเป็นช่วยให้ดูแลโค้ดเบสได้ง่ายขึ้น
  • นี่คือหนึ่งในงานที่มีคุณค่ามากที่สุดในโค้ดเบสขนาดใหญ่
• ทำงานเป็น PR ขนาดเล็ก และจัดการการเปลี่ยนแปลงที่กระทบโค้ดของทีมอื่นก่อน
  • ช่วยให้ผู้เชี่ยวชาญโดเมนมองเห็นปัญหาและป้องกันอุบัติเหตุได้

ทำไมโค้ดเบสขนาดใหญ่จึงสำคัญ?

• คุณค่าของโค้ดเบสขนาดใหญ่
  • บริษัทเทคโนโลยีส่วนใหญ่สร้างรายได้จากโค้ดเบสขนาดใหญ่
  • การทำงานกับ "legacy codebase" คือเนื้องานจริงของบริษัท
• ต้องเข้าใจก่อนจึงค่อยแยกโค้ด
  • หากต้องการแยกโค้ดเบสขนาดใหญ่ ต้องเข้าใจภาพรวมการทำงานทั้งหมดให้เพียงพอก่อน
  • การออกแบบใหม่ครั้งใหญ่เป็นไปไม่ได้หากไม่มีความเข้าใจ

สรุป

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

[kallare]

ความสม่ำเสมอเป็นเรื่องสำคัญก็จริง แต่การผัดการปรับปรุงโค้ดออกไปหรือทำซ้ำแพตเทิร์นที่ผิดพลาดเดิม ๆ ก็ไม่ใช่วิธีที่ดีเหมือนกัน... เป็นปัญหาที่ยากจริง ๆ เพราะการรักษาความสม่ำเสมออาจกลายเป็นการสะสมหนี้ทางเทคนิคแบบเดิม ๆ ต่อไปก็ได้

[regentag]

เหนือสิ่งอื่นใดก็ควรปฏิบัติตามกฎการเขียนโค้ด
โดยเฉพาะกฎเรื่องการเยื้องบรรทัด...

[roxie]

คุณอยู่ในโดเมนที่ไม่สามารถใช้เครื่องมือที่ช่วยจับให้โดยอัตโนมัติได้ใช่ไหม..? ฮือฮือ

[regentag]

ใช่เลย.... ฮือๆ

[roxie]

ฉันจะร้องไห้ให้เลย.. ฮือฮือฮือฮือ

[bbulbum]

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

[beoks]

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• เมื่อโค้ดเบสเดิมขาดความสม่ำเสมอ สิ่งสำคัญคือการนำแนวทางใหม่เข้ามา จัดทำเอกสาร และรับฟีดแบ็ก ควรพยายามรักษาความสอดคล้องกับโค้ดเดิมไว้

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

• ควรใช้เครื่องมือของโค้ดเบสเดิม แต่การสร้างโค้ดเบสใหม่อาจสนุกกว่า

  • ยิ่งโค้ดเบสมีการเชื่อมโยงกันแน่นมากเท่าไร การเปลี่ยนแปลงก็อาจยิ่งยากขึ้น และถ้าขาด test coverage ก็อาจเกิดปัญหาได้

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

  • หากทีมใหม่ไม่เข้าใจระบบเดิม โปรเจกต์ก็อาจล้มเหลวได้

• ในโค้ดเบสขนาดใหญ่ มักมีความพยายามปรับปรุงแบบสุ่มอยู่มาก

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

• การรักษาวิวัฒนาการของโค้ดเบสไว้เป็นเรื่องยาก

  • ความสม่ำเสมอแบบสัมบูรณ์ไม่เปิดโอกาสให้มีการทดลอง และถ้าไม่มีการทดลอง ก็ไม่มีความสำเร็จ

• หากโค้ดเบสมีขนาดใหญ่และคนไม่พอ ต้องใช้เวลานานกว่าที่คนใหม่จะเริ่มทำงานได้อย่างมีประสิทธิภาพ

  • การทำงานในสภาพแวดล้อมแบบนี้อาจไม่ดีต่อเส้นทางอาชีพ

• การรักษาโค้ดเบสให้สะอาดหมายถึงทำเพียงงานขั้นต่ำที่จำเป็นต่อการปล่อยฟีเจอร์

  • นี่อาจเป็นทางเลือกเชิงยุทธวิธีของวิศวกรที่ฉลาดในเชิงการเมืองซึ่งมีเป้าหมายคือการปล่อยฟีเจอร์

• ความสม่ำเสมอไม่ใช่สิ่งสำคัญที่สุดเสมอไป และการปรับปรุงบางส่วนของโค้ดเบสอาจดีกว่า

  • "lava layer anti-pattern" อาจสร้างระบบที่ดีกว่าความพยายามรักษาความสม่ำเสมอ

• คำพูดที่ว่า "การขาดความสม่ำเสมอคือความผิดพลาดร้ายแรง" นั้นถูกต้อง 100%

  • ยึดตามแนวคิด "เข้าเมืองตาหลิ่ว ต้องหลิ่วตาตาม"

• คติสามข้อของการเป็นวิศวกร:

  • ความชัดเจน, ความสม่ำเสมอ, ความกระชับ
  • วางความเจ็บปวดไว้ในที่ที่ถูกต้อง
  • ต่อสู้กับเอนโทรปี