Tập tin cấu hình trở thành một ngôn ngữ lập trình ở điểm nào?

Question 1

Tôi đã nghiền ngẫm các tệp cấu hình và mối quan hệ của chúng với mã trong một thời gian và tùy thuộc vào ngày và hướng gió, ý kiến của tôi dường như thay đổi. Ngày càng nhiều mặc dù tôi tiếp tục quay lại nhận thức lần đầu tiên tôi có được khi học Lisp: có rất ít sự khác biệt giữa dữ liệu và mã. Điều này có vẻ đúng gấp đôi đối với các tệp cấu hình. Khi nhìn đúng chỗ, một tập lệnh Perl không hơn một tập tin cấu hình cho perl. Điều này có xu hướng gây ra hậu quả khá nặng nề đối với các tác vụ như QA và phân công lao động như ai phải chịu trách nhiệm thay đổi các tệp cấu hình.

Quá trình chuyển từ tệp cấu hình sang ngôn ngữ chính thức thường chậm và dường như được thúc đẩy bởi mong muốn có một hệ thống chung. Hầu hết các dự án dường như bắt đầu nhỏ với một số mục cấu hình như nơi ghi nhật ký, nơi tìm dữ liệu, tên người dùng và mật khẩu, v.v. Nhưng sau đó chúng bắt đầu phát triển: các tính năng bắt đầu có thể được bật hoặc tắt, thời gian và thứ tự của các hoạt động bắt đầu được kiểm soát, và chắc chắn ai đó muốn bắt đầu thêm logic vào nó (ví dụ: sử dụng 10 nếu máy là X và 15 nếu máy là Y). Tại một thời điểm nào đó, tệp cấu hình trở thành một ngôn ngữ cụ thể của miền và ở đó được viết kém.

Bây giờ tôi đã lan man về việc thiết lập sân khấu, đây là những câu hỏi của tôi:

Mục đích thực sự của tệp cấu hình là gì?
Có nên cố gắng giữ cho các tệp cấu hình đơn giản không?
Ai phải chịu trách nhiệm thực hiện các thay đổi đối với chúng (nhà phát triển, người dùng, quản trị viên, v.v.)?
Chúng có nên được kiểm soát nguồn (xem câu hỏi 3)?

Như tôi đã nói trước đó, câu trả lời của tôi cho những câu hỏi này thay đổi liên tục, nhưng ngay bây giờ tôi đang nghĩ:

để cho phép những người không phải là lập trình viên thay đổi các hành vi lớn một cách nhanh chóng
vâng, bất cứ thứ gì không được tạo chi tiết thô đều phải ở dạng mã
người dùng phải chịu trách nhiệm về các tệp cấu hình và người lập trình phải chịu trách nhiệm về lớp cấu hình giữa tệp cấu hình và mã để cung cấp khả năng kiểm soát chi tiết hơn đối với ứng dụng
không, nhưng lớp giữa có hạt mịn hơn sẽ

Question 2

Câu hỏi rất thú vị!

Tôi có xu hướng giới hạn các tệp cấu hình của mình ở định dạng "key = value" rất đơn giản, bởi vì tôi hoàn toàn đồng ý với bạn rằng các tệp cấu hình có thể rất nhanh chóng trở thành chương trình hoàn chỉnh. Ví dụ, bất kỳ ai đã từng cố gắng "cấu hình" OpenSER đều biết cảm giác mà bạn đang nói đến: đó không phải là cấu hình, mà là lập trình (đau đớn).

Khi bạn cần ứng dụng của mình có cấu hình rất "khủng" theo những cách mà bạn không thể tưởng tượng được ngày nay, thì thứ bạn thực sự cần là một hệ thống plugin . Bạn cần phát triển ứng dụng của mình theo cách mà người khác có thể viết mã một plugin mới và kết nối nó vào ứng dụng của bạn trong tương lai.

Vì vậy, để trả lời câu hỏi của bạn:

Mục đích thực sự của tệp cấu hình là gì?

