เวนเดอร์เจ้าขนาดกลาง หรือ ขนาดใหญ่ ไปจนถึงบริษัทข้ามชาติเลย มักจะเขียนโค้ดให้อ่านยาก ๆ
มีเซตติ้งค่านู่นนั่นนี่ ดีแคร์วกไปวนมา แยกไฟล์ ลิงค์ไฟล์ ยุ่งเหยิงไปหมด จนต้องจ้างให้สต๊าฟเขามา
นั่งเป็นเอ้าต์ซอร์สดูแลระบบให้ จนไปถึงจ้างเขาพัฒนาเพิ่มเติม สัญญาจ้างสามเดือนหกเดือนไปเรื่อย ๆ
สลัดยังไงก็ไม่หลุด ยิ่งเขาอยู่นาน ระบบยิ่งบานออกเยอะ ทีมในองค์กรก็ดูโค้ดดูการตั้งค่าเขาไม่ออก
ต้องพึ่งพาเขาไปเรื่อย ๆ ถ้าไม่มีเขา สต๊าฟของบริษัทผู้ว่าจ้างก็ไปต่อไม่เป็น
ส่วนเจ้าเล็ก ๆ โดยเฉพาะบริษัทตั้งใหม่ของเด็กเจ็นวาย หรือ แซด มักจะเขียนโค้ดให้ดูง่าย อ่านง่าย
คอมเมนท์เยอะ ลดการตั้งค่า การประกาศ หรือความยุ่งเหยิงของระบบให้เหลือน้อยที่สุด เพื่อที่เขาจะส่งงาน
ให้คนในองค์กรเอาไปดูแลต่อได้ สามารถอ่านโค้ดออกได้โดยง่าย ชัดเจน ไม่ยุ่งเหยิง วกวน ซ่อนเงื่อน
เพราะเขาไม่อยากโดนคอล โดนโทรจิก หรือตามให้มาพัฒนาเพิ่มเติมอะไรให้ เขาอยากไปเปิดงานตัวใหม่ ๆ
เขาอยากใช้เทคโนโลยีใหม่ ๆ ไปเรื่อย ๆ
ใครมีประสบการณ์ยังไงมาแชร์กันได้ครับ ผมอายุเยอะแล้ว ผ่านมาทั้งงานประจำ เอ้าซอร์ส ฟรีแลนซ์
ตอนนี้ร่วมงานกับคนรุ่นใหม่ยังหนุ่มแน่น ทำให้กระชุ่มกระชวยและรู้สึกดีมาก ๆ ครับ เพิ่งก้าวออกจากคอมฟอร์ทโซน
มาได้เดือนกว่า ๆ เองครับ แต่ไม่รู้สึกถึงความเป็นกรรมกรห้องแอร์อย่างแต่ก่อนเลย อยากตื่นเช้าไปทำงาน
อยากให้ถึงวันจันทร์เร็ว ๆ ไม่ชอบหยุดยาว ๆ
เอาเป็นว่าผมทำในส่วนขององค์กร
gift099 Mon, 12/10/2020 - 09:06
เอาเป็นว่าผมทำในส่วนขององค์กรใหญ่ละกันนะ
เขียนยากมี setting นู่นนี่ ส่วนนึงเกิดจาก อยากให้โปรแกรมมันยืดหยุ่น
IT สามารถเปลี่ยน config ได้เรื่อยๆ
ดูเหมือนยากนะ แต่ระยะยาวก็ดูจะประหยัดกว่า ถ้าหากว่าเขียนโปรแกรมเพื่องานใดงานหนึ่งเฉพาะ
เวลาจะแก้ทีก็ต้องจ้างคนมาเพิ่มนู้นนี่จากโปรแกรมเดิม
บางทีแก้ไขจากโปรแกรมเดิมไม่ได้ด้วย
ต้องสร้างโปรแกรมใหม่ขึ้นมาเพื่อทำงานอีกอย่าง
(ถ้าโปรแกรมไหนคุยกับ user / IT ลูกค้าแล้ว เป็นงานเฉพาะด้าน นานๆจะแก้โปรแกรมซักที ก็เขียนแบบธรรมดานี่แหละ บางทีก็อาจจะมี Hardcode ในโปรแกรมบ้าง ทำให้อ่านง่ายๆ )
+1 โครงสร้างดี ปรับระบบง่าย
b98se Mon, 12/10/2020 - 10:55
In reply to เอาเป็นว่าผมทำในส่วนขององค์กร by gift099
+1 โครงสร้างดี ปรับระบบง่าย
เห็นด้วยครับ
ZiiT Tue, 13/10/2020 - 20:20
In reply to เอาเป็นว่าผมทำในส่วนขององค์กร by gift099
เห็นด้วยครับ
จากประโยคนี้ของเจ้าของโพสต์ "ทีมในองค์กรก็ดูโค้ดดูการตั้งค่าเขาไม่ออก"
ผมว่าต้องกลับไปดูว่าทาง ผู้พัฒนา over-engineered หรือว่าทาง Owner นั้นประสบการณ์น้อยครับ จะได้แก้ถูกจุด
ส่วนเจ้าเล็ก ๆ
mr_tawan Wed, 14/10/2020 - 10:28
ถ้าจำกัด scope ชัดเจนมันจะได้ประมาณนี้ครับ แต่ถ้า scope เปลี่ยนก็ต้องแก้โค๊ดนะ น่าจะแพงกว่าคอนฟิก
เอาจริง ๆ มันเป็นการย้ายคอนฟิกกลับเข้ามาในโค๊ดนะครับ
เขาลอกระบบเก่ามา
udornrt Thu, 15/10/2020 - 08:49
เขาลอกระบบเก่ามา
เห็นด้วย
langisser Fri, 16/10/2020 - 20:59
In reply to เขาลอกระบบเก่ามา by udornrt
เห็นด้วย
คือเอามาก็แก้ๆให้ทันทำงานได้ ส่วนไหนไม่รู้ก็ไม่แตะ บางอันของเก่าก็ทำได้แต่คนเขียนไม่เข้าใจก็เขียนเพิ่มโมดูลเข้าไปอีก
เห็นด้วย
langisser Sat, 17/10/2020 - 11:18
In reply to เขาลอกระบบเก่ามา by udornrt
เห็นด้วย
คือเอามาก็แก้ๆให้ทันทำงานได้ ส่วนไหนไม่รู้ก็ไม่แตะ บางอันของเก่าก็ทำได้แต่คนเขียนไม่เข้าใจก็เขียนเพิ่มโมดูลเข้าไปอีก
ีโค้ดที่สองที่คุณยกตัวอย่างมา
big50000 Thu, 15/10/2020 - 11:26
โค้ดแบบที่สอง ผมว่าอ่านยากมากเลยนะ โดยเฉพาะคอมเมนต์เยอะ ๆ นี่เกลียดถึงเกลียดมาก ถ้าจะคอมเมนต์จริงๆ ก็ควรให้โค้ดมันอธิบายตัวเองได้ ส่วนตัวผมเองจะเขียนคอมเมนต์เฉพาะจั่วหัวของมัน ไว้ trigger IDE ให้ช่วยเตือนความจำ กับส่วนที่ไม่เมกเซนส์ถ้าไม่เขียนอะไรไว้ โค้ดแบบนี้ส่วนตัวผมคือดีมาก แค่มันเสียเวลาหน่อยตอนเข้ามาทำงานกับมันแรก ๆ (ต่อจากคนอื่น) ยกเว้นเสียว่าเขาอยากจะวางยาคุณให้จ้างเขาต่อไป มันก็อาจจะมีโค้ดหรือพารามิเตอร์ non-standard มาให้เห็นอยู่หน่อย ๆ แต่ก็ไม่ได้เรียนรู้ยากเย็นอะไรนัก
การ declare แยกไฟล์ไว้ ดูเหมือนยุ่งยากนะ แต่จริง ๆ มันคือสวรรค์ของนักเขียนโค้ดแบบผมเลย อยากรู้ค่าอะไรจากโปรแกรมที่คนเดิมเขียนไว้ ก็ไปค้นหาในตัว declare แล้วเอามาเติมโปรแกรม ระบบเดิมได้เลย ไม่ต้อง refactor ทั้งโปรเจกต์ ที่เสี่ยงไปโดนค่าอื่นในโปรแกรมด้วย ยกเว้นว่าชอบ define ไว้ที่หัวฟังก์ชันก็จะเป็นอีกเรื่องหนึ่ง แต่สำหรับผม แบบที่ไว้ข้างนอกมันสะดวกกว่า
มันจริงอยู่ที่โค้ดที่ declare น้อย ๆ คอมเมนต์เยอะ แล้ววิ่งเป็น procedure มันจะอ่านเข้าใจได้ง่ายกว่า แต่ตอนดูแลรักษาโค้ดนี่นรกชัด ๆ โดยเฉพาะตอนที่ต้องมาแก้ไขฟีเจอร์เดิมหรือเปลี่ยนแปลงค่าระบบ ถ้าไม่รื้อใหม่หมดก็คือสร้างใหม่ไปเลย อีกอย่างยิ่งคอมเมนต์เยอะยิ่งพิมพ์โค้ดช้าลง 555
ปล. จริง ๆ ผมก็คนรุ่นใหม่ gen z นะ แต่เห็นโค้ดคนรุ่นเดียวกันแล้ว ถ้าไม่ได้เรียนหนักจริงคือได้แต่ส่ายหัว อ่านง่ายก็จริงนะ แต่มันไม่ได้เรื่องเอาเสียเลย โค้ดตัวใหญ่มาก แถมแก้ทีต้องแก้ตัวอื่นไปพร้อมกันอีกด้วย เห็นแล้วสับสนแทน
ในระยะยาว
akira Thu, 22/10/2020 - 07:48
ในระยะยาว และระบบที่มีขนาดใหญ่ระบบมีการตั้งค่าและ 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