โกหก 2: รหัสควรได้รับการออกแบบรอบ ๆ แบบจำลองของโลกหรือไม่? [ปิด]

ฉันเพิ่งอ่านโพสต์บล็อกของBig Big Liesและฉันมีเวลายากที่จะแก้ไขคำโกหกที่สองซึ่งอ้างถึงที่นี่:

(โกหก # 2) รหัสควรได้รับการออกแบบทั่วทั้งโลก

ไม่มีค่าในรหัสที่เป็นรูปแบบหรือแผนที่โลกจินตนาการ ฉันไม่รู้ว่าทำไมอันนี้ถึงน่าสนใจสำหรับโปรแกรมเมอร์บางคน แต่มันเป็นที่นิยมอย่างมาก หากมีจรวดในเกมให้มั่นใจได้ว่ามีคลาส "Rocket" (สมมติว่าโค้ดคือ C ++) ซึ่งมีข้อมูลสำหรับจรวดหนึ่งอันและทำจรวด โดยไม่คำนึงถึงการเปลี่ยนแปลงข้อมูลจริง ๆ หรือการจัดวางข้อมูล หรือสำหรับเรื่องนั้นโดยที่ไม่มีความเข้าใจพื้นฐานว่ามีสิ่งใดสิ่งหนึ่งอยู่คงมากกว่าหนึ่งสิ่ง

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

นี่คือปัญหาของฉันกับเรื่องโกหกนี้โดยเฉพาะ

1. มีคุณค่าในการใช้รหัสเป็นแบบจำลอง / แผนที่ของโลกจินตนาการในขณะที่การสร้างแบบจำลองโลกแห่งจินตนาการช่วยอย่างน้อยฉันเองเป็นการมองเห็นและจัดระเบียบรหัส

2. สำหรับฉันแล้วการมีคลาส "Rocket" เป็นตัวเลือกที่ถูกต้องสมบูรณ์แบบสำหรับชั้นเรียน บางที "จรวด" อาจถูกแบ่งออกเป็นประเภทของจรวดเช่น AGM-114 Hellfire เป็นต้นซึ่งจะมีความแข็งแกร่งของน้ำหนักบรรทุก, ความเร็วสูงสุด, รัศมีการเลี้ยวสูงสุด, ประเภทการเลี้ยวเป้าหมายและอื่น ๆ แต่จรวดทุกประเภทจะต้องมีตำแหน่ง และความเร็ว

3. แน่นอนว่าการมี 100 จรวดมีราคามากกว่า 1 Rocket หากมี 100 จรวดบนหน้าจอจะต้องมี 100 การคำนวณที่แตกต่างกันเพื่ออัปเดตตำแหน่งของพวกเขา ย่อหน้าที่สองดูเหมือนว่ากำลังอ้างสิทธิ์ว่าหากมี 100 จรวดมันควรมีค่าใช้จ่ายน้อยกว่า 100 การคำนวณเพื่ออัปเดตสถานะหรือไม่

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

ก่อนอื่นมาดูบริบท: นี่คือนักออกแบบเกมที่เขียนในบล็อกที่มีหัวเรื่องที่เปิดใช้งานประสิทธิภาพล่าสุดจาก Cell BE CPU กล่าวอีกอย่างหนึ่ง: มันเกี่ยวกับการเขียนโปรแกรมเกมคอนโซลโดยเฉพาะอย่างยิ่งการเขียนโปรแกรมเกมคอนโซลสำหรับ PlayStation 3

ตอนนี้โปรแกรมเมอร์เกมเป็นกลุ่มที่อยากรู้อยากเห็นโปรแกรมเมอร์เกมคอนโซลมากขึ้นและ Cell BE เป็นซีพียูที่ค่อนข้างแปลก (มีเหตุผลที่ Sony ให้การออกแบบที่ธรรมดากว่าสำหรับ PlayStation 4!)

ดังนั้นเราต้องดูข้อความเหล่านั้นในบริบทนี้

นอกจากนี้ยังมีการทำให้เข้าใจง่ายในการโพสต์บล็อกนั้น โดยเฉพาะอย่างยิ่ง Lie # 2 นี้มีการนำเสนอไม่ดี

ฉันจะยืนยันว่าทุกสิ่งที่เป็นนามธรรมจากโลกแห่งความจริงเป็นแบบอย่างในบางแง่มุม และเนื่องจากซอฟต์แวร์ไม่ใช่ของจริง แต่เป็นเสมือนมันเป็นสิ่งที่เป็นนามธรรมและทำให้เป็นแบบอย่างเสมอ แต่! แบบจำลองไม่จำเป็นต้องมีการทำแผนที่แบบสะอาด 1: 1 สู่โลกแห่งความเป็นจริง นั่นคือสิ่งที่ทำให้มันเป็นแบบอย่างในตอนแรก

ดังนั้นในบางแง่ผู้เขียนผิดอย่างชัดเจน: ซอฟต์แวร์เป็นรูปแบบ ระยะเวลา ในอีกแง่หนึ่งเขาพูดถูก: โมเดลนั้นไม่จำเป็นต้องคล้ายโลกแห่งความจริงเลย

ฉันจะยกตัวอย่างที่ฉันได้ให้ไปแล้วในคำตอบอื่น ๆ ในช่วงหลายปีที่ผ่านมา (ใน) แนะนำบัญชีธนาคาร OO 101 ที่มีชื่อเสียง นี่คือลักษณะของบัญชีธนาคารในเกือบทุกระดับ OO:

class Account {
  var balance: Decimal
  def transfer(amount: Decimal, target: Account) = {
    balance -= amount
    target.balance += amount
  }
}

ดังนั้นที่: balanceเป็นข้อมูลและtransferเป็นการดำเนินงาน

แต่! นี่คือลักษณะของบัญชีธนาคารในเกือบทุกซอฟต์แวร์ธนาคาร:

class TransactionSlip {
  val transfer(amount: Decimal, from: Account, to: Account)
}

class Account {
  def balance = 
    TransactionLog.filter(t => t.to == this).map(_.amount).sum - 
    TransactionLog.filter(t => t.from == this).map(_.amount).sum
}

ดังนั้นตอนนี้transferเป็นข้อมูลและbalanceเป็นการดำเนินการ (ครึ่งทางซ้ายของบันทึกธุรกรรม) (คุณจะสังเกตเห็นว่าTransactionSlipมันไม่เปลี่ยนรูปbalanceเป็นฟังก์ชั่นที่บริสุทธิ์TransactionLogสามารถผนวก "โครงสร้างข้อมูลที่ไม่เปลี่ยนรูปแบบ" เกือบเท่านั้น "... ฉันแน่ใจว่าพวกคุณหลายคนเห็นข้อบกพร่องที่เกิดขึ้นพร้อมกันที่เห็นได้ชัดในการใช้งานครั้งแรก .)

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

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

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

อย่างไรก็ตามความจริงที่ว่ารุ่นที่สองนี้ตรงกับทั้งการทำงานของธนาคารในโลกแห่งความเป็นจริงและวิธีการทำงานของซอฟต์แวร์การธนาคารในโลกแห่งความเป็นจริงไม่ได้ทำให้ "ถูกต้อง" มากขึ้นโดยอัตโนมัติ เพราะในความเป็นจริงที่แรก ( "ผิด") รุ่นที่ค่อนข้างใกล้ชิดใกล้เคียงกับวิธีการที่ธนาคารลูกค้าดูธนาคารของพวกเขา เพื่อให้พวกเขา , transferเป็นการดำเนินงาน (พวกเขาจะต้องกรอกแบบฟอร์ม) และbalanceเป็นชิ้นส่วนของข้อมูลที่ด้านล่างของใบแจ้งยอดบัญชีของพวกเขา

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

ฉันไม่เห็นด้วยกับ "การโกหก" ที่เขาเสนอ

TL; DRผู้เขียนบทความนี้พยายามที่จะแย้งเพื่อทำให้บทความของพวกเขาน่าสนใจยิ่งขึ้น แต่การที่เรียกว่า "การโกหก" นั้นได้รับการยอมรับจากนักพัฒนาซอฟต์แวร์ด้วยเหตุผลที่ดี

Lie # 1 - Big O มีความสำคัญสำหรับการปรับขนาด ไม่มีใครสนใจถ้าแอปพลิเคชั่นขนาดเล็กใช้เวลานานขึ้นซึ่งเป็นค่าคงที่เพียงครั้งเดียวเท่านั้นพวกเขาสนใจว่าเมื่อพวกเขาเพิ่มขนาดอินพุตเป็นสองเท่ามันจะไม่คูณเวลาดำเนินการคูณด้วย 10

Lie # 2 - โปรแกรมจำลองหลังจากโลกแห่งความเป็นจริงอนุญาตให้โปรแกรมเมอร์ดูโค้ดของคุณในอีก 3 ปีต่อมาเพื่อให้เข้าใจได้ง่ายว่ามันทำอะไรอยู่ รหัสจะต้องสามารถบำรุงรักษาได้หรือคุณจะต้องใช้เวลาหลายชั่วโมงเพียงแค่พยายามเข้าใจว่าโปรแกรมกำลังพยายามทำอะไร คำตอบอื่นชี้ให้เห็นว่าคุณสามารถมีชั้นเรียนทั่วไปมากขึ้นเช่นและLaunchPad MassiveDeviceMoverสิ่งเหล่านี้ไม่จำเป็นต้องมีคลาสที่ไม่ดี แต่คุณยังต้องการRocketคลาส มีใครควรรู้ได้อย่างไรMassiveDeviceMoverว่ามันทำอะไรหรือมันเคลื่อนที่อย่างไร มันเคลื่อนไหวภูเขายานอวกาศหรือดาวเคราะห์? ซึ่งโดยทั่วไปหมายถึงการเพิ่มคลาสอย่างเช่นMassiveDeviceMoverทำให้โปรแกรมของคุณมีประสิทธิภาพลดลง (แต่อาจเป็นวิธีที่อ่านและเข้าใจได้ง่ายขึ้น)

นอกจากนี้ค่าใช้จ่ายของนักพัฒนาเริ่มสูงกว่าต้นทุนของฮาร์ดแวร์เมื่อนานมาแล้ว มันเป็นความคิดที่น่ากลัวที่จะเริ่มต้นพยายามออกแบบด้วยการปรับให้เหมาะสมที่ด้านหน้าของความคิดของคุณ คุณเขียนโปรแกรมด้วยวิธีที่ง่ายและเข้าใจได้จากนั้นปรับแต่งโปรแกรมของคุณหลังจากค้นหาว่าส่วนใดของโปรแกรมของคุณใช้เวลาในการรันนานมาก อย่าลืม: 80% ของเวลาดำเนินการถูกใช้ไป 20% ของโปรแกรม

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

ในระบบอีคอมเมิร์ซคุณไม่ได้จัดการกับ "จรวด" ในระดับชั้นคุณต้องจัดการกับ "ผลิตภัณฑ์" ดังนั้นมันขึ้นอยู่กับสิ่งที่คุณพยายามจะทำและระดับที่คุณต้องการให้เป็นนามธรรม

ในเกมมันอาจเป็นที่ถกเถียงกันอยู่ว่าจรวดเป็นเพียงหนึ่งใน "วัตถุเคลื่อนที่" หลายประเภท ฟิสิกส์เดียวกันนี้นำไปใช้กับวัตถุเคลื่อนที่อื่น ๆ อย่างน้อยที่สุด "จรวด" ก็จะสืบทอดจากคลาสพื้นฐาน "วัตถุเคลื่อนที่" ทั่วไป

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

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

ในทำนองเดียวกันโลกแห่งความจริงก็มีคุณสมบัติที่มีประโยชน์มากมายที่เราวางใจ มันง่ายมากที่จะสร้างข้อยกเว้นของนกเพนกวิน - "นกทุกตัวบินยกเว้น ... " และมันง่ายมากที่จะทำสิ่งต่าง ๆ เป็นจรวดฉันหมายถึงถ้าฉันเรียกมันว่าเพนกวินจรวดและจุดสว่างมัน ... มันใช้งานไม่ได้

ดังนั้นวิธีที่เราแยกสิ่งต่าง ๆ ในโลกแห่งความคิดทำงานภายใต้ข้อ จำกัด เหล่านั้น เมื่อเราทำสิ่งต่าง ๆ ในรหัสเราควรแยกสิ่งต่าง ๆ ให้ทำงานได้ดีภายใต้ข้อ จำกัดเหล่านั้นซึ่งแตกต่างกันอย่างแน่นอน

ทางเลือกคืออะไร?

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

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

ทางเลือกคือการสร้างแบบจำลองสิ่งที่โปรแกรมของคุณใส่ใจ Rocketแม้ว่าข้อเสนอที่โปรแกรมของคุณด้วยจรวดคุณอาจไม่จำเป็นต้องมีนิติบุคคลที่เรียกว่า ตัวอย่างเช่นคุณอาจมีLaunchPadนิติบุคคลและLaunchScheduleนิติบุคคลและMassiveDeviceMoverนิติบุคคล ความจริงที่ว่าทั้งหมดนี้ช่วยในการปล่อยจรวดไม่ได้หมายความว่าคุณกำลังจัดการกับจรวดด้วยตนเอง

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

นี่เป็นปัญหาที่แท้จริง แต่ฉันจะให้เวลากับคุณในฐานะนักพัฒนาบางทีนั่นอาจจะช่วยได้

ครั้งแรกฉันจะไม่เรียกมันว่าเป็นความเข้าใจผิดทั่วไป การเรียกมันว่าเป็นเรื่องจริง

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

Three Sounds นิดหน่อยสำหรับฉัน แต่โดยพื้นฐานแล้วเขาถูกต้องอีกครั้ง แต่สิ่งนี้อาจถูกเขียนใหม่เพื่อ "เขียนโค้ดตามความต้องการของคุณอย่าพยายามปรับให้เหมาะกับความต้องการของคุณ"

สองอีกครั้งที่นี่เขาถูกต้อง ฉันได้เห็นนักพัฒนาใช้เวลาหลายสัปดาห์หรือนานกว่านั้นในการพัฒนาคลาส "จรวด" เมื่อคลาส "ยานพาหนะ" ง่าย ๆ จะใช้งานได้หรือเป็นคลาสที่ "ง่ายขึ้น" ถ้าจรวดของคุณต้องทำก็คือย้ายจากด้านซ้ายของหน้าจอไปทางขวาและทำเสียงคุณสามารถใช้คลาสเดียวกับที่คุณทำกับรถยนต์รถไฟเรือและแมลงวัน 100 ควรมีค่าใช้จ่ายน้อยกว่า 1 * 100 อาร์กิวเมนต์ที่ดูเหมือนว่าจะใช้เวลาในการพัฒนาและไม่มากในการคำนวณค่าใช้จ่าย แม้ว่าการยึดติดกับคลาสทั่วไปที่น้อยกว่าที่นำมาใช้ซ้ำคือ "ถูกกว่า" แต่คลาสที่เฉพาะเจาะจงจำนวนมากที่ไม่สามารถใช้ซ้ำได้ สิ่งนี้อาจถูกเขียนใหม่เนื่องจาก "คลาสทั่วไปนั้นดีกว่าคลาสเฉพาะ

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

One note ล่าสุดบทความถูกเขียนในปี 2008 (ดีที่สุดที่ฉันบอกได้) สิ่งต่าง ๆ เปลี่ยนแปลงอย่างรวดเร็ว งบเป็นจริงในวันนี้ แต่ระบบฝังตัวเป็นเรื่องธรรมดามากในวันนี้แล้วย้อนกลับไปและรูปแบบการพัฒนาเปลี่ยนไป บางทีแม้แต่ในการตอบสนองต่อบทความ / พูดคุยนี้

ฉันพบว่ามันน่าสนใจที่สิ่งเหล่านี้ตั้งอยู่ตรงกลางความกังวลด้านวิชาการ: แพลตฟอร์มประสิทธิภาพของการใช้หน่วยความจำและข้อมูล แต่มันก็ไม่สนใจองค์ประกอบของมนุษย์อย่างสมบูรณ์

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

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

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

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