Tôi muốn nói rằng, để cho phép những người sẽ cài đặt ứng dụng của bạn có thể kiểm tra một số thông số liên quan đến triển khai, chẳng hạn như tên máy chủ, số luồng, tên của các plugin bạn cần và các tham số triển khai cho các plugin đó (kiểm tra ra cấu hình của FreeRadius cho một ví dụ về nguyên tắc này), v.v. Chắc chắn không phải là nơi để thể hiện logic nghiệp vụ.
Có nên cố gắng giữ cho các tệp cấu hình đơn giản không?

Chắc chắn. Như bạn đã đề xuất, "lập trình" trong một tệp cấu hình là rất kinh khủng. Tôi tin rằng nó nên được tránh.
Ai phải chịu trách nhiệm thực hiện các thay đổi đối với chúng (nhà phát triển, người dùng, quản trị viên, v.v.)?

Nói chung, tôi sẽ nói là quản trị viên, người triển khai ứng dụng.
Chúng có nên được kiểm soát nguồn (xem câu hỏi 3)?

Tôi thường không kiểm soát nguồn các tập tin cấu hình bản thân, nhưng tôi làm nguồn điều khiển một tập tin cấu hình mẫu, với tất cả các thông số và các giá trị mặc định của họ, và ý kiến mô tả những gì họ làm. Ví dụ, nếu một tệp cấu hình được đặt tên database.conf, tôi thường kiểm soát nguồn của một tệp có tên database.conf.template. Tất nhiên bây giờ tôi đang nói về những gì tôi làm với tư cách là một nhà phát triển . Với tư cách là quản trị viên , tôi có thể muốn kiểm soát nguồn cài đặt thực tế mà tôi đã chọn cho mỗi lần cài đặt. Ví dụ: chúng tôi quản lý một vài trăm máy chủ từ xa và chúng tôi cần theo dõi cấu hình của chúng: chúng tôi đã chọn làm điều này với kiểm soát nguồn.

Biên tập: Mặc dù tôi tin rằng những điều trên là đúng với hầu hết các ứng dụng, tất nhiên luôn có những ngoại lệ. Ví dụ: ứng dụng của bạn có thể cho phép người dùng định cấu hình động các quy tắc phức tạp. Hầu hết các ứng dụng email cho phép người dùng xác định các quy tắc quản lý email của họ (ví dụ: "tất cả các email đến từ 'john doe' và không có tôi trong trường Tới: nên bị loại bỏ"). Một ví dụ khác là một ứng dụng cho phép người dùng xác định một đề nghị thương mại phức tạp mới. Bạn cũng có thể nghĩ về các ứng dụng như Cognos cho phép người dùng của họ xây dựng các báo cáo cơ sở dữ liệu phức tạp. Ứng dụng email khách có thể sẽ cung cấp cho người dùng một giao diện đơn giản để xác định các quy tắc và điều này sẽ tạo ra một tệp cấu hình phức tạp (hoặc thậm chí có thể là một chút mã). Mặt khác, cấu hình do người dùng xác định cho các ưu đãi thương mại có thể được lưu trong cơ sở dữ liệu, theo cách có cấu trúc (không phải là cấu trúc key = value đơn giản cũng không phải là một phần của mã). Và một số ứng dụng khác thậm chí có thể cho phép người dùng viết mã bằng python hoặc VB hoặc một số ngôn ngữ có khả năng tự động hóa khác. Nói cách khác ... số dặm của bạn có thể thay đổi.

Question 3

Đồng ý. Bạn sẽ có một số người dùng muốn cấu hình thực sự đơn giản, bạn nên cung cấp cho họ. Đồng thời, bạn sẽ có các yêu cầu liên tục "Bạn có thể thêm cái này không? Làm thế nào để làm trong tệp cấu hình?", Tôi không hiểu tại sao bạn không thể hỗ trợ cả hai nhóm.

