데이터 값을 프로그램에 하드 코딩하면 이점이 있습니까?

나는 자율적이고 초보자 같은 코더이므로 프로그래머 링고를 못쓰게되면 사과드립니다.

나는 데이터에 대한 쿼리에서 보고서를 생성하는 도구를 본질적으로 만드는 개발자에게 지속적으로 업데이트되는 데이터를 제공하는 프로젝트를 진행하고 있습니다.

관련된 모든 사람들은 데이터 생성 (스키마가 아니라 도메인 / 값 자체)을 보고서 생성 프로그램에 하드 코딩해야한다고 생각하는 것 같습니다.

예를 들어 직원에 대해보고한다고 가정합니다. 보고서는 각 부서에 대한 제목과 함께 범주로 분할 된 다음 각 부서 아래에 직책의 소제목이되고 각 소제목 아래에 직원 목록이 표시됩니다. 개발자는 부서와 직책을 하드 코딩하려고합니다. 반면에, 나는 그들이 런타임에 그런 것들을 쿼리하고, 그것들을 기준으로 레코드를 정렬하고, 어떤 값이 있는지에 따라 동적으로 보고서 헤더를 생성 할 수 있다고 생각합니다.

잠재적 가치 목록은 시간이 지남에 따라 변경되므로 (예 : 부서가 생성 / 이름 변경되고, 새로운 직책이 추가됨) 코드를 지속적으로 업데이트해야합니다. 코드 유지 관리 단계를 건너 뛰고 보고서를 동적으로 구성 할 수있는 것 같습니다.

나는 개발자가 아니기 때문에 내가 무엇을 놓치고 있는지 궁금합니다. 이와 같은 도구에 값을 하드 코딩하면 어떤 이점이 있습니까? 이것은 일반적으로 프로그램 설계 방식입니까?

위키 백과 :

하드 코딩 (하드 코딩 또는 하드 코딩)은 아마도 소급해서 만 입력 또는 구성 데이터로 간주 될 수있는 것을 프로그램 또는 기타 실행 가능한 개체의 소스 코드에 직접 포함하거나 데이터를 외부 소스에서 가져 오거나 지정된 입력으로 프로그램 자체에서 데이터를 생성하거나 형식을 지정하는 대신

하드 코딩은 반 패턴으로 간주됩니다.

안티 패턴으로 간주되는 하드 코딩은 최종 사용자가 프로그램 외부의 일부 수단으로 세부 사항을 변경하는 것이 더 편리한 경우 입력 데이터 또는 원하는 형식이 변경 될 때마다 프로그램의 소스 코드를 변경해야합니다.

때로는 피할 수 없지만 일시적이어야합니다.

하드 코딩이 종종 필요합니다. 프로그래머는 최종 사용자를위한 동적 사용자 인터페이스 솔루션이 없을 수 있지만 여전히 기능을 제공하거나 프로그램을 릴리스해야합니다. 이것은 일반적으로 일시적이지만 단기적으로 코드를 전달해야하는 압력을 해결합니다. 나중에, 사용자가 최종 사용자에게 결과 또는 결과를 수정할 수있는 매개 변수를 전달할 수 있도록 소프트 코딩이 수행됩니다.

• 메시지를 하드 코딩하면 프로그램을 국제화하기가 어렵습니다.
• 하드 코딩 경로는 다른 위치에 적응하기가 어렵습니다.

하드 코딩의 유일한 장점은 코드를 빠르게 전달하는 것 같습니다.

정말? 유효한 유스 케이스가 없습니까?

하드 코딩 이 일반적으로 반 패턴 이거나 최소한 매우 나쁜 코드 냄새 라는 데 동의하지만 , 그럴만한 경우가 많이 있습니다.

• 단순성 ( YAGNI ),
• 입력은 실제로 일정하며 변경되지 않습니다 (즉, 자연 또는 비즈니스 상수 또는 근사값을 나타냅니다 (예 : 0, PI, ...)).
• 임베디드 소프트웨어 (메모리 및 할당 제약 조건이 떠오름)
• 보안 소프트웨어 (이러한 값은 암호화 토큰 및 솔트와 같이 해독 및 역 엔지니어링하기 어렵거나 해독 할 수 없음),
• 생성 된 코드 (전 처리기 또는 생성기는 구성 가능하지만 하드 코딩 된 값으로 코드를 뱉어 냄),
• 그리고 아마도 몇 가지 더.

아직도 안티 패턴 ? 너무 엔지니어링입니다 ! 소프트웨어의 수명에 관한 것입니다 !!

나는 큰 이유가 있다고 말하고있는 것이 아니라 일반적으로 하드 코딩 된 값을 사용합니다. 그러나 일부는 유효한 이유로 쉽게 패스를 얻을 수 있습니다.

그리고 단순성 / YAGNI 에 관한 첫 번째 것도 사소한 것으로 생각하지 마십시오. 좁은 사용 사례에 대해 하나의 작업을 수행하는 간단한 스크립트에 대해 미친 파서와 값 검사기를 구현할 이유가 없을 것입니다.

균형을 찾기가 어렵습니다. 때로는 소프트웨어가 시작된 간단한 스크립트보다 더 길어지고 오래 지속될 것이라고 예측하지 못합니다. 때때로, 그것은 다른 방법입니다 : 우리는 일을 과도하게 엔지니어링하고, 프로젝트는 Pragmatic Programmer를 읽는 것보다 더 빨리 선반에 놓입니다. 초기 프로토 타입이 필요했던 것보다 시간과 노력을 낭비했습니다.

그것은 안티 패턴의 의미입니다. 스펙트럼의 두 극단에 모두 있으며 외형은 코드를 검토하는 사람의 감도에 달려 있습니다.

값을 하드 코딩해도 괜찮습니다. 예를 들어, 0과 같은 숫자 또는 알고리즘 목적으로 특정 값이어야하는 비트 마스크에 대한 하나 또는 여러 n ^ 2-1 값이 있습니다. 이러한 값을 구성 가능 항목에 허용하면 아무런 가치가 없으며 문제의 가능성 만 열립니다. 다시 말해, 값을 변경하면 문제가 해결 될 경우 하드 코딩해야합니다.

당신이 준 예제에서, 하드 코딩이 유용한 곳을 보지 못했습니다. 언급 한 모든 내용은 제목을 포함하여 이미 데이터베이스에 있어야합니다. 프리젠 테이션을 구동하는 항목 (예 : 정렬 순서)이없는 경우 추가 할 수 있습니다.

하드 코딩 된 값을 최종 사용자가 대신 구성 할 수있는 강력한 솔루션을 구현하려면 해당 값의 강력한 유효성 검사가 필요합니다. 빈 줄에 넣었습니까? 숫자 여야하는 곳에 숫자가 아닌 것을 넣었습니까? 그들은 SQL 주입을하고 있습니까? 기타.

하드 코딩은 이러한 위험을 많이 피합니다.

하드 코딩이 항상 또는 종종 좋은 아이디어라고 말하는 것은 아닙니다. 이것은 고려해야 할 요소 중 하나 일뿐입니다.