ไฟล์ config กลายเป็นภาษาโปรแกรมที่จุดใด

ฉันใช้ไฟล์ config และความสัมพันธ์กับโค้ดมาระยะหนึ่งแล้วและขึ้นอยู่กับวันและทิศทางของลมความคิดเห็นของฉันดูเหมือนจะเปลี่ยนไป มากขึ้นเรื่อย ๆ แม้ว่าฉันจะกลับมาสู่การตระหนักรู้ครั้งแรกในขณะที่เรียนรู้ Lisp: มีความแตกต่างเล็กน้อยระหว่างข้อมูลและรหัส สิ่งนี้ดูเหมือนจะเป็นจริงทวีคูณสำหรับไฟล์ config เมื่อมองในแง่ที่ถูกต้องสคริปต์ Perl จะมากกว่าไฟล์ config สำหรับ perl เล็กน้อย สิ่งนี้มีแนวโน้มที่จะส่งผลที่ค่อนข้างหนักสำหรับงานเช่น QA และแผนกต่างๆเช่นใครควรรับผิดชอบในการเปลี่ยนไฟล์ config

การคืบจากไฟล์กำหนดค่าไปเป็นภาษาที่สมบูรณ์โดยทั่วไปจะทำงานช้าและดูเหมือนว่าจะได้รับแรงหนุนจากความปรารถนาที่จะมีระบบทั่วไป โปรเจ็กต์ส่วนใหญ่ดูเหมือนจะเริ่มต้นเล็ก ๆ ด้วยรายการกำหนดค่าบางอย่างเช่นตำแหน่งที่จะเขียนบันทึกค้นหาข้อมูลชื่อผู้ใช้และรหัสผ่าน ฯลฯ แต่จากนั้นพวกเขาก็เริ่มเติบโตขึ้น: ฟีเจอร์ต่างๆเริ่มที่จะสามารถเปิดหรือปิดได้ การกำหนดเวลาและลำดับของการดำเนินการเริ่มได้รับการควบคุมและบางคนต้องการเริ่มเพิ่มลอจิกเข้าไปอย่างหลีกเลี่ยงไม่ได้ (เช่นใช้ 10 ถ้าเครื่องเป็น X และ 15 ถ้าเครื่องเป็น Y) เมื่อถึงจุดหนึ่งไฟล์ config จะกลายเป็นภาษาเฉพาะของโดเมนและภาษาที่เขียนไม่ดี

ตอนนี้ฉันได้เดินเตร่เพื่อตั้งเวทีคำถามของฉันมีดังนี้:

1. วัตถุประสงค์ที่แท้จริงของไฟล์กำหนดค่าคืออะไร?
2. ควรพยายามทำให้ไฟล์ config เป็นเรื่องง่ายหรือไม่?
3. ใครควรรับผิดชอบในการเปลี่ยนแปลงสิ่งเหล่านี้ (นักพัฒนาผู้ใช้ผู้ดูแลระบบ ฯลฯ )
4. ควรควบคุมแหล่งที่มา (ดูคำถาม 3)?

อย่างที่ฉันได้กล่าวไปก่อนหน้านี้คำตอบของฉันสำหรับคำถามเหล่านี้เปลี่ยนไปเรื่อย ๆ แต่ตอนนี้ฉันกำลังคิดว่า:

1. เพื่อให้ผู้ที่ไม่ใช่โปรแกรมเมอร์สามารถเปลี่ยนแปลงพฤติกรรมจำนวนมากได้อย่างรวดเร็ว
2. ใช่สิ่งที่ไม่หยาบควรอยู่ในรหัส
3. ผู้ใช้ควรรับผิดชอบต่อไฟล์ config และโปรแกรมเมอร์ควรรับผิดชอบเลเยอร์คอนฟิกูเรชันระหว่างไฟล์ config และโค้ดที่ให้การควบคุมแอพพลิเคชั่นอย่างละเอียดมากขึ้น
4. ไม่ แต่ชั้นกลางที่ละเอียดกว่านั้นควรเป็น

คำถามที่น่าสนใจมาก!

ฉันมักจะ จำกัด ไฟล์กำหนดค่าของฉันให้อยู่ในรูปแบบ "key = value" ที่เรียบง่ายมากเพราะฉันเห็นด้วยกับคุณอย่างเต็มที่ว่าไฟล์ config สามารถกลายเป็นโปรแกรมที่สมบูรณ์ได้อย่างรวดเร็ว ตัวอย่างเช่นใครก็ตามที่เคยพยายาม "กำหนดค่า" OpenSER จะรู้ดีถึงความรู้สึกที่คุณกำลังพูดถึงนั่นไม่ใช่การกำหนดค่า แต่เป็นการเขียนโปรแกรม (ที่เจ็บปวด)

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