Dự án tôi hiện đang thực hiện sử dụng Lua cho tệp cấu hình của nó. Lua là một ngôn ngữ kịch bản, và nó hoạt động khá tốt trong kịch bản này. Có sẵn một ví dụ về cấu hình mặc định của chúng tôi .

Bạn sẽ lưu ý rằng nó chủ yếu là các câu lệnh key = value, trong đó giá trị có thể là bất kỳ kiểu tích hợp nào của Lua. Điều phức tạp nhất là danh sách và chúng không thực sự phức tạp (đó chỉ là vấn đề về cú pháp).

Bây giờ tôi chỉ đang chờ ai đó hỏi cách đặt cổng máy chủ của họ thành một giá trị ngẫu nhiên mỗi khi họ khởi động nó ...

Question 4

Gần đây, tôi đang làm việc trên một dự án và tôi nhận ra rằng tôi muốn có các điều kiện bên trong tệp cấu hình của mình - trước đây chỉ là một điều kiện khá đơn giản có dạng:


key = val
key2 = val
name = `hostname`

Tôi không muốn viết một ngôn ngữ nhỏ, bởi vì trừ khi tôi làm điều đó rất cẩn thận, tôi không thể cho phép sự linh hoạt có ích.

Thay vào đó, tôi quyết định rằng tôi sẽ có hai hình thức:

Nếu tệp bắt đầu bằng "#!" và có thể thực thi được. Tôi sẽ phân tích cú pháp kết quả của việc chạy nó.
Nếu không, tôi sẽ đọc nó như hiện tại

Điều này có nghĩa là bây giờ tôi có thể cho phép mọi người viết "tệp cấu hình" trông giống như sau:

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

Bằng cách này, tôi có được sức mạnh của tệp cấu hình động nếu người dùng muốn sử dụng nó và sự đơn giản của việc không phải viết ngôn ngữ nhỏ của riêng tôi.

Question 5

Mọi lược đồ tệp cấu hình (đủ lâu) cuối cùng sẽ trở thành một ngôn ngữ lập trình. Do tất cả các hàm ý bạn mô tả, khôn ngoan là người thiết kế tệp cấu hình nhận ra rằng cô ấy đang là tác giả của một ngôn ngữ lập trình và lập kế hoạch cho phù hợp, vì cô ấy sẽ tạo gánh nặng cho người dùng trong tương lai với di sản xấu.

Question 6

Tôi có một triết lý khác về các tệp cấu hình. Dữ liệu về cách một ứng dụng sẽ được chạy vẫn là dữ liệu và do đó thuộc về một kho lưu trữ dữ liệu, không phải trong mã (tệp cấu hình IMO là mã). Nếu người dùng cuối cần có thể thay đổi dữ liệu, thì ứng dụng phải cung cấp một giao diện để thực hiện việc đó.

Tôi chỉ sử dụng các tệp cấu hình để trỏ đến các cửa hàng dữ liệu.

Question 7

Bạn có thể chuyển sang lý thuyết tính toán để xác định những gì được coi là ngôn ngữ lập trình. Nếu định dạng tệp cấu hình của bạn là Turing Complete thì nó được coi là một ngôn ngữ lập trình. Theo định nghĩa này, định dạng tệp để mô tả các cấp độ của Sokoban được coi là ngôn ngữ lập trình (xem tại đây ). Có những mức độ phức tạp khác bên dưới Turing Complete cũng có thể được tính, chẳng hạn như Ngữ pháp thông thường và Dữ liệu tự động đẩy xuống .

Một cách khác để xem xét nó là nhiều tệp cấu hình chỉ có khả năng đánh dấu dữ liệu, trong khi một ngôn ngữ lập trình thích hợp phải có khả năng triển khai các thuật toán . Ví dụ: JSON là một định dạng tệp cấu hình, trong khi ECMA Script là một ngôn ngữ lập trình.

Question 8

Đây là suy nghĩ của tôi:

