ให้ฉันถามคำถามตอบโต้กับคุณอย่างจริงจัง: ในมุมมองของคุณอะไรคือความแตกต่างระหว่าง "data" และ "code"?
เมื่อฉันได้ยินคำว่า "ข้อมูล" ฉันคิดว่า "รัฐ" ข้อมูลคือคำจำกัดความสิ่งที่แอปพลิเคชันนั้นออกแบบมาเพื่อจัดการและดังนั้นสิ่งที่แอพพลิเคชั่นไม่สามารถรู้ได้ในเวลารวบรวม มันเป็นไปไม่ได้ที่จะใช้ข้อมูลรหัสฮาร์ดเพราะทันทีที่คุณทำฮาร์โค้ดมันจะกลายเป็นพฤติกรรม
ประเภทของข้อมูลแตกต่างกันไปตามแอปพลิเคชัน; ระบบการออกใบแจ้งหนี้เชิงพาณิชย์อาจจัดเก็บข้อมูลลูกค้าและข้อมูลการสั่งซื้อในฐานข้อมูล SQL และโปรแกรมกราฟิกแบบเวกเตอร์อาจเก็บข้อมูลเรขาคณิตและข้อมูลเมตาในไฟล์ไบนารี ในทั้งสองกรณีนี้และทุกสิ่งในระหว่างนั้นมีการแยกที่ชัดเจนและไม่สามารถแยกได้ระหว่างโค้ดและข้อมูล ข้อมูลเป็นของผู้ใช้ไม่ใช่โปรแกรมเมอร์ดังนั้นจึงไม่มีการกำหนดรหัสตายตัว
สิ่งที่คุณกำลังพูดถึงคือการใช้คำอธิบายที่ถูกต้องทางเทคนิคที่สุดสำหรับคำศัพท์ปัจจุบันของฉัน: ข้อมูลที่ควบคุมพฤติกรรมของโปรแกรมซึ่งไม่ได้เขียนด้วยภาษาโปรแกรมหลักที่ใช้ในการพัฒนาแอปพลิเคชั่นส่วนใหญ่
แม้คำจำกัดความนี้ซึ่งค่อนข้างคลุมเครือน้อยกว่าคำว่า "ข้อมูล" ก็มีปัญหาเล็กน้อย ตัวอย่างเช่นถ้าส่วนสำคัญของโปรแกรมแต่ละรายการเขียนด้วยภาษาต่างกัน ฉันได้ทำงานส่วนตัวในหลายโครงการซึ่งมีประมาณ 50% C # และ 50% JavaScript รหัส JavaScript คือ "data" หรือไม่? คนส่วนใหญ่จะบอกว่าไม่มี แล้ว HTML คืออะไร "data" คนส่วนใหญ่ยังคงบอกว่าไม่มี
แล้ว CSS ล่ะ ข้อมูลหรือรหัสนั่นคืออะไร? หากเราคิดว่าโค้ดเป็นสิ่งที่ควบคุมพฤติกรรมของโปรแกรม CSS นั้นไม่ได้เป็นโค้ดจริงๆเพราะมันมีผลกระทบต่อรูปลักษณ์ภายนอกเท่านั้น แต่มันก็ไม่ใช่ข้อมูลจริงๆ ผู้ใช้ไม่ได้เป็นเจ้าของแอปพลิเคชันไม่ได้เป็นเจ้าของจริงๆ มันเทียบเท่ากับรหัสสำหรับนักออกแบบ UI มันเป็นรหัสเหมือนแต่ไม่ได้รหัสมาก
ผมอาจจะเรียก CSS ชนิดของการกำหนดค่า แต่ความหมายในทางปฏิบัติมากขึ้นก็คือว่ามันเป็นเพียงรหัสในโดเมนภาษาเฉพาะ นั่นคือสิ่งที่ XML, YAML และ "ไฟล์ที่จัดรูปแบบ" ของคุณเป็นตัวแทน และเหตุผลที่เราใช้ภาษาเฉพาะโดเมนก็คือโดยทั่วไปแล้วมันมีความกระชับและแสดงออกในโดเมนเฉพาะมากกว่าการเข้ารหัสข้อมูลเดียวกันในภาษาโปรแกรมทั่วไปเช่น C หรือ C # หรือ Java
คุณรู้จักรูปแบบต่อไปนี้หรือไม่?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
ฉันแน่ใจว่าคนส่วนใหญ่ทำ; มันJSON และนี่คือสิ่งที่น่าสนใจเกี่ยวกับ JSON: ใน JavaScript มันเป็นรหัสที่ชัดเจนและในทุก ๆ ภาษามันเป็นข้อมูลที่จัดรูปแบบอย่างชัดเจน เกือบทุกภาษาการเขียนโปรแกรมหลักเดียวมีอย่างน้อยหนึ่งไลบรารีสำหรับ "การแยกวิเคราะห์" JSON
หากเราใช้ไวยากรณ์เดียวกันนั้นภายในฟังก์ชั่นในไฟล์ JavaScript มันก็ไม่สามารถเป็นอย่างอื่นได้นอกจากรหัส และถ้าเราใช้ JSON นั้นจงผลักมันเป็น.jsonไฟล์และแยกมันในแอปพลิเคชัน Java ทันใดนั้นมันก็คือ "ข้อมูล" มันสมเหตุสมผลจริงๆเหรอ?
ฉันยืนยันว่า "data-ness" หรือ "configuration-ness" หรือ "code-ness" นั้นมีอยู่ในตัวของสิ่งที่ถูกอธิบายไม่ใช่วิธีอธิบาย
หากโปรแกรมของคุณต้องการพจนานุกรม 1 ล้านคำเพื่อที่จะสร้างวลีรหัสผ่านแบบสุ่มคุณต้องการให้รหัสเช่นนี้หรือไม่:
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
หรือคุณจะผลักคำเหล่านั้นออกเป็นไฟล์ข้อความที่คั่นด้วยเส้นแล้วบอกให้โปรแกรมของคุณอ่าน ไม่สำคัญว่ารายการคำจะไม่เปลี่ยนแปลงหรือไม่ไม่ใช่ว่าคุณกำลังเข้ารหัสยากหรือเข้ารหัสนุ่มนวล (ซึ่งหลายคนคิดว่าเป็นรูปแบบการต่อต้านเมื่อนำมาใช้อย่างไม่เหมาะสม) มันเป็นคำถามของ รูปแบบใดมีประสิทธิภาพมากที่สุดและทำให้ง่ายที่สุดในการอธิบาย "สิ่งของ" ไม่ว่า "สิ่งของ" คืออะไร มันไม่เกี่ยวข้องอย่างเป็นธรรมไม่ว่าคุณจะเรียกมันว่ารหัสหรือข้อมูล เป็นข้อมูลที่โปรแกรมของคุณต้องการเพื่อเรียกใช้และรูปแบบไฟล์แบบแฟลตเป็นวิธีที่สะดวกที่สุดในการจัดการและบำรุงรักษา
สมมติว่าคุณทำตามแนวทางปฏิบัติที่ถูกต้องทุกสิ่งนี้จะเข้าสู่การควบคุมแหล่งต่อไปดังนั้นคุณอาจเรียกมันว่ารหัสเพียงโค้ดในรูปแบบที่แตกต่างกันและอาจจะเรียบง่ายมาก หรือคุณสามารถเรียกมันว่าการกำหนดค่า แต่สิ่งเดียวที่แยกความแตกต่างของรหัสจากการกำหนดค่าคือการที่คุณจัดทำเอกสารและบอกผู้ใช้ถึงวิธีการเปลี่ยนแปลง คุณอาจจะสามารถคิดค้นอาร์กิวเมนต์เถื่อนเกี่ยวกับการกำหนดค่าที่ถูกตีความในเวลาเริ่มต้นหรือรันไทม์และไม่ใช่ในเวลารวบรวม แต่จากนั้นคุณจะเริ่มอธิบายภาษาที่มีการพิมพ์แบบไดนามิกหลายอย่างและเกือบจะแน่นอนทุกอย่างกับเครื่องยนต์สคริปต์ที่ฝังอยู่ภายใน เกมส่วนใหญ่) รหัสและการกำหนดค่าเป็นสิ่งที่คุณตัดสินใจติดป้ายกำกับว่าไม่มีอะไรมากไม่น้อยไปกว่านี้
ขณะนี้มีเป็นอันตรายต่อexternalizingข้อมูลที่ไม่ปลอดภัยจริงในการปรับเปลี่ยน (ดูการเชื่อมโยง "อ่อนเข้ารหัส" ด้านบน) หากคุณส่งออกอาเรย์เสียงสระของคุณในไฟล์กำหนดค่าและบันทึกเป็นไฟล์การกำหนดค่าให้กับผู้ใช้ปลายทางของคุณคุณกำลังให้วิธีที่แทบจะไม่สามารถทำลายแอพของคุณได้ทันทีตัวอย่างเช่นการใส่ "q" เป็นเสียงสระ แต่นั่นไม่ใช่ปัญหาพื้นฐานกับ "การแยกรหัสและข้อมูล" มันเป็นความรู้สึกที่ไม่ดีนัก
สิ่งที่ฉันบอกให้กับผู้พัฒนาระบบรองคือพวกเขาควรปรับการตั้งค่าภายนอกที่พวกเขาคาดว่าจะเปลี่ยนแปลงตามสภาพแวดล้อม ซึ่งรวมถึงสิ่งต่าง ๆ เช่นสตริงการเชื่อมต่อชื่อผู้ใช้คีย์ API เส้นทางไดเรกทอรีและอื่น ๆ พวกเขาอาจจะเหมือนกันในกล่อง dev ของคุณและในการผลิต แต่อาจจะไม่และ sysadmins จะตัดสินใจว่าพวกเขาต้องการให้มันดูในการผลิตไม่ใช่ devs ดังนั้นคุณต้องมีวิธีหนึ่งในการตั้งค่ากลุ่มหนึ่งที่ใช้กับเครื่องบางเครื่องและการตั้งค่าอื่น ๆ ที่ใช้กับเครื่องอื่น ๆ - เพราะฉะนั้น, ไฟล์กำหนดค่าภายนอก (หรือการตั้งค่าในฐานข้อมูล ฯลฯ )
แต่ฉันเน้นว่าการใส่ "ข้อมูล" ลงในไฟล์ "" นั้นไม่เหมือนกับการส่งออกไปเป็นการกำหนดค่า การใส่พจนานุกรมคำศัพท์ลงในไฟล์ข้อความไม่ได้หมายความว่าคุณต้องการให้ผู้ใช้ (หรือ IT) เปลี่ยนแปลงมันเป็นเพียงวิธีที่ทำให้นักพัฒนาซอฟต์แวร์เข้าใจได้ง่ายขึ้นว่าเกิดอะไรขึ้นและหากจำเป็น การเปลี่ยนแปลงเป็นครั้งคราว ในทำนองเดียวกันการวางข้อมูลเดียวกันในตารางฐานข้อมูลไม่จำเป็นต้องนับว่าเป็นการกระทำภายนอกถ้าหากตารางนั้นเป็นแบบอ่านอย่างเดียวและ / หรือ DBA จะได้รับคำสั่งไม่ให้คลาดเคลื่อน การกำหนดค่าแสดงถึงข้อมูลที่ไม่แน่นอน แต่ในความเป็นจริงที่กำหนดโดยกระบวนการและความรับผิดชอบมากกว่าการเลือกรูปแบบ
ดังนั้นเพื่อสรุป:
"รหัส" ไม่ใช่คำที่กำหนดอย่างเข้มงวด หากคุณขยายคำจำกัดความของคุณให้ครอบคลุมภาษาเฉพาะโดเมนและสิ่งอื่นที่มีผลต่อพฤติกรรมความเสียดทานที่เห็นได้ชัดนี้จะหายไปและมันก็สมเหตุสมผล คุณสามารถมี "รหัส" DSL ที่ไม่ได้คอมไพล์ในไฟล์แฟล็ต
"ข้อมูล" หมายถึงข้อมูลที่เป็นของผู้ใช้หรืออย่างน้อยคนอื่นที่ไม่ใช่นักพัฒนาและโดยทั่วไปไม่สามารถใช้ได้ในเวลาออกแบบ มันไม่สามารถเขียนรหัสแบบยาก ๆ ได้แม้ว่าคุณต้องการทำเช่นนั้น ด้วยข้อยกเว้นที่เป็นไปได้ของรหัสการแก้ไขด้วยตนเองการแยกระหว่างรหัสและข้อมูลเป็นเรื่องของการกำหนดไม่ใช่การตั้งค่าส่วนตัว
"Soft-coding" อาจเป็นวิธีปฏิบัติที่เลวร้ายเมื่อนำไปใช้มากเกินไป แต่ไม่ใช่ทุกกรณีของการทำ externalization ที่จำเป็นต้องใช้ soft-coding และหลาย ๆ กรณีของการจัดเก็บข้อมูลใน
การกำหนดค่าเป็นชนิดพิเศษนุ่มเข้ารหัสที่เป็นสิ่งจำเป็นเพราะความรู้ที่ว่าโปรแกรมประยุกต์อาจต้องทำงานในสภาพแวดล้อมที่แตกต่างกัน การปรับใช้ไฟล์การกำหนดค่าแยกต่างหากพร้อมกับแอปพลิเคชันนั้นทำงานได้น้อยลง (และอันตรายน้อยกว่า) กว่าการปรับใช้รหัสรุ่นที่แตกต่างกันไปในทุกสภาพแวดล้อม ดังนั้นการเข้ารหัสแบบ soft บางชนิดจึงมีประโยชน์จริง