Thực hành xấu - trường hợp chuyển đổi để thiết lập môi trường


32

Trong ba năm qua, tôi đã làm việc với tư cách là nhà phát triển, tôi đã thấy rất nhiều ví dụ về việc mọi người sử dụng câu lệnh chuyển đổi để đặt đường dẫn (cả ở mặt sau và mặt trước) cho một URL. Dưới đây là một ví dụ về điều này:

Ví dụ back-end (C #):

public static string getHost(EnvironmentEnum environment){
    var path = String.Empty;
    switch (environment)
    {
        case EnvironmentEnum.dev:
            path = "http://localhost:55793/";
            break;
        case EnvironmentEnum.uat:
            path = "http://dev.yourpath.com/";
            break;
        case EnvironmentEnum.production:
            path = "http://yourpath.com/";
            break;
    }
    return path;
}

Ví dụ về giao diện người dùng (JavaScript):

(function () {
    if (window.location.host.indexOf("localhost") !== -1) {
        window.serviceUrl = "http://localhost:57939/";
    }
    else if (window.location.host.indexOf("qa") !== -1) {
        window.serviceUrl = "http://dev.yourpath.com/";
    }
    else {
        window.serviceUrl = "http://yourpath.com/";
    }
})();

Nó đã được thảo luận cho dù đó là một thực tiễn tốt hay xấu, và tôi nghĩ đó là một thực tiễn xấu, bởi vì chúng ta phải tránh loại mã này và thiết lập một cấu hình phù hợp. Nhưng thành thật mà nói tôi thực sự không biết câu trả lời thích hợp và tại sao nó không được khuyến khích và cách chính xác để thực hiện điều này là gì.

ai đó có thể giải thích nó những ưu và nhược điểm của thực hành trên?


13
Chỉ riêng dòng này là không tối ưu. đường dẫn = " yourpath.com "; Cấu hình nên được bên ngoài để mã.
paparazzo

2
Từ góc độ xem xét mã thuần túy, a Dictionarylà cách mã hóa gọn gàng hơn nhiều trong C #. Xem ideone.com/45g5xO . Hoặc trong JS sử dụng một đối tượng cũ, xem jsfiddle.net/1ouhovqq .
Danny Beckett

4
Điều gì xảy ra nếu tên công ty của bạn thay đổi thành tên có chứa "qa"?
dùng253751

Hãy nhớ rằng nếu bạn sử dụng tệp cấu hình, nó cần được kiểm soát trong điều khiển mã nguồn .... Bất kỳ bạn cũng có thể phải chỉnh sửa tệp cấu hình nhiều lần trong ngày khi bạn thiết lập các máy kiểm tra mới. Tôi vẫn nghĩ rằng một tệp cấu hình là tốt nhất, nhưng trước tiên bạn có thể muốn tìm một tệp có tên dựa trên Môi trường trước khi xem tệp cấu hình detaul.
Ian

1
Tôi không nghĩ bạn nên đi khắp nơi gọi những điều thực tiễn tồi tệ nếu bạn không thể định lượng được lý do tại sao bạn nghĩ rằng đó là một thực tiễn tồi
Roy

Câu trả lời:


81

Mã phù hợp với bạn và dễ duy trì là theo định nghĩa "tốt". Bạn không bao giờ nên thay đổi mọi thứ chỉ vì mục đích tuân theo ý tưởng "thực hành tốt" của ai đó nếu người đó không thể chỉ ra vấn đề với mã của bạn là gì.

Trong trường hợp này, vấn đề rõ ràng nhất là tài nguyên được mã hóa cứng vào ứng dụng của bạn - ngay cả khi chúng được chọn linh hoạt, chúng vẫn được mã hóa cứng. Điều này có nghĩa là bạn không thể thay đổi các tài nguyên này mà không biên dịch lại / triển khai lại ứng dụng của bạn. Với tệp cấu hình bên ngoài, bạn chỉ phải thay đổi tệp đó và khởi động lại / tải lại ứng dụng của mình.

Có hay không đó là một vấn đề phụ thuộc vào những gì bạn làm với nó. Trong một khung Javascript được tự động phân phối lại với mọi yêu cầu, không có vấn đề gì cả - giá trị thay đổi sẽ lan truyền đến mọi người dùng vào lần tiếp theo họ sử dụng ứng dụng. Với việc triển khai tại chỗ bằng một ngôn ngữ được biên dịch ở một vị trí không thể tiếp cận, đó thực sự là một vấn đề rất lớn. Cài đặt lại ứng dụng có thể mất nhiều thời gian, tốn rất nhiều tiền hoặc phải thực hiện vào ban đêm để duy trì tính khả dụng.

Việc các giá trị được mã hóa cứng có phải là một vấn đề hay không phụ thuộc vào việc tình huống của bạn giống ví dụ thứ nhất hay giống ví dụ thứ hai hơn.


15
Tôi yêu đoạn đầu tiên của bạn. Chắc chắn, bạn theo dõi nó với ... chỉ ra vấn đề là gì ... nhưng ý kiến ​​cho rằng "điều này là xấu vì blog XYZ đã nói như vậy" là nguyên nhân của nhiều mã xấu hơn thực tế ngăn chặn.
corsiKa

5
Người mới bắt đầu nên được đưa ra các nguyên tắc được thử nghiệm theo thời gian để sống, không chỉ đơn giản là "nếu nó phù hợp với bạn thì nó vẫn ổn" . Tôi đoán tôi không sai khi nói rằng các giá trị môi trường mã hóa cứng hoàn toàn là thực tiễn xấu dưới bất kỳ ánh sáng nào.
Tulains Córdova

3
@ jpmc26: Tất nhiên, bạn cho rằng việc triển khai mã phía máy chủ là không tầm thường và cũng có một số quy trình riêng biệt thông qua đó các giá trị cấu hình có thể được cập nhật với ít chi phí hơn. Không nhất thiết phải đúng. Nhiều cửa hàng có rất ít chi phí trong quá trình triển khai của họ. Mặt khác, thực sự có một số cửa hàng nơi các thay đổi cấu hình về cơ bản có nhiều chi phí như triển khai mã thay đổi. (Xác nhận, cần sự chấp thuận của cả một nhóm người, v.v.). Các mối quan tâm trùng lặp chắc chắn là hợp lệ mặc dù.
Kevin Cathcart

2
Với các cài đặt môi trường được trộn lẫn với mã ứng dụng của bạn, bạn sẽ gặp phải một lỗi logic hoặc thay đổi không lường trước được trong môi trường thực thi. Tránh xa việc kiểm tra sản xuất hoặc sản xuất từ ​​kiểm tra hoặc một số kết hợp bất ngờ và có thể là thảm họa khác. Việc duy trì các thuộc tính đặc thù của môi trường tách biệt với mã trong C # nói chung là không đáng kể. Tại sao có một rủi ro không cần thiết?
John M Gant

1
@ user61852 "Tôi đoán tôi không sai khi nói rằng các giá trị môi trường mã hóa cứng hoàn toàn là thực tiễn xấu dưới bất kỳ ánh sáng nào." phân tích cú pháp thành "giá trị môi trường mã hóa cứng luôn là thực tiễn xấu" Nếu luôn luôn là thực tiễn xấu, thì luôn luôn có thể xác định ít nhất một vấn đề mà giá trị môi trường mã hóa cứng sẽ gây ra.
emory

14

Bạn hoàn toàn đúng khi nghĩ rằng đây là một thực hành xấu. Tôi đã thấy điều này trong mã sản xuất và nó luôn quay lại cắn bạn.

Điều gì xảy ra khi bạn muốn thêm một môi trường khác? Hoặc thay đổi máy chủ phát triển của bạn? Hoặc bạn cần phải thất bại ở một địa điểm khác? Bạn không thể vì cấu hình của bạn được liên kết trực tiếp với mã.

Cấu hình nên được buộc ra khỏi mã và vào chính môi trường. Đó là một nguyên tắc của Ứng dụng Mười hai yếu tố ( http://12factor.net/config ), nhưng đó là một cách thực hành tốt cho bất kỳ ứng dụng nào. Bạn có thể thấy rằng các biến môi trường không phù hợp với tình huống của bạn, trong trường hợp đó tôi khuyên bạn nên xem việc lưu trữ cấu hình đó trong cơ sở dữ liệu của tệp cấu hình cùng với mã (nhưng không được đăng ký bằng).


Nếu bạn không theo dõi tệp cấu hình, làm sao bạn biết tệp cấu hình bạn có hợp lệ cho phiên bản phần mềm bạn vừa kiểm tra ra khỏi VCS của mình. (tức là tệp cấu hình chưa được mã hóa không khác với tệp nguồn chưa được mã hóa - bạn không thể xây dựng và triển khai từ thanh toán VCS mà không có nó)
mattnz 7/07/2015

Tôi không đồng ý rằng một tập tin cấu hình không bị theo dõi là một đề xuất khó khăn. Cách tôi đã xử lý vấn đề này trước đây là hai lần: một, nhị phân để triển khai cũng chứa Lược đồ XML xác định cấu hình của nó (vì vậy bạn có thể xác minh rằng một tệp cấu hình đã cho sẽ hoạt động). Thứ hai, các tệp cấu hình cho từng môi trường được lưu trữ trong một hệ thống kiểm soát tài liệu với các thư mục khác nhau cho từng môi trường. Một cái gì đó tương tự có thể được thực hiện trong Git với các nhánh - phiên bản được kiểm soát, nhưng bị phân biệt đối xử với mã không có môi trường.
mgw854

5

Đối với một người, (như những người khác đã đề cập) đây là một ý tưởng tồi vì bạn đang buộc các chi tiết triển khai vào mã của mình. Điều này gây khó khăn cho việc thay đổi mọi thứ.

Như đã đề cập trong câu trả lời này , nếu bạn muốn thêm một môi trường mới bây giờ, bạn phải cập nhật mã của mình ở mọi nơi , thay vì chỉ thêm chương trình của bạn vào một môi trường mới.

Có một lỗ hổng nghiêm trọng khác khi thực hiện điều này trong mã Javascript của bạn: Bạn đang phơi bày nội bộ của công ty bạn trước những kẻ tấn công tiềm năng. Chắc chắn, bạn có thể đứng sau một bức tường lửa, nhưng bạn vẫn có thể có một nhân viên bất mãn hoặc ai đó cho phép virus xâm nhập.

Tin xấu gấu.

Điều tốt nhất để làm là đặt cấu hình của bạn từ môi trường (như trong câu trả lời được liên kết trước đó, Ứng dụng Mười hai yếu tố có lời khuyên tuyệt vời về chủ đề này). Có một số cách để làm điều này tùy thuộc vào ngôn ngữ của bạn. Một trong những cách dễ nhất (thông thường) là chỉ đặt các biến môi trường. Sau đó, bạn chỉ cần thay đổi các biến tùy thuộc vào nơi bạn đang chạy - cho dù đó là hộp dev, qa hoặc sản xuất. Một tùy chọn khác là lưu trữ các giá trị trong một .initệp hoặc JSON. Tuy nhiên, một sự thay thế khác sẽ được lưu trữ các giá trị cấu hình của bạn dưới dạng mã thực tế. Tùy thuộc vào ngôn ngữ hoặc môi trường bạn đang sử dụng, điều này có thể hoặc không phải là một ý tưởng tốt.

Nhưng mục tiêu cuối cùng là cho phép bạn lấy một cơ sở mã, thả nó vào bất kỳ máy nào có kiến ​​trúc / kết nối được hỗ trợ và có thể chạy nó mà không cần sửa đổi mã theo bất kỳ cách nào.


1

Điều gì sẽ xảy ra nếu tôi muốn chạy phụ trợ trên máy của mình nhưng không phải trên cổng 55793, ví dụ nếu tôi đang chạy nhiều phiên bản cùng một lúc để so sánh chúng? Điều gì xảy ra nếu tôi muốn chạy phụ trợ ứng dụng trên một máy, nhưng truy cập nó từ máy khác? Nếu tôi muốn thêm môi trường thứ tư thì sao? Như những người khác đã chỉ ra, bạn phải biên dịch lại chỉ để thay đổi cấu hình cơ bản.

Cách tiếp cận bạn đã mô tả có thể đã có hiệu quả trong thực tế cho nhóm của bạn cho đến nay, nhưng nó rất hạn chế. Một hệ thống cấu hình cho phép các tham số như đường dẫn này được đặt tùy ý trong tệp cấu hình trung tâm linh hoạt hơn nhiều so với hệ thống chỉ cung cấp các tùy chọn cố định và bạn có lợi thế gì với cách tiếp cận câu lệnh chuyển đổi? Không ai!


0

Đó là một THỰC HÀNH BAD .

Một nguyên tắc cơ bản của thiết kế phần mềm: Đừng bỏ qua các giá trị cấu hình mã cứng trong các chương trình của bạn. Điều này đặc biệt đúng với bất cứ điều gì có cơ hội thay đổi hợp lý trong tương lai.

Mã chương trình mà bạn phát triển phải là cùng một mã đi vào bất kỳ môi trường nào như kiểm tra QA, UAT và sản xuất. Nếu ai đó cần thay đổi cấu hình sau này vì môi trường đã thay đổi hoặc họ cần sử dụng nó trong một môi trường mới, tốt thôi. Nhưng họ không bao giờ phải chạm vào mã chương trình của bạn để làm như vậy. Và bạn không nên có các phiên bản mã khác nhau cho từng môi trường. Nếu chương trình của bạn đã thay đổi kể từ khi được thử nghiệm, thì bạn đã không thử phiên bản đó. Hỏi bất kỳ kỹ sư phần mềm, bất kỳ chuyên gia đảm bảo chất lượng phần mềm, bất kỳ chuyên gia quản lý dự án CNTT, bất kỳ kiểm toán viên CNTT nào.

Ai đó có thể di chuyển thử nghiệm đến một máy chủ khác. Ai đó có thể quyết định cũng muốn có một môi trường đào tạo người dùng hoặc môi trường cho các cuộc biểu tình bán hàng. Họ không cần phải đi đến một lập trình viên cho cấu hình quản trị.

Phần mềm phải linh hoạt và đủ mạnh để xử lý các tình huống bất ngờ, theo lý do.

Hơn nữa, phần mềm không nên được viết đơn giản tuy nhiên có vẻ dễ nhất đối với bạn tại thời điểm này. Chi phí phát triển phần mềm là nhỏ so với chi phí bảo trì phần mềm trong suốt vòng đời của nó. Và giả sử một năm kể từ bây giờ, bạn có thể không phải là người làm việc với mã đó. Bạn nên suy nghĩ về những gì bạn sẽ để lại cho kẻ ngốc đáng thương tiếp theo, người phải nhặt bất cứ thứ gì bạn có thể để lại, có lẽ nhiều năm sau khi bạn tiếp tục với đồng cỏ xanh hơn. Hoặc bạn có thể là người nhặt được mã năm sau đó, không tin vào những gì bạn đã làm hồi đó.

Mã mọi thứ đúng, tốt nhất bạn có thể. Nó ít có khả năng trở thành một vấn đề sau này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.