Để cho phép dễ dàng sửa đổi hành vi thời gian chạy của ứng dụng. Điều này có thể do lập trình viên hoặc không lập trình viên, tùy thuộc vào nhu cầu. Điều này có thể xảy ra trong quá trình phát triển, nhưng tôi thường xem các tệp cấu hình như một cách để giúp chương trình linh hoạt hơn tại bất kỳ thời điểm nào.
Đúng. Tôi nghĩ rằng các tệp cấu hình nên càng đơn giản càng tốt, với điều kiện ràng buộc là bạn có thể cần nhiều tùy chọn khác nhau để kiểm soát các hành vi khác nhau trong thời gian chạy của mình. Tôi thích nhóm các cài đặt cấu hình và đơn giản hóa chúng nhiều nhất có thể.
Phụ thuộc vào cái gì và tại sao thay đổi được thực hiện. Nếu người dùng định thay đổi nó, nên tạo giao diện người dùng để ẩn họ khỏi các chi tiết. Điều này thường đúng với những người không phải là nhà phát triển nói chung.
Tôi thường kiểm soát nguồn cấu hình "mặc định", nhưng có một cách để ghi đè cấu hình này cho mỗi hệ thống trong thời gian chạy thực tế.

Đối với việc thêm logic vào tệp cấu hình - tôi sẽ tránh điều này. Tôi nghĩ tốt hơn là chỉ cần bật tính năng logic của tệp cấu hình trong ứng dụng của bạn. Theo kinh nghiệm của tôi, hành vi trong các tệp cấu hình dẫn đến thiếu khả năng bảo trì và hiểu biết. Tôi thực sự thích giữ các tệp cấu hình càng đơn giản càng tốt.

Question 9

Tôi có xu hướng đồng ý với tiền đề của câu hỏi này. Tôi tránh để mình gặp rắc rối bằng cách dự đoán sớm rằng điều này sẽ xảy ra, và do đó không bao giờ tung ra hệ thống cấu hình của riêng tôi.

Tôi sử dụng tính năng cấu hình của hệ điều hành (chẳng hạn như plist, hoặc gconf hoặc bất cứ thứ gì thích hợp),
Hoặc một tệp phẳng đơn giản, có thể được xử lý bằng một thứ gì đó như trình phân tích cú pháp INI ngoài giá đỡ.
Cắn dấu đầu dòng và cắm một trình phân tích cú pháp ngôn ngữ trọng lượng nhẹ, thường là lua, đôi khi tcl vào ứng dụng,
Hoặc lưu trữ dữ liệu trong SQLite hoặc cơ sở dữ liệu quan hệ tương tự.

Và từ chức để sống với bất kỳ quyết định nào mà tôi đã đưa ra, hoặc nếu tôi không thể, hãy cấu trúc lại để sử dụng một trong những lựa chọn trên phù hợp hơn với ứng dụng.

Vấn đề là, thực sự không có bất kỳ lý do gì để sử dụng giải pháp cấu hình tự phát triển. Đối với một điều, người dùng của bạn sẽ khó hơn khi phải tìm hiểu một định dạng cấu hình mới, dành riêng cho ứng dụng. Mặt khác, Bạn được hưởng lợi từ nhiều bản sửa lỗi và cập nhật miễn phí khi sử dụng giải pháp bán sẵn. Cuối cùng, tính năng creep đã được tạm dừng, bởi vì, bạn thực sự không thể chỉ thêm một tính năng nữa mà không thực sự thực hiện một cuộc đại tu lớn vì hệ thống cấu hình không thực sự nằm trong tay bạn ngay từ đầu.

Question 10

Nó phụ thuộc vào những gì bạn đồng ý với các nhà phát triển khác trong nhóm. Bạn có đang sử dụng các tệp cấu hình giống như tệp cấu hình hay bạn đang tạo Hướng dẫn mô hình ứng dụng .

Các hiện tượng khi tệp cấu hình trở thành ngôn ngữ lập trình:

