나쁜 습관-환경을 설정하기 위해 사례를 전환


32

지난 3 년 동안 개발자로 일하면서 사람들이 switch 문을 사용하여 URL의 경로 (백엔드 및 프런트 엔드)를 설정하는 많은 예를 보았습니다. 아래는 이에 대한 예입니다.

백엔드 예제 (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;
}

프론트 엔드 예제 (자바 스크립트) :

(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/";
    }
})();

그것은 좋은 습관인지 나쁜 습관인지에 대해 논의되었으며, 우리는 이런 종류의 코드를 피하고 적절한 구성을 설정해야하기 때문에 나쁜 습관이라고 생각합니다. 그러나 솔직히 말해서 나는 정답을 알지 못하며 왜 권장되지 않는지, 이것을 구현하는 올바른 방법은 무엇입니까?

누군가 위의 연습의 장단점을 설명 할 수 있습니까?


13
이 라인만으로는 최적이 아닙니다. 경로 = " yourpath.com "; 구성은 코드 외부에 있어야합니다.
paparazzo

2
순수한 코드 검토 관점에서 a Dictionary는 C #에서 이것을 코딩하는 훨씬 깨끗한 방법입니다. ideone.com/45g5xO를 참조하십시오 . 또는 JS에서 오래된 객체를 사용하십시오 ( jsfiddle.net/1ouhovqq 참조) .
Danny Beckett

4
회사 이름이 "qa"가 포함 된 이름으로 변경되면 어떻게됩니까?
user253751

구성 파일을 사용하는 경우 소스 코드 제어에서 제어 파일을 제어해야합니다. 새 테스트 기계를 설정할 때 구성 파일을 하루에 여러 번 편집해야 할 수도 있습니다. 여전히 구성 파일이 가장 좋다고 생각하지만 detaul 구성 파일을보기 전에 환경 기반 파일을 먼저 찾고 싶을 수 있습니다.
Ian

1
왜 나쁜 습관이라고 생각하는지 정량화 할 수 없다면 나쁜 습관이라고 부르지 말아야한다고 생각하지 않습니다.
Roy

답변:


81

당신을 위해 작동하고 유지하기 쉬운 코드는 "좋은"정의입니다. 코드의 문제가 무엇인지 지적 할 수없는 경우 "좋은 습관"에 대한 누군가의 아이디어에 순종하기 위해 사물을 변경해서는 안됩니다.

이 경우 가장 분명한 문제는 리소스를 동적으로 선택하더라도 여전히 리소스가 애플리케이션에 하드 코딩되어 있다는 것입니다. 즉, 응용 프로그램을 다시 컴파일 / 재배포하지 않으면 이러한 리소스를 변경할 수 없습니다. 외부 구성 파일을 사용하면 해당 파일을 변경하고 응용 프로그램을 다시 시작 / 재로드하면됩니다.

그것이 문제인지 아닌지는 당신이하는 일에 달려 있습니다. 어쨌든 모든 요청과 함께 자동으로 재배포되는 Javascript 프레임 워크에서는 전혀 문제가 없습니다. 변경된 값은 다음에 응용 프로그램을 사용할 때 모든 사용자에게 전파됩니다. 액세스 할 수없는 위치에 컴파일 된 언어로 온-프레미스 배포를 수행하면 실제로 큰 문제가됩니다. 응용 프로그램을 다시 설치하는 데 시간이 오래 걸리거나 비용이 많이 들거나 밤에 가용성을 유지하기 위해 수행해야 할 수 있습니다.

하드 코딩 된 값이 문제인지 여부는 상황이 첫 번째 예와 비슷한 지 아니면 두 번째 예와 같은지에 따라 다릅니다.


15
나는 당신의 첫 단락을 좋아합니다. 물론, 문제가 무엇인지 지적하면서 ... "블로그 XYZ가 그렇게 말했기 때문에 이것이 나쁘다"라는 생각은 실제로 방지하는 것보다 더 나쁜 코드의 원인입니다.
corsiKa

5
초보자에게는 단순히 "만약 당신에게 효과가 있다면 괜찮습니다"라는 상대주의 아니라 살기 위해 오랜 시간 검증 된 원칙을 부여해야합니다 . 나는 하드 코딩 환경 값이 어떤 조명 하에서도 완전히 나쁜 습관이라고 말하는 것은 잘못이 아니라고 생각합니다.
Tulains Córdova

