저는 독학하고 초보적인 코더이므로 프로그래머 용어를 틀리지 않으면 사과드립니다.

저는 지속적으로 업데이트 될 데이터를 제공하는 프로젝트를 진행하고 있습니다. 개발자는 기본적으로 데이터 쿼리에서 보고서를 생성하는 도구를 만들 것입니다.

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

예를 들어 직원에 대해보고한다고 가정하면 보고서가 분할됩니다. 각 부서의 제목이있는 범주로, 각 부서 제목 아래에는 직책의 부제목이 있고, 각 부제목 아래에는 직원 목록이 있습니다. 개발자는 부서와 직책을 하드 코딩하려고합니다. 다른 한편으로는 런타임에 이러한 것들을 쿼리하고, 레코드를 정렬하고, 값에 따라 동적으로 보고서 헤더를 생성 할 수 있다고 생각합니다.

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

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

댓글

  • 하드 코딩 된 항목의 중복 가능성 제거 값 및 방어 설계 vs YAGNI
  • 보고서 교차 분석, 즉 행의 값이 열로 표시되어야합니까?
  • @Brendan-보고서에서 값을 하드 코딩하는 경우 , ‘ 두 위치 (데이터 소스 및 보고서)에서 목록을 변경해야하는 반면 보고서가 동적 인 경우 한 위치 (보고서)에서만 변경하면됩니다. .
  • @Brendan 왜 세 개의 위치로 끝나나요? 아마도 내 이해가 틀렸지 만 ‘ 데이터베이스에서 데이터를 가져 오는 SQL 쿼리를 구상하고 있습니다. 애플리케이션은 예를 들어 부서별로 반환 된 값을 집계 / 그룹화합니다. ‘ 여러 DB 쿼리의 오버 헤드를 기꺼이 갖고 싶다면 정말로 원하는 경우 별개의 부서 / 역할 제목을 선택할 수 있습니다. 데이터가 둘 이상의 위치에 존재하는 경우는 없습니다. 보고서는 데이터를 기반으로합니다.
  • @Brendan 또한 한 위치에 있다는 정의에 동의하지 않습니다. ‘ 소스 코드 전체에 흩어져있는 여러 위치에 있습니다.

답변

Wikipedia :

하드 코딩 (하드 코딩 또는 하드 코딩)은 입력 또는 구성 데이터로 간주 될 수있는 내용을 프로그램 또는 기타 실행 가능한 개체의 소스 코드에 직접 삽입하거나 외부 소스로부터 데이터를 얻거나 주어진 입력을 사용하여 프로그램 자체에서 데이터를 생성하거나 형식화하는 대신.

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

n 안티 패턴, 하드 코딩을 사용하려면 입력 데이터 나 원하는 형식이 변경 될 때마다 프로그램의 소스 코드를 변경해야합니다. 최종 사용자가 프로그램 외부에서 어떤 방법으로 세부 사항을 변경하는 것이 더 편리 할 수 있습니다.

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

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

  • 하드 코딩 메시지 수가 많아 프로그램을 국제화하기가 어렵습니다.
  • 하드 코딩 경로로 인해 다른 위치에 적응하기가 어렵습니다.

하드 코딩의 유일한 장점은 빠른 코드 전달입니다.

댓글

  • 확인 하지만 ” 유일한 이점 “은 종종 매우 중요합니다. 프로그래밍에서 디자인 결정은 종종 미래의 교정과 현재의 빠른 제공 사이의 균형에 관한 것이므로 하드 코딩은 완벽하게 수용 가능한 선택이 될 수 있습니다. 때때로 하드 코딩이 아님 은 잘못된 설계 선택입니다.
  • -1 ‘이 답변이 도움이되지 않는다고 생각합니다. 본질적으로 ‘ 값을 소스 코드에 부적절하게 삽입하는 것은 부적절하다고 ‘ 말합니다. 나는 OP가 소스 코드에 속할 수 있고 따라서 Wikipedia 정의를 벗어날 수있는시기에 대한 지침을 원한다고 생각합니다.
  • 하드 코딩은 프로세스의 중요한 부분이어야하며 안티 패턴이 구식이라고 생각하면 Angular Tour of Heroes 튜토리얼은 거대한 소프트웨어 하우스가 직접 장식하거나 중간 단계로 의무화하는 대표적인 예입니다. 또한 동적 데이터로 이동할 때 일부 하드 코딩 된 데이터를 대체로 유지해야합니다. 아마도 환경 변수 또는 코드 자체의 부울 토글에 의해 제어되어 버그 및 보안 문제를 적절하게 분리 할 수 있습니다. 줄.