các cặp tên = giá trị bắt đầu phụ thuộc vào nhau
bạn cảm thấy cần phải kiểm soát luồng (ví dụ: nếu (cái này) hơn thế )
tài liệu cho tệp cấu hình trở nên cần thiết để phát triển thêm (thay vì chỉ sử dụng ứng dụng)
trước khi giá trị từ cấu hình được đọc, nó yêu cầu phải có một số ngữ cảnh (nghĩa là các giá trị phụ thuộc vào thứ gì đó bên ngoài để cấu hình tệp chính nó)

Question 11

Các tệp cấu hình luôn nhích dần từng bước để trở thành "ngôn ngữ lập trình chính thức" xấu xí, phi logic. Cần có nghệ thuật và kỹ năng để thiết kế ngôn ngữ lập trình tốt, và ngôn ngữ cấu hình biến ngôn ngữ lập trình có xu hướng trở nên khủng khiếp.

Một cách tiếp cận tốt là sử dụng một ngôn ngữ được thiết kế độc đáo, chẳng hạn như python hoặc ruby và sử dụng nó để tạo DSL cho cấu hình của bạn. Bằng cách đó, ngôn ngữ cấu hình của bạn có thể vẫn đơn giản trên bề mặt nhưng thực sự là ngôn ngữ lập trình chính thức.

Question 12

Tôi tin rằng câu hỏi của bạn rất phù hợp với việc chuyển sang "giao diện thông thạo". Nhiều nhà phát triển đã "nhìn thấy ánh sáng" đối với các ứng dụng được cấu hình XML. Sử dụng XML có thể rất dài dòng và khó chỉnh sửa chính xác (đặc biệt nếu không có lược đồ nào được cung cấp). Có giao diện thông thạo cho phép nhà phát triển định cấu hình ứng dụng bằng ngôn ngữ dành riêng cho miền với sự hỗ trợ của một số cặp khóa-giá trị từ tệp cấu hình văn bản thuần túy (hoặc có thể là tham số dòng lệnh). Nó cũng giúp bạn dễ dàng thiết lập và định cấu hình các phiên bản mới của ứng dụng để thử nghiệm hoặc bất cứ điều gì.

Đây là câu trả lời của tôi cho câu hỏi của bạn:

Mục đích thực sự của tệp cấu hình là gì?

Tệp cấu hình là một cách cho phép người dùng tùy chỉnh hành vi của chương trình của họ tại thời điểm chạy.

Có nên cố gắng giữ cho các tệp cấu hình đơn giản không?

Lý tưởng nhất, tôi nghĩ rằng các tệp cấu hình ít nhất nên được bổ sung bởi một giao diện thông thạo để cấu hình chương trình (điều này hữu ích ở nhiều khía cạnh). Nếu bạn yêu cầu một tệp cấu hình thì nó phải được giữ rất đơn giản, không có gì khác ngoài các cặp khóa-giá trị.

Ai phải chịu trách nhiệm thực hiện các thay đổi đối với chúng (nhà phát triển, người dùng, quản trị viên, v.v.)?

Tôi nghĩ câu trả lời cho điều này phụ thuộc vào tổ chức của bạn. Người triển khai phần mềm phải có trách nhiệm đảm bảo rằng nó được cấu hình đúng.

Chúng có nên được kiểm soát nguồn (xem câu hỏi 3)?

Tôi sẽ đánh cắp câu trả lời này từ người khác :) Tôi thích ý tưởng lưu trữ cấu hình mẫu trong kiểm soát nguồn và sửa đổi nó theo nhu cầu của từng người dùng cục bộ. Rất có thể tệp cấu hình của một nhà phát triển này là cơn ác mộng của nhà phát triển khác, vì vậy tốt nhất nên để những thứ khác nhau tùy theo người dùng ngoài quyền kiểm soát nguồn. Có một mẫu cũng là một cách hay để cho phép người triển khai ứng dụng (hoặc các nhà phát triển khác) thấy chính xác những giá trị nào hợp lệ cho tệp cấu hình.

Question 13

