เอาเป็นว่าผมทำในส่วนขององค์กรใหญ่ละกันนะ
เขียนยากมี setting นู่นนี่ ส่วนนึงเกิดจาก อยากให้โปรแกรมมันยืดหยุ่น
IT สามารถเปลี่ยน config ได้เรื่อยๆ

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

(ถ้าโปรแกรมไหนคุยกับ user / IT ลูกค้าแล้ว เป็นงานเฉพาะด้าน นานๆจะแก้โปรแกรมซักที ก็เขียนแบบธรรมดานี่แหละ บางทีก็อาจจะมี Hardcode ในโปรแกรมบ้าง ทำให้อ่านง่ายๆ )

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

ถ้าจำกัด scope ชัดเจนมันจะได้ประมาณนี้ครับ แต่ถ้า scope เปลี่ยนก็ต้องแก้โค๊ดนะ น่าจะแพงกว่าคอนฟิก

เอาจริง ๆ มันเป็นการย้ายคอนฟิกกลับเข้ามาในโค๊ดนะครับ

เขาลอกระบบเก่ามา

โค้ดแบบที่สอง ผมว่าอ่านยากมากเลยนะ โดยเฉพาะคอมเมนต์เยอะ ๆ นี่เกลียดถึงเกลียดมาก ถ้าจะคอมเมนต์จริงๆ ก็ควรให้โค้ดมันอธิบายตัวเองได้ ส่วนตัวผมเองจะเขียนคอมเมนต์เฉพาะจั่วหัวของมัน ไว้ trigger IDE ให้ช่วยเตือนความจำ กับส่วนที่ไม่เมกเซนส์ถ้าไม่เขียนอะไรไว้ โค้ดแบบนี้ส่วนตัวผมคือดีมาก แค่มันเสียเวลาหน่อยตอนเข้ามาทำงานกับมันแรก ๆ (ต่อจากคนอื่น) ยกเว้นเสียว่าเขาอยากจะวางยาคุณให้จ้างเขาต่อไป มันก็อาจจะมีโค้ดหรือพารามิเตอร์ non-standard มาให้เห็นอยู่หน่อย ๆ แต่ก็ไม่ได้เรียนรู้ยากเย็นอะไรนัก
การ declare แยกไฟล์ไว้ ดูเหมือนยุ่งยากนะ แต่จริง ๆ มันคือสวรรค์ของนักเขียนโค้ดแบบผมเลย อยากรู้ค่าอะไรจากโปรแกรมที่คนเดิมเขียนไว้ ก็ไปค้นหาในตัว declare แล้วเอามาเติมโปรแกรม ระบบเดิมได้เลย ไม่ต้อง refactor ทั้งโปรเจกต์ ที่เสี่ยงไปโดนค่าอื่นในโปรแกรมด้วย ยกเว้นว่าชอบ define ไว้ที่หัวฟังก์ชันก็จะเป็นอีกเรื่องหนึ่ง แต่สำหรับผม แบบที่ไว้ข้างนอกมันสะดวกกว่า
มันจริงอยู่ที่โค้ดที่ declare น้อย ๆ คอมเมนต์เยอะ แล้ววิ่งเป็น procedure มันจะอ่านเข้าใจได้ง่ายกว่า แต่ตอนดูแลรักษาโค้ดนี่นรกชัด ๆ โดยเฉพาะตอนที่ต้องมาแก้ไขฟีเจอร์เดิมหรือเปลี่ยนแปลงค่าระบบ ถ้าไม่รื้อใหม่หมดก็คือสร้างใหม่ไปเลย อีกอย่างยิ่งคอมเมนต์เยอะยิ่งพิมพ์โค้ดช้าลง 555

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

ในระยะยาว และระบบที่มีขนาดใหญ่ระบบมีการตั้งค่าและ Config ดี จะมีความยืดหยุ่นในการขยายตัว ตามขนาดองค์กรได้ดีกว่า การ Scale ระบบมันมีทั้ง Vertical และ Horizontal ถ้าระบบรองรับทั้ง 2 รูปแบบมักมี Config ที่ค่อนข้างซับซ้อนนะ อย่างผมนี่เขียนมีทั้ง Config และ Modular เนี่ยคุณน่าจะปวดตับกันเลย แต่ระบบผมเวลาระบบมีปัญหาจะสามารถจะปิดเฉพาะส่วนได้ โดยระบบภาพรวมยังทำงานไปปรกติ เวลามี Bug หรือพลาดก็ไม่กระทบภาพรวม เวลาจะขยายระบบ เช่น Module บางตัวมีการใช้งานสูงมาก ก็แยกไปติดตั้งได้ โดยไม่ต้องแก้ไขโปรแกรม แก้เฉพาะ Config

การแก้ไขปัญหาระบบที่มี Config เยอะ น่าจะเป็นการทำ Document ภายนอกเป็นไฟล์แบบคู่มืออธิบายเอาไว้ เพื่อการตั้งค่า ไม่ใช่เพื่อการแก้ Code นะ เพราะระบบพวกนี้ส่วนใหญ่จะ Extend ออกไป ส่วนไหนที่นิ่งแล้วจะไม่แก้ไข จะใช้วิธี Extend เพื่อเขียนต่อมากกว่า เพียงแต่เมื่อระบบมีขนาดใหญ่มาก งานรีบ อาจมี Class ซ้อนกันอยู่หลาย Class หน่อย โดยเฉพาะถ้าไม่ได้ทำ Design Pattern เอาไว้ด้วยงานรีบ เพราะปรกติของผม จะ Tune ระบบเมื่อระบบนิ่งพอระดับนึงแล้ว ไม่ได้เขียนไป Tune ไป

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