답변

정말? 가능한 유효한 사용 사례가 없습니까?

하드 코딩 이 일반적으로 반 패턴 또는 적어도 아주 나쁜 코드 냄새 는 의미가있는 경우가 많이 있습니다. 다음은 몇 가지입니다.

  • 단순성 / YAGNI .

  • 실제로 변경되지 않는 실제 상수.

    즉, 상수는 자연 em을 나타냅니다. > 또는 비즈니스 상수 또는 1의 근사치 입니다. (예 : 0, PI, …)

  • 하드웨어 또는 소프트웨어 환경 제약

    임베디드 소프트웨어에서는 메모리 및 할당 제약이 떠 오릅니다.

  • 보안 소프트웨어

    이 값은 사용할 수 없으며 디코딩 또는 리버스 엔지니어링이 쉽지 않습니다. 암호화 토큰 및 솔트. (하드 코딩으로 유지하는 것도 명백한 단점이 있습니다 …)

  • 생성 된 코드

    전 처리기 또는 생성기는 구성 가능하지만 하드 코딩 된 값으로 코드를 뱉어냅니다. 규칙 엔진에 의존하는 코드 나 모델 기반 아키텍처가있는 경우에는 드물지 않습니다.

  • 고성능 코드

    이 코드는 ” 생성 된 ” 코드입니다. , 훨씬 더 전문화되어 있습니다. 예 : 예상치 못한 변경이있는 미리 결정된 조회 / 계산 테이블. 예를 들어 이것은 그래픽 프로그래밍에서 전혀 드문 일이 아닙니다.

  • 구성 및 폴백

    실제 코드와 구성 파일 모두에서 구성 값이있을 수 있으며 여러 경우 (구성을 사용할 수없는 경우, 구성 요소가 다음과 같이 응답하지 않는 경우) 예상 등). 그래도 일반적으로 코드 외부에 보관하고 찾아 보는 것이 가장 좋지만 특정 조치 / 문제 / 상황에 대한 특정 가치 / 반응을 절대적으로 갖고 싶은 경우가있을 수 있습니다.

  • 그리고 아마도 몇 가지 더 …

아직 반 패턴

a>? 과도한 엔지니어링 도 마찬가지입니다. 소프트웨어의 기대 수명에 관한 것입니다 !!

내가 말하는 것은 아닙니다. 모든 큰 이유가 있으며 일반적으로 하드 코딩 된 값을 꺼려합니다. 그러나 일부는 유효한 이유로 쉽게 패스를 얻을 수 있습니다.

단순성과 관련하여 첫 번째 항목을 감독하지 마십시오 ./ YAGNI 는 “사소한 것입니다. 좁은 사용 사례에 대해 하나의 작업을 수행하는 간단한 스크립트에 대해 미친 파서 및 값 검사기를 구현할 이유가 없습니다.” 좋습니다.

xkcd : 일반적인 문제-

밸을 찾기가 어렵습니다. ance. 때때로 당신은 소프트웨어가 시작된 단순한 스크립트보다 성장하고 오래 지속될 것이라고 예측하지 못합니다.하지만 종종 그 반대의 경우가 있습니다. 우리는 일을 과도하게 엔지니어링하고 프로젝트는 가능한 한 빨리 보류됩니다. 실용적인 프로그래머를 읽으십시오. 초기 프로토 타입에 필요하지 않은 것보다 시간과 노력을 낭비했습니다.

그것은 안티 패턴의 평균적인 것입니다. 그것들은 스펙트럼의 양쪽 극단에 존재하며 그 모양은 코드를 검토하는 사람의 민감도.

개인적으로는 무언가가 변경 될 수 있는 것을 보자 마자 항상 일반적인 경로로 이동하는 경향이 있습니다. “두 번 이상해야했습니다.하지만 더 정확한 접근 방식은 하드 코딩 비용과 특정 상황에 대한 코드 생성 또는 생성 비용을 신중하게 평가하는 것입니다.작업을 수동으로 수행하는 것보다 자동화 할 가치가 있는지 결정하는 것과 같습니다. 시간과 비용 만 고려하면됩니다.

xkcd : 그럴만 한 가치가 있습니까?-