ดังนั้นเพื่อตอบคำถามของคุณ:

1. วัตถุประสงค์ที่แท้จริงของไฟล์กำหนดค่าคืออะไร?

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

2. ควรพยายามทำให้ไฟล์ config เป็นเรื่องง่ายหรือไม่?

   อย่างแน่นอน. ตามที่คุณแนะนำ "การเขียนโปรแกรม" ในไฟล์กำหนดค่านั้นแย่มาก ฉันเชื่อว่าควรหลีกเลี่ยง

3. ใครควรรับผิดชอบในการเปลี่ยนแปลงสิ่งเหล่านี้ (นักพัฒนาผู้ใช้ผู้ดูแลระบบ ฯลฯ )

   โดยทั่วไปฉันจะบอกว่าผู้ดูแลระบบที่ปรับใช้แอปพลิเคชัน

4. ควรได้รับการควบคุมแหล่งที่มา (ดูคำถาม 3)?

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

แก้ไข: แม้ว่าฉันเชื่อว่าข้างต้นเป็นจริงสำหรับแอปพลิเคชันส่วนใหญ่ แต่ก็มีข้อยกเว้นอยู่เสมอ แอปพลิเคชันของคุณอาจอนุญาตให้ผู้ใช้กำหนดค่ากฎที่ซับซ้อนได้แบบไดนามิก โปรแกรมรับส่งเมลส่วนใหญ่อนุญาตให้ผู้ใช้กำหนดกฎสำหรับการจัดการอีเมลของตน (ตัวอย่างเช่น "อีเมลทั้งหมดที่มาจาก" john doe "และไม่มีฉันในช่องถึง: ควรทิ้ง") อีกตัวอย่างหนึ่งคือแอปพลิเคชันที่อนุญาตให้ผู้ใช้กำหนดข้อเสนอเชิงพาณิชย์ที่ซับซ้อนใหม่ คุณอาจคิดถึงแอ็พพลิเคชันเช่น Cognos ซึ่งอนุญาตให้ผู้ใช้สร้างรายงานฐานข้อมูลที่ซับซ้อน ไคลเอนต์อีเมลอาจเสนออินเทอร์เฟซที่เรียบง่ายให้กับผู้ใช้เพื่อกำหนดกฎและสิ่งนี้จะสร้างไฟล์การกำหนดค่าที่ซับซ้อน (หรืออาจเป็นโค้ดเล็กน้อย) ในทางกลับกัน, การกำหนดค่าที่ผู้ใช้กำหนดเองสำหรับข้อเสนอเชิงพาณิชย์อาจถูกบันทึกไว้ในฐานข้อมูลในลักษณะที่มีโครงสร้าง (ไม่ใช่โครงสร้างคีย์ = ค่าแบบธรรมดาหรือส่วนของโค้ด) และแอปพลิเคชั่นอื่น ๆ บางตัวอาจอนุญาตให้ผู้ใช้เขียนโค้ดใน python หรือ VB หรือภาษาที่รองรับระบบอัตโนมัติอื่น ๆ กล่าวอีกนัยหนึ่ง ... ระยะทางของคุณอาจแตกต่างกันไป

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

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

คุณจะทราบว่าส่วนใหญ่เป็นคำสั่ง key = value โดยที่ค่าสามารถเป็นประเภทบิวท์อินของ Lua ได้ สิ่งที่ซับซ้อนที่สุดคือรายการและไม่ซับซ้อนจริงๆ (เป็นเพียงเรื่องของไวยากรณ์)

ตอนนี้ฉันแค่รอให้ใครบางคนถามถึงวิธีตั้งค่าพอร์ตของเซิร์ฟเวอร์เป็นค่าสุ่มทุกครั้งที่เริ่มต้น ...

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

key = val
key2 = val
name = `hostname`

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

แต่ฉันตัดสินใจว่าฉันมีสองรูปแบบ:

1. หากไฟล์ขึ้นต้นด้วย "#!" และสามารถเรียกใช้งานได้ฉันจะแยกวิเคราะห์ผลลัพธ์ของการเรียกใช้

2. มิฉะนั้นฉันจะอ่านมันตามที่เป็นอยู่

ซึ่งหมายความว่าตอนนี้ฉันสามารถอนุญาตให้คนอื่นเขียน "ไฟล์คอนฟิกูเรชัน" ที่มีลักษณะดังนี้:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

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

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

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

ฉันใช้ไฟล์กำหนดค่าเพื่อชี้ไปที่ที่เก็บข้อมูลเท่านั้น

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

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