3
@ jpmc26 : 서버 측 코드를 배포하는 것이 사소한 것이 아니라 구성 값을 적은 오버 헤드로 업데이트 할 수있는 별도의 프로세스가 있다고 가정합니다. 반드시 사실도 아닙니다. 많은 상점은 배포 프로세스에서 오버 헤드가 거의 없습니다. 반면에 실제로는 구성 변경으로 변경된 코드를 배포하는 것만 큼 많은 오버 헤드가있는 상점이 있습니다. (모든 사람들로부터 승인이 필요한 검증 등). 중복 문제는 확실히 유효합니다.
케빈 카스 카트

2
환경 설정이 응용 프로그램 코드와 혼합되어 있으면 프로덕션에서 테스트를 치르거나 테스트에서 프로덕션을 치르거나 예기치 않은 치명적이거나 치명적인 다른 조합에서 논리적 인 오류 또는 실행 환경의 예기치 않은 변경이 발생합니다. C #의 코드와 별도로 환경 별 속성을 유지 관리하는 것은 일반적으로 쉽지 않습니다. 왜 불필요한 위험을 감수해야합니까?
John M Gant

1
@ user61852 "어떤 환경에서도 하드 코딩 환경 값이 완전히 나쁜 습관이라고 말하는 것은 잘못된 것이 아닙니다." "하드 코딩 환경 값은 항상 나쁜 습관입니다"로 구문 분석 항상 나쁜 습관이면 하드 코딩 환경 값으로 인해 발생할 수있는 하나 이상의 문제를 항상 식별 할 수 있어야합니다.
emory

14

당신은 이것이 나쁜 습관이라고 생각하는 데 절대적으로 옳습니다. 나는 이것을 프로덕션 코드에서 보았고 항상 당신을 물었습니다.

다른 환경을 추가하려고하면 어떻게됩니까? 아니면 개발 서버를 변경 하시겠습니까? 아니면 다른 위치로 장애 조치해야합니까? 구성이 코드와 직접 연결되어 있기 때문에 할 수 없습니다.