댓글

  • ‘ 재밌습니다. 제가 직접이 작업을 수행했고 값을 동적으로 처리하는 것이 훨씬 쉽고 빠르며 깔끔했습니다. Python은 최종 제품이 Java로 코딩 될 것이라고 생각하지만 차이가 있다면 값을 하드 코딩 할 때 각 수신 열을 여러 위치에서 추적해야했기 때문에 과도하게 엔지니어링 된 느낌이 들었습니다.
  • @Tom : ‘ 하드 코딩 된 값을 사용하는 것보다 구성 조회 라이브러리를 구현 (또는 재사용)하는 것이 더 쉽고 빠르다고 말씀하십니까? 또한 ‘ 당신의 마지막 문장이 오버 엔지니어링의 정의에 어떻게 부합하는지 알지 못합니다. 장어는 분명히 지저분하고, ‘ 하드 코딩되고 복제 된 경우 ‘ 훨씬 더 나빠집니다. 질문에 대한 질문입니다. 아마도 오해를 받았을 것입니다.하지만 값이 매번 하드 코딩 된 것이 아니라 프로그램의 단일 지점에 있음을 의미하는 것 같았습니다.
  • 어쨌든, I ‘ 유효한 사례를 ‘ 지적합니다. 저는 ‘ 또한 저의 마지막 문장에서 ‘ 논란의 여지가 있음을 지적합니다. ‘ 모든 사람과 팀이 다양한 기술 수준을 가진 사람들을 기쁘게 할 수는 없습니다.
  • @Tom, don ‘ t 너무 짧게 팔아요. 당신은 ‘ 확실히 뭔가를하고 있습니다. 하드 코딩 Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']와는 반대로 부서 및 직위 필드를 확인하여 데이터를 구성하는 빠른 알고리즘을 작성하는 것이 더 쉽고 시간이 적게 소요되는 것 같습니다. 또한 새로운 부서 또는 직함이 도입 된 경우 하드 코딩 된 배열을 유지 관리하는 것이 훨씬 더 어려울 것입니다.
  • 하드 코딩 할 수있는 더 복잡한 것을 가질 수 있습니다. 내가 몇 년 전에 썼다는 생각에 떠오르는 것은 일련의 값의 가능한 모든 순열이었습니다. 임의의 유효한 방향을 찾아야했습니다. 임의 순열을 선택한 다음 첫 번째 유효한 결과를 취하는 것이 가장 효율적인 솔루션이었으며 O (N ^ 3) 루프에 있었기 때문에 효율성이 중요했습니다.

답변

값을 하드 코딩해도되는 경우가 있습니다. 예를 들어 0, 1 또는 1과 같은 숫자가 있습니다. 알고리즘 목적을 위해 특정 값이어야하는 비트 마스크에 대한 다양한 n ^ 2-1 값. 이러한 값을 구성 가능 항목에 허용하면 값이없고 문제의 가능성 만 열립니다. 즉, 값을 변경하면 문제가 발생하는 경우에만 아마도 하드 코딩되어야 할 것입니다.

당신이 준 예에서, 저는 하드 코딩이 어디에 유용한 지 알 수 없습니다. 당신이 언급 한 모든 것은 제목을 포함하여 이미 데이터베이스에 있어야합니다. 프레젠테이션을 주도하는 요소 (예 : 정렬 순서)도 추가 할 수 있습니다.

댓글

  • 감사합니다. 정렬 순서는 그러나 우리의 경우에는 ‘ 중요하지 않았으며 ‘ 그게 될 수 있다고 생각조차하지 않았습니다. 데이터베이스의 다른 테이블로 추가되었습니다.
  • 이 모든 것을 DB에서 관리하는 것은 하나의 옵션이라는 점에 유의해야합니다. 구성 파일이나 다른 솔루션을 사용할 수도 있지만 하드 코딩은 좋지 않은 선택 인 것 같습니다. 옵션은 ‘ 사용자가 옵션을 관리 할 수있는 인터페이스를 쉽게 만들 수 있기 때문에 자주 사용됩니다. 이 는이 목적을 위해 특별히 설계되었습니다.

답변

다음과 같은 강력한 솔루션 구현 하드 코딩되었을 수있는 값을 최종 사용자의 요구에 따라 구성 할 수 있습니다. 이러한 값에 대한 강력한 검증. 빈 문자열을 넣었습니까? 숫자가되어야하는 곳에 숫자가 아닌 것을 넣었나요? SQL 주입을하고 있습니까? 기타

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

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

답글 남기기

이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다