นี่คือความคิดของฉัน:

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

2. ใช่. ฉันคิดว่าไฟล์ config ควรเรียบง่ายที่สุดเนื่องจากมีข้อ จำกัด ว่าคุณอาจต้องใช้ตัวเลือกต่างๆเพื่อควบคุมพฤติกรรมต่างๆของรันไทม์ของคุณ ฉันชอบจัดกลุ่มการตั้งค่าคอนฟิกและลดความซับซ้อนให้มากที่สุด

3. ขึ้นอยู่กับว่ามีการเปลี่ยนแปลงอะไรและทำไม หากผู้ใช้กำลังจะเปลี่ยนมันควรทำส่วนหน้าเพื่อซ่อนพวกเขาจากรายละเอียด สิ่งเดียวกันนี้มักเกิดขึ้นกับผู้ที่ไม่ใช่นักพัฒนาโดยทั่วไป

4. ฉันมักจะซอร์สควบคุมการกำหนดค่า "ค่าเริ่มต้น" แต่มีวิธีที่จะแทนที่สิ่งนี้ต่อระบบสำหรับรันไทม์จริง

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

ฉันมักจะเห็นด้วยกับหลักฐานของคำถามนี้ ฉันหลีกเลี่ยงไม่ให้ตัวเองมีปัญหาโดยการคาดการณ์ล่วงหน้าว่าสิ่งนี้จะเกิดขึ้นดังนั้นจึงไม่เคยม้วนระบบกำหนดค่าของฉันเอง

• ไม่ว่าฉันจะใช้ความสามารถในการกำหนดค่าของระบบปฏิบัติการ (เช่น plist หรือ gconf หรืออะไรก็ตามที่เหมาะสม)
• หรือไฟล์แบนธรรมดาที่สามารถจัดการได้เช่นตัวแยกวิเคราะห์ INI นอกชั้นวาง
• กัดสัญลักษณ์แสดงหัวข้อย่อยและเสียบตัวแยกวิเคราะห์ภาษาที่มีน้ำหนักเบาโดยปกติคือ lua บางครั้ง tcl ในแอปพลิเคชัน
• หรือจัดเก็บข้อมูลใน SQLite หรือฐานข้อมูลเชิงสัมพันธ์ที่คล้ายกัน

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

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

ขึ้นอยู่กับสิ่งที่คุณเห็นด้วยกับนักพัฒนาคนอื่น ๆ ในทีม คุณใช้ไฟล์กำหนดค่าเหมือนกับไฟล์กำหนดค่าหรือคุณกำลังสร้างแอปพลิเคชันModel Driven

อาการของไฟล์กำหนดค่ากลายเป็นภาษาโปรแกรม:

• ชื่อ = คู่ค่าเริ่มขึ้นอยู่กับกันและกัน
• คุณรู้สึกว่าจำเป็นต้องมีการควบคุมการไหล (เช่นถ้า (นี้) มากกว่านั้น )
• เอกสารสำหรับไฟล์ config มีความสำคัญในการพัฒนาต่อไป (แทนที่จะใช้แค่แอพพลิเคชั่น)
• ก่อนที่จะอ่านค่าจาก config จำเป็นต้องมีบริบทบางอย่าง (เช่นค่าขึ้นอยู่กับสิ่งภายนอกของไฟล์ config เอง)

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

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

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

นี่คือคำตอบของฉันสำหรับคำถามของคุณ:

• วัตถุประสงค์ที่แท้จริงของไฟล์กำหนดค่าคืออะไร?

ไฟล์กำหนดค่าเป็นวิธีการอนุญาตให้ผู้ใช้ปรับแต่งลักษณะการทำงานของโปรแกรมในขณะทำงาน

• ควรพยายามทำให้ไฟล์ config เป็นเรื่องง่ายหรือไม่?

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

• ใครควรรับผิดชอบในการเปลี่ยนแปลงสิ่งเหล่านี้ (นักพัฒนาผู้ใช้ผู้ดูแลระบบ ฯลฯ )

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

• ควรได้รับการควบคุมแหล่งที่มา (ดูคำถาม 3)?

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

ฉันเคยเห็นโปรแกรม python ที่ไฟล์ config เป็นรหัส หากคุณไม่จำเป็นต้องทำอะไรเป็นพิเศษ (เงื่อนไข ฯลฯ ) มันดูไม่แตกต่างจากรูปแบบการกำหนดค่าอื่น ๆ มากนัก เช่นฉันสามารถสร้างไฟล์config.pyด้วยสิ่งต่างๆเช่น:

num_threads = 13
hostname = 'myhost'

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