구성은 코드와 환경 자체로 강제 실행되어야합니다. Twelve-Factor App ( http://12factor.net/config ) 의 원칙 이지만 모든 응용 프로그램에 좋은 습관입니다. 환경 변수가 귀하의 상황에 적합하지 않다는 것을 알 수 있습니다.이 경우 구성 파일 데이터베이스에 해당 구성을 코드와 함께 (체크 인되지는 않음) 저장하는 것이 좋습니다.


구성 파일을 추적하지 않으면 보유한 구성 파일이 VCS에서 방금 체크 아웃 한 소프트웨어 버전에 유효한지 어떻게 알 수 있습니까? (즉, 추적되지 않은 구성 파일은 추적되지 않은 소스 파일과 다르지 않습니다. VCS 체크 아웃 없이는 빌드 및 배포 할 수 없습니다)
mattnz

추적되지 않은 구성 파일이 어려운 제안이라는 데 동의하지 않습니다. 이전에 처리 한 방법은 두 가지입니다. 하나는 배포 바이너리에 구성을 정의하는 XML 스키마가 포함되어 있으므로 주어진 구성 파일이 작동하는지 확인할 수 있습니다. 둘째, 각 환경의 구성 파일은 각 환경마다 다른 폴더가있는 문서 제어 시스템에 저장되었습니다. Git에서 브랜치 (버전 제어가 가능하지만 환경이없는 코드와 구별됨)를 사용하여 비슷한 작업을 수행 할 수 있습니다.
mgw854

5

하나는 (다른 사람들이 언급했듯이) 구현 세부 정보를 코드에 연결하기 때문에 나쁜 생각입니다. 이로 인해 변경하기가 어렵습니다.

이 답변 에서 언급했듯이 이제 새로운 환경을 추가하려면 프로그램을 새로운 환경에 추가하는 대신 코드를 어디서나 업데이트해야 합니다.

Javascript 코드 에서이 작업을 수행하는 데 또 다른 심각한 결함이 있습니다. 회사 내부를 잠재적 공격자에게 노출시키고 있습니다. 물론, 방화벽 뒤에있을 수 있지만 불만이있는 직원이나 바이러스를 감염시키는 사람이 여전히있을 수 있습니다.

나쁜 소식이 있습니다.

가장 잘 할 수있는 일이 (이전에 링크 된 대답으로, 열두 요인 앱이 주제에 대한 훌륭한 조언이 있습니다) 환경에서 구성을 설정하는 것입니다. 언어에 따라 여러 가지 방법이 있습니다. 가장 쉬운 방법 중 하나는 대개 환경 변수를 설정하는 것입니다. 그런 다음 로컬 개발자 상자, qa 또는 프로덕션 여부에 관계없이 실행중인 위치에 따라 변수를 변경하면됩니다. 다른 옵션은 값을 .ini파일 또는 JSON 에 저장하는 것 입니다. 또 다른 대안은 구성 값을 실제 코드로 저장하는 것입니다. 사용중인 언어 나 환경에 따라 좋은 생각 일 수도 있고 아닐 수도 있습니다.

그러나 궁극적 인 목표는 하나의 코드베이스를 가져 와서 지원되는 아키텍처 / 연결성을 가진 모든 머신 에 드롭하고 어떤 식 으로든 코드를 수정하지 않고 실행할 수있게하는 것입니다.


1

백엔드를 내 컴퓨터에서 실행하고 포트 55793에서는 실행하지 않으려면 (예 : 여러 버전을 동시에 실행하여 비교하는 경우) 어떻게해야합니까? 한 시스템에서 응용 프로그램 백엔드를 실행하고 다른 시스템에서 액세스하려면 어떻게해야합니까? 네 번째 환경을 추가하려면 어떻게합니까? 다른 사람들이 지적했듯이 기본 구성을 변경하기 위해 다시 컴파일해야합니다.

지금까지 설명한 접근법은 지금까지 팀에서 실제로 작동했을 수도 있지만 의미가 없습니다. 중앙 구성 파일에서이 경로와 같은 매개 변수를 임의로 설정할 수있는 구성 시스템은 고정 된 옵션 만 제공하는 것보다 훨씬 융통성이 있으며 switch statement 방식을 사용하면 어떤 이점이 있습니까? 없어!


0

그것은이다 BAD의 연습 .

소프트웨어 디자인의 기본 원칙 : 프로그램 내부에 구성 값을 하드 코딩하지 마십시오. 이것은 미래에 변화가 일어날 가능성이있는 모든 경우에 특히 그렇습니다.

개발 한 프로그램 코드는 QA 테스트, UAT 및 프로덕션과 같은 환경에 사용되는 것과 동일한 코드 여야합니다. 환경이 변경되어 나중에 구성을 변경해야하거나 새로운 환경에서 사용해야하는 경우에는 문제가 없습니다. 그러나 그렇게하기 위해 프로그램 코드를 건드리지 않아도됩니다. 또한 각 환경마다 다른 버전의 코드가 없어야합니다. 테스트 한 후 프로그램이 변경된 경우 해당 버전을 테스트하지 않은 것입니다. 소프트웨어 엔지니어, 소프트웨어 품질 보증 전문가, IT 프로젝트 관리 전문가, IT 감사관에게 문의하십시오.

누군가 테스트를 다른 서버로 옮길 수 있습니다. 누군가가 사용자 교육 환경 또는 영업 데모 환경을 원할 수도 있습니다. 관리자 구성을 위해 프로그래머에게 갈 필요가 없습니다.

소프트웨어는 이유 내에서 예기치 않은 상황을 처리 할 수있을 정도로 유연하고 강력해야합니다.

또한 소프트웨어는 단순히 작성해서는 안되지만 현재로서는 가장 쉬운 것 같습니다. 소프트웨어 개발 비용은 소프트웨어 유지 보수 비용보다 수명이 짧습니다. 그리고 지금부터 일년 후에, 당신은 그 코드를 다루는 사람이 아닐 수도 있습니다. 당신은 아마도 당신이 남은 엉망진창을 풀어야 할 다음 가난한 사람들을 위해 떠날 것을 생각해야 할 것입니다. 또는 당신은 몇 년 후 코드를 집어 들었을 수도 있습니다.

최선을 다해 올바르게 코딩하십시오. 나중에 문제가 될 가능성은 적습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.