완전히 진지한 반대 질문을하겠습니다. "데이터"와 "코드"의 차이점은 무엇입니까?
"data"라는 단어가 들리면 "state"라고 생각합니다. 정의에 따르면 데이터는 응용 프로그램 자체가 관리하도록 설계된 것이므로 컴파일 타임에 응용 프로그램이 알 수없는 것입니다. 그것은하지 않습니다 수 없는 데이터 - 때문에 곧, 그것은 행동이된다 당신이 하드 코드로 하드 코드 데이터.
데이터 유형은 응용 프로그램에 따라 다릅니다. 상업용 송장 시스템은 고객 및 주문 정보를 SQL 데이터베이스에 저장할 수 있으며 벡터 그래픽 프로그램은 형상 데이터 및 메타 데이터를 이진 파일에 저장할 수 있습니다. 이 두 경우와 그 사이의 모든 상황에서 코드와 데이터가 명확하고 깨지지 않습니다. 데이터는 프로그래머가 아닌 사용자 에게 속하므로 하드 코딩 할 수 없습니다.
당신이 말하고있는 것은 나의 현재 어휘에서 사용 가능한 가장 기술적으로 정확한 설명을 사용하는 것입니다 : 대부분의 응용 프로그램을 개발하는 데 사용되는 기본 프로그래밍 언어로 작성되지 않은 프로그램 동작을 통제하는 정보.
"data"라는 단어보다 애매 모호한이 정의조차도 몇 가지 문제가 있습니다. 예를 들어, 프로그램의 중요한 부분이 각각 다른 언어로 작성된 경우 어떻게됩니까? 저는 개인적으로 약 50 % C # 및 50 % JavaScript 인 여러 프로젝트를 수행했습니다. JavaScript 코드는 "데이터"입니까? 대부분의 사람들은 거절합니다. HTML은 어떻습니까? "데이터"입니까? 대부분의 사람들은 여전히 거절합니다.
CSS는 어떻습니까? 그 데이터 또는 코드입니까? 코드를 프로그램 동작을 제어하는 것으로 생각하면 CSS는 실제로 코드가 아닙니다. 왜냐하면 CSS는 동작이 아니라 모양에만 영향을 미치기 때문입니다. 그러나 실제로 데이터도 아닙니다. 사용자는 그것을 소유하지 않으며, 응용 프로그램은 그것을 소유하지도 않습니다. UI 디자이너의 코드와 동일합니다. 코드 와 비슷 하지만 코드 는 아닙니다.
CSS를 일종의 구성이라고 부를 수 있지만 좀 더 실용적인 정의는 단순히 도메인 특정 언어로 코드화된다는 것입니다 . XML, YAML 및 기타 "형식화 된 파일"이 종종 나타내는 것입니다. 또한 도메인 별 언어를 사용하는 이유는 일반적으로 C 또는 C # 또는 Java와 같은 범용 프로그래밍 언어로 동일한 정보를 코딩하는 것보다 특정 도메인에서 동시에 더 간결하고 표현력이 뛰어 나기 때문입니다.
다음 형식을 인식합니까?
{
name: 'Jane Doe',
age: 27,
interests: ['cats', 'shoes']
}
나는 대부분의 사람들이 그렇게 확신합니다. 그건 JSON . JSON에 대한 흥미로운 점은 다음과 같습니다. JavaScript에서는 코드 가 명확 하고 다른 모든 언어에서는 데이터 형식 이 명확 합니다. 거의 모든 주류 프로그래밍 언어에는 JSON "구문 분석"을위한 라이브러리가 하나 이상 있습니다.
JavaScript 파일의 함수 내에서 똑같은 구문을 사용하면 코드 이외의 다른 것이 될 수 없습니다. 그러나 JSON을 가져 와서 .json파일로 가져 와서 Java 애플리케이션에서 구문 분석하면 갑자기 "데이터"입니다. 정말 말이 되나요?
나는 "데이터-성"또는 "구성-성"또는 "코드-성"이 기술 된 방식 이 아니라 기술 된 것에 고유 한 것이라고 주장한다 .
임의의 암호를 생성하기 위해 프로그램에 백만 단어의 사전이 필요한 경우 다음과 같이 코드를 작성 하시겠습니까?
var words = new List<string>();
words.Add("aa");
words.Add("aah");
words.Add("ahhed");
// snip 172836 more lines
words.Add("zyzzyva");
words.Add("zyzzyvas");
아니면 모든 단어를 줄로 구분 된 텍스트 파일로 넣고 프로그램에서 읽도록 지시합니까? 단어 목록이 절대 바뀌지 않는 것은 중요하지 않습니다. 하드 코딩인지 소프트 코딩인지 (많은 사람들이 부적절하게 적용 할 때 반 패턴으로 간주되는) 문제인지는 문제가되지 않습니다. 어떤 형식이 가장 효율적이며 "물건"이 무엇이든 "물건"을 설명하기가 가장 쉽습니다. 코드 또는 데이터라고 부르는 것은 상당히 관련이 없습니다. 프로그램 실행에 필요한 정보이며 플랫 파일 형식이 가장 편리하게 관리하고 유지 관리하는 방법입니다.
적절한 관행을 따르고 있다고 가정하면,이 모든 것이 어쨌든 소스 제어에 들어가므로, 코드를 호출 할 수도 있습니다. 또는 구성이라고 할 수 있지만 구성과 코드를 구별하는 유일한 방법은 코드를 문서화하고 최종 사용자에게 변경 방법을 알려주는 것입니다. 컴파일 타임이 아닌 시작 시간이나 런타임에 구성이 해석되는 것에 대한 가짜 주장을 발명 할 수는 있지만 동적으로 유형이 지정된 여러 언어와 그 안에 스크립트 엔진이 내장 된 거의 모든 것을 설명하기 시작합니다 (예 : 대부분의 게임). 코드와 구성은 더 이상 아무것도 아닌 것으로 라벨을 붙이기로 결정한 모든 것입니다.
이제이 있습니다 에 위험 외부화 실제로 수정하는 것이 안전하지 않습니다 정보 (위의 "소프트 코딩"링크를 참조). 모음 파일을 구성 파일로 외부화하고이를 최종 사용자에게 구성 파일로 문서화하는 경우, "q"를 모음으로 지정하여 앱을 즉시 중단 할 수있는 거의 완벽한 방법을 제공합니다. 그러나 이것이 "코드와 데이터의 분리"의 근본적인 문제는 아니며 단순히 디자인 감각이 나쁘다는 것입니다.
주니어 개발자들에게 환경에 따라 변경 될 것으로 예상되는 설정을 항상 외부화해야한다는 것입니다. 여기에는 연결 문자열, 사용자 이름, API 키, 디렉토리 경로 등이 포함됩니다. 그들은 당신의 dev 상자와 프로덕션에서 동일 할 수도 있지만 아마도 아닐 수도 있습니다 .sysadmins는 dev가 아닌 프로덕션에서 어떻게 보일지 결정할 것입니다. 따라서 일부 컴퓨터에는 하나의 설정 그룹을 적용하고 다른 컴퓨터에는 다른 설정을 적용 할 수있는 방법이 필요합니다 (ergo, 외부 구성 파일 (또는 데이터베이스의 설정 등)).
그러나 단순히 "데이터"를 "파일"에 넣는 것은 구성으로 외부화하는 것과 같지 않다고 강조합니다. 단어 사전을 텍스트 파일에 넣었다고해서 사용자 (또는 IT)가 변경하기 를 원한다는 의미는 아닙니다. 개발자 가 지옥에서 무슨 일이 일어나고 있는지 이해하고 필요한 경우 더 쉽게 이해할 수 있도록하는 방법 일뿐입니다. 가끔 변경됩니다. 마찬가지로, 테이블이 읽기 전용이고 DBA가 절대로 나사를 쓰지 말라고 지시 한 경우, 데이터베이스 테이블에 동일한 정보를 넣는 것이 반드시 행동의 외부화로 간주되지는 않습니다. 구성은 데이터가 변경 가능하지만 실제로는 형식 선택이 아닌 프로세스 및 책임에 의해 결정됨을 의미합니다.
요약하면 다음과 같습니다.
"코드"는 엄격하게 정의 된 용어가 아닙니다. 정의를 확장하여 도메인 별 언어 및 동작에 영향을 미치는 다른 요소를 포함 시키면 이러한 명백한 마찰이 사라지고 모든 것이 의미가 있습니다. 플랫 파일에 컴파일되지 않은 DSL "코드"가있을 수 있습니다.
"데이터"는 사용자 나 개발자 이외의 다른 사람이 소유하고 일반적으로 디자인 타임에 사용할 수없는 정보를 의미합니다. 원하는 경우에도 하드 코딩 할 수 없습니다. 자체 수정 코드를 제외하고 코드와 데이터를 구분하는 것은 개인적인 취향이 아니라 정의의 문제입니다.
"소프트 코딩"은 과도하게 적용되는 경우 끔찍한 관행 일 수 있지만 모든 외부화 인스턴스가 반드시 소프트 코딩을 구성하는 것은 아니며 "플랫 파일"에 정보를 저장하는 많은 인스턴스가 반드시 외부화의 선의의 시도는 아닙니다.
구성은 소프트 코딩 즉의 특별한 유형 입니다 때문에 응용 프로그램이 다른 환경에서 실행해야 할 수도있는 지식이 필요. 응용 프로그램과 함께 별도의 구성 파일을 배포하면 모든 환경에 다른 버전의 코드를 배포하는 것보다 작업이 훨씬 적고 덜 위험합니다. 따라서 일부 유형의 소프트 코딩이 실제로 유용합니다.