Tôi đã thấy các chương trình python trong đó tệp cấu hình là mã. Nếu bạn không cần làm bất cứ điều gì đặc biệt (điều kiện, v.v.), nó trông không khác nhiều so với các kiểu cấu hình khác. Ví dụ: tôi có thể tạo một tệp config.pyvới những thứ như:

num_threads = 13
hostname = 'myhost'

và gánh nặng duy nhất đối với người dùng, so với (giả sử) các tệp INI, là họ cần đặt '' xung quanh các chuỗi. Không nghi ngờ gì nữa, bạn có thể làm điều tương tự bằng các ngôn ngữ thông dịch khác. Nó cung cấp cho bạn khả năng không giới hạn để làm phức tạp tệp cấu hình của bạn nếu cần, với nguy cơ có thể khiến người dùng của bạn sợ hãi.

Question 14

Có, các tệp cấu hình phải đơn giản. Bản thân chúng không được chứa 'logic' - hãy nghĩ về chúng như một danh sách các biểu thức trong câu lệnh if, không phải toàn bộ câu lệnh điều kiện.

Chúng ở đó để cho phép người dùng quyết định nên sử dụng các tùy chọn nào được mã hóa trong ứng dụng, vì vậy đừng cố làm cho chúng phức tạp, nó sẽ tự đánh bại - bạn có thể phải viết các tệp cấu hình đơn giản để kiểm soát cách định cấu hình tệp cấu hình gốc!

Question 15

Một trong những mục đích của công việc "Oslo" tại Microsoft là cho phép (mặc dù không yêu cầu) giải quyết vấn đề này.

Một ứng dụng sẽ xuất xưởng với các mô hình của bất kỳ thành phần mới nào mà nó bao gồm. Nó cũng sẽ sử dụng các mô hình hiện có. Ví dụ, nó có thể bao gồm một dịch vụ web, vì vậy nó có thể sử dụng lại mô hình hệ thống của một dịch vụ web.
Các mô hình sẽ bao gồm siêu dữ liệu mô tả chúng, bao gồm đủ thông tin để các công cụ truy cập chúng, bằng văn bản hoặc đồ họa.
Các phần của mô hình sẽ tương ứng với "cấu hình"

Điều này có nghĩa là các tệp cấu hình tương đương ngày nay có thể đủ phong phú để hỗ trợ cả chỉnh sửa văn bản và đồ họa cấu hình của chúng. Công cụ đồ họa sẽ được cung cấp với "Oslo" (tên mã "Quadrant").

Question 16

Tôi sẽ là người phản đối và gửi nó chỉ là một ngôn ngữ khi nó thể hiện nhiều hơn những gì có thể được biểu diễn bằng XML; hoặc khác khi XML được coi là một ngôn ngữ.

Ngoài ra, hầu hết các tệp cấu hình có thể được coi là các lớp, nhưng chỉ có thuộc tính và không có phương thức. Và nếu không có phương pháp, tôi không nghĩ đó là một ngôn ngữ.

Cuối cùng, "ngôn ngữ" là một sự trừu tượng ngắn gọn, nhưng có, các cạnh là mơ hồ.

Question 17

Mã của các ứng dụng của chúng ta trở nên ít quan trọng hơn ... Có tập lệnh, có tất cả các loại thuộc tính xác định hành vi của các lớp, phương thức, đối số phương thức và thuộc tính. Người dùng có thể xác định các trình kích hoạt cơ sở dữ liệu và các ràng buộc cơ sở dữ liệu. Có thể có các tệp cấu hình rất phức tạp. Đôi khi người dùng có thể xác định các biểu mẫu XSLT để thao tác đầu vào và đầu ra vì hệ thống của chúng tôi cần phải mở (SOA). Và có những thứ như BizzTalk cũng cần cấu hình phức tạp. Người dùng có thể xác định quy trình làm việc phức tạp.

Chúng tôi phải viết mã tốt hơn để đối phó với môi trường phức tạp này, vì vậy mã của các ứng dụng của chúng tôi trở nên quan trọng hơn ...

Question 18