ใช่ไฟล์ config ควรเรียบง่าย พวกเขาไม่ควรมี 'ตรรกะ' ด้วยตัวเอง - คิดว่ามันเป็นรายการของนิพจน์ในคำสั่ง if ไม่ใช่คำสั่งเงื่อนไขอย่างครบถ้วน

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

จุดประสงค์ประการหนึ่งของงาน "ออสโล" ที่ Microsoft คือการอนุญาต (แม้ว่าจะไม่ต้องการ) การแก้ไขปัญหานี้

1. แอปพลิเคชันจะมาพร้อมกับโมเดลของส่วนประกอบใหม่ ๆ ที่มีอยู่ นอกจากนี้ยังใช้โมเดลที่มีอยู่ ตัวอย่างเช่นอาจรวมถึงบริการบนเว็บดังนั้นจึงสามารถนำรูปแบบระบบของบริการเว็บกลับมาใช้ใหม่ได้
2. โมเดลจะมีข้อมูลเมตาที่อธิบายถึงข้อมูลเหล่านี้รวมถึงข้อมูลที่เพียงพอสำหรับเครื่องมือในการเข้าถึงไม่ว่าจะเป็นข้อความหรือกราฟิก
3. บางส่วนของโมเดลจะสอดคล้องกับ "การกำหนดค่า"

ซึ่งหมายความว่าไฟล์คอนฟิกูเรชันที่เทียบเท่ากันในปัจจุบันอาจมีมากพอที่จะรองรับทั้งการแก้ไขข้อความและกราฟิกของการกำหนดค่า เครื่องมือกราฟิกจะมาพร้อมกับ "Oslo" (ชื่อรหัส "Quadrant")

ฉันจะเป็นผู้ฝ่าฝืนและส่งมันเป็นเพียงภาษาเมื่อมันรวบรวมได้มากกว่าที่ XML สามารถแสดงได้ หรืออื่น ๆ เมื่อ XML ถูกพิจารณาว่าเป็นภาษา

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

ท้ายที่สุดแล้ว "ภาษา" เป็นนามธรรมที่เรียบง่าย แต่ใช่ขอบจะคลุมเครือ

รหัสของแอปพลิเคชันของเรามีความสำคัญน้อยลง ... มีการเขียนสคริปต์มีแอตทริบิวต์ทุกประเภทที่กำหนดลักษณะการทำงานของคลาสวิธีการอาร์กิวเมนต์เมธอดและคุณสมบัติ ผู้ใช้สามารถกำหนดทริกเกอร์ฐานข้อมูลและข้อ จำกัด ของฐานข้อมูล อาจมีไฟล์กำหนดค่าที่ซับซ้อนมาก บางครั้งผู้ใช้สามารถกำหนด XSLT stylsheets เพื่อจัดการอินพุตและเอาต์พุตเนื่องจากระบบของเราจำเป็นต้องเปิด (SOA) และยังมีสิ่งต่างๆเช่น BizzTalk ที่ต้องการการกำหนดค่าที่ซับซ้อนด้วย ผู้ใช้สามารถกำหนดขั้นตอนการทำงานที่ซับซ้อน

เราต้องเขียนโค้ดให้ดีขึ้นเพื่อจัดการกับสภาพแวดล้อมที่ซับซ้อนนี้โค้ดของแอปพลิเคชันของเราจึงมีความสำคัญมากขึ้น ...

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

ไฟล์กำหนดค่า : "จุดประสงค์ของฉันคืออะไร"
คุณ : "กำหนดค่าเนย"
ไฟล์กำหนดค่า : "ตกลง ... "
ไฟล์กำหนดค่า : "จุดประสงค์ของฉันคืออะไร"
คุณ : "คุณกำหนดค่าเนย"
ไฟล์กำหนดค่า : "พระเจ้าช่วย"

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

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

3. อีกครั้งผู้ที่ควรแก้ไขไฟล์ config นั้นขึ้นอยู่กับแอปพลิเคชัน แต่ฉันเห็นด้วยกับ miniquark ใครก็ตามที่ปรับใช้แอปพลิเคชันควรเป็นผู้รับผิดชอบในการกำหนดค่า

4. แหล่งที่มาควบคุมทุกสิ่งที่คุณทำได้ การควบคุมแหล่งที่มานั้นยอดเยี่ยม คุณสามารถย้อนสิ่งต่างๆกลับมาได้อย่างง่ายดายและมีประวัติทั้งหมดของการเปลี่ยนแปลงที่คุณทำและบันทึกว่าใครเป็นผู้ทำการเปลี่ยนแปลงเหล่านั้น แล้วทำไมล่ะ?