Tôi rất thích sử dụng các chương trình python làm tệp cấu hình, đặc biệt là cho daemon. Tôi muốn làm cho daemon hoàn toàn trống cấu hình ngoại trừ "cổng cấu hình". Sau đó, chương trình python kết nối với daemon và tiến hành tạo các đối tượng trong daemon và kết nối chúng lại với nhau để tạo ra cấu hình mong muốn. Khi mọi thứ được thiết lập, daemon có thể được để lại để tự chạy. Tất nhiên, lợi ích là bạn có được một ngôn ngữ lập trình chính thức đầy đủ để viết các tệp cấu hình của mình và vì bạn đã có cách để nói chuyện với daemon từ một chương trình khác, bạn có thể sử dụng nó để gỡ lỗi và lấy số liệu thống kê. Nhược điểm lớn là phải đối phó với các tin nhắn từ một chương trình khác đến bất cứ lúc nào.

Question 19

Tệp cấu hình : "Mục đích của tôi là gì?"
Bạn : "Cấu hình bơ."
Tệp cấu hình : "Ok ..."
Tệp cấu hình : "Mục đích của tôi là gì?"
Bạn : "Bạn cấu hình bơ."
File cấu hình : "Ôi trời ơi."

Không có "mục đích thực sự" của tệp cấu hình. Bất cứ điều gì có ý nghĩa đối với ứng dụng của bạn. Nói chung, những thứ khác nhau (hoặc có thể khác nhau) giữa các máy và không thay đổi giữa quá trình chạy ứng dụng của bạn có thể nằm trong một tệp cấu hình. Mặc định, cổng và địa chỉ cho các dịch vụ khác đều là những ứng cử viên sáng giá. Khóa và bí mật cũng là những ứng cử viên tuyệt vời nhưng nên được xử lý riêng biệt với cấu hình thông thường của bạn vì lý do bảo mật. Tôi không đồng ý rằng mục đích của tệp cấu hình là cho phép thực hiện các thay đổi nhanh chóng. Mục đích là để cho phép sự linh hoạt trong việc thiết lập ứng dụng của bạn. Nếu một tệp cấu hình là một cách nhanh chóng để cho phép sự linh hoạt đó thì càng tốt - nhưng bạn không nên có ý định các tệp cấu hình của mình thường xuyên thay đổi.
Có và không. Bạn có nên cố gắng làm cho mã ứng dụng của mình đơn giản không? Đúng. Bạn nên cố gắng làm cho mọi thứ bạn viết đơn giản và đi vào trọng tâm. Không phức tạp hơn mức cần thiết. Điều này cũng đúng với cấu hình của bạn. Tuy nhiên, đây là ứng dụng rất cụ thể. Mã hóa cứng những gì nên có trong cấu hình vì nó sẽ làm cho cấu hình của bạn "quá phức tạp" là thiết kế tồi. Trên thực tế, cố gắng "giữ mọi thứ đơn giản" là lý do tại sao các tệp cấu hình cuối cùng trở thành một mớ hỗn độn khổng lồ. Đôi khi động thái đơn giản nhất là modularize. Đây là lý do tại sao các tệp cấu hình của bạn nên được viết bằng ngôn ngữ lập trình mục đích chung nổi tiếng - không phải một ngôn ngữ cấu hình khủng khiếp nào đó (đọc: tất cả các "ngôn ngữ cấu hình" đều tệ ).
Một lần nữa, ai nên sửa đổi các tệp cấu hình là hoàn toàn phụ thuộc vào ứng dụng. Nhưng tôi đồng ý với miniquark, bất kỳ ai đang triển khai ứng dụng nên phụ trách cấu hình.
Nguồn kiểm soát mọi thứ bạn có thể. Kiểm soát nguồn là rất tốt. Bạn có thể hoàn nguyên mọi thứ một cách siêu dễ dàng và bạn có toàn bộ lịch sử về những thay đổi bạn đã thực hiện và hồ sơ về những người đã thực hiện những thay đổi đó. Vậy tại sao không?