단일 스레드, 비OS, 임베디드 애플리케이션에서 글로벌 변수가 무엇입니까?
글로벌 변수를 사용하는 것에 대한 대부분의 반대 의견은 여러 스레드, 스레드 안전 등의 문제를 언급하기 때문에 타당합니다.
하지만 OS가 아닌 소규모의 단일 스레드 사례에서는 어떤 반대 의견이 있습니까?저의 경우, 저는 "C"에 내장된 시스템을 쓰고 있습니다.저도 그 제품의 유일한 개발자입니다.
글로벌 변수를 제거하면 코드가 더 좋아지는 이유는 무엇입니까?
(여러 응답을 읽은 후 이 시스템에는 동적 메모리 할당(예: malloc)이 없다는 점도 지적했어야 했습니다.모든 메모리는 컴파일 시 정적으로 할당됩니다.)
그럴 리가 없어요.
글로벌 변수와 관련된 두 가지 근본적인 문제는 네임스페이스를 혼란스럽게 하는 것이며, "아무도" 이 변수를 제어할 수 없다는 사실입니다(따라서 잠재적 충돌 및 여러 스레드와의 충돌).
"글로벌은 나쁘다"는 것은 다른 거의 모든 컴퓨터 프로그래밍 관용구와 마찬가지로 지침이지 어렵고 빠른 규칙이 아닙니다.이런 종류의 "규칙"이 만들어질 때, 규칙을 단순히 암기하여 규칙을 채택하는 것보다 규칙을 만드는 배경과 동기를 이해하는 것이 가장 좋습니다.그들을 맹목적으로 받아들이지 마세요.
당신의 경우, 당신은 당신의 시스템의 특성과 규칙 주위의 주장을 이해하는 것처럼 보이며 이 경우에는 적용되지 않는다고 결정했습니다.당신 말이 맞아요, 그렇지 않아요.
그러니 걱정하지 마세요.
매크로가 반드시 나쁜 것은 아니며 농축 우라늄이 반드시 나쁜 것은 아닌 것과 마찬가지로 글로벌 변수도 반드시 나쁜 것은 아닙니다.주어진 설계 선택의 장단점에 대해 의식적인 결정을 내리는 한, 여러분은 괜찮을 것입니다.
글로벌 변수에 대한 인수 중 일부는 다음과 같습니다.
- 좋은 객체 지향 설계를 위반합니다.
- 코드가 볼 것으로 예상되는 모든 글로벌 변수를 설정하지 않고는 개별 코드 블록을 테스트할 수 없기 때문에 코드를 단위 테스트하기가 어렵습니다.
- 코드의 결합을 증가시킵니다. 한 코드 블록의 작업은 공유 글로벌 변수를 통해 다른 코드 블록의 작업에 예측할 수 없는 방식으로 영향을 미칠 수 있습니다.
글로벌 변수 인수 중 일부는 다음과 같습니다.
- 여러 기능 간에 단일 리소스를 쉽게 공유할 수 있습니다.
- 코드를 읽기 쉽게 만들 수 있습니다.
설계에서 글로벌 변수가 의미가 있고 임의 오류 및 두통 테스트 없이 코드를 더 쉽게 읽거나 유지 관리할 수 있도록 하는 데 사용할 수 있다면 모든 방법으로 변수를 사용하십시오.
저는 임베디드 마이크로컨트롤러용 C 코드를 많이 작성하고, 항상 글로벌 변수를 사용합니다.이러한 경직된 시스템에서 글로벌 변수는 의미가 있습니다.저는 잠재적인 단점을 알고 있지만, 장점과 단점을 분석하고 주요 단점을 방지하기 위해 코드를 작성합니다.
결론:엄격하고 빠른 규칙은 없습니다.보유하고 있는 최상의 정보를 기반으로 특정 프로젝트 또는 플랫폼에 대한 최상의 결정을 내리십시오.
여기 글로벌 변수가 나쁜 이유를 설명하는 좋은 기사가 있습니다.
글로벌 변수가 불필요할 때 피해야 하는 이유는 무엇입니까?
비국소성 - 소스 코드는 개별 요소의 범위가 제한될 때 가장 쉽게 이해할 수 있습니다.전역 변수는 프로그램의 모든 부분에서 읽거나 수정될 수 있으므로 가능한 모든 사용에 대해 기억하거나 추론하기 어렵습니다.접근 제어 또는 제약 조건 검사 없음 - 전역 변수는 프로그램의 모든 부분에서 가져오거나 설정할 수 있으며, 사용과 관련된 모든 규칙은 쉽게 깨지거나 잊혀질 수 있습니다.
암묵적 결합 -- 많은 전역 변수가 있는 프로그램은 종종 그러한 변수 중 일부 사이에 긴밀한 결합을 하고 변수와 함수 사이에 결합을 합니다.결합된 항목을 응집력 있는 단위로 그룹화하면 일반적으로 더 나은 프로그램을 만들 수 있습니다.
메모리 할당 문제 - 일부 환경에는 전역 할당을 까다롭게 만드는 메모리 할당 체계가 있습니다.특히 "생성자"가 할당 이외의 부작용을 갖는 언어에서는 더욱 그렇습니다(이 경우 두 전역이 서로 의존하는 안전하지 않은 상황을 표현할 수 있기 때문입니다).또한 모듈을 동적으로 연결할 때 다른 라이브러리에 자체 글로벌 인스턴스가 있는지 또는 글로벌이 공유되는지 여부가 불분명할 수 있습니다.
테스트 및 제한 - 글로벌을 활용하는 소스는 실행 간에 '깨끗한' 환경을 쉽게 설정할 수 없기 때문에 테스트하기가 다소 어렵습니다.더 일반적으로, 해당 소스에 명시적으로 제공되지 않는 모든 종류의 글로벌 서비스를 활용하는 소스는 동일한 이유로 테스트하기 어렵습니다.
글로벌을 추가하는 것은 정말 쉽습니다.그것들을 선언하는 습관이 드는 것은 쉽습니다.그것은 좋은 디자인을 생각하는 것보다 훨씬 빠릅니다.
글로벌 변수는 여러분이 생각하는 것만큼 나쁘지 않습니다. 불필요할 때마다 피해야 합니다.전역 변수는 프로그램 전체에서 사용되는 변수에 유용하게 사용될 수 있으므로 항상 변수가 변경되는 위치를 추적해야 합니다. 그러나 프로그램의 제한된 부분 내에서만 사용되는 경향이 있는 변수의 경우 전역 변수를 사용하지 않는 것이 좋습니다.
커플링을 최소화하기 때문입니다.지금은 시스템이 작을 수 있지만 계속 작업하면 그렇지 않을 수 있습니다.
글로벌 변수는 C로 작성된 작은 임베디드 응용 프로그램에 필요합니다.예를 들어 인터럽트 서비스 루틴과 다른 모듈 간에 정보를 전달하려면 글로벌 변수를 사용해야 합니다.다음은 임베디드 응용프로그램에서 글로벌 변수를 효과적으로 사용하는 데 도움이 되는 몇 가지 팁입니다.
정적 변수와 전역 변수를 구분합니다.정적 변수는 동일한 C 파일의 모든 함수에서 사용할 수 있습니다.이들은 C++ 클래스의 개인 구성원에 해당합니다.C에서 당신은 컴파일러의 일을 직접 해야 합니다.모듈 외부에서 변수를 실수로 사용하지 않도록 하고 범위를 명확하게 표시하려면 static 키워드를 사용합니다.변수 앞에 모듈 이름을 붙일 수 있습니다.
글로벌 변수(많은 C 파일에서 사용)에 대한 명명 규칙을 따릅니다.그들이 전세계적이라는 것을 분명히 하라.
글로벌 변수가 많이 필요한 경우 구조로 묶는 것을 고려하십시오.
필요한 경우 volatile 키워드를 사용합니다.이는 전역 변수가 ISR에 의해 수정되는 경우에 필요합니다.
글로벌 변수를 사용하는 코드는 유지하기가 더 어렵습니다.유지 관리자는 변수가 무엇을 하는지 정확하게 알기 전에 시스템에서 변수의 모든 용도를 찾아야 하기 때문입니다.유지 관리 속도가 느려지므로 가능한 한 피해야 합니다.바로 그거야
그것은 범위의 문제입니다.로컬 개념을 수행하기 위해 글로벌 변수를 만드는 것을 좋아하는 개발자들이 있습니다.따라서 이러한 변수의 사용을 추적하기가 훨씬 어려워지므로 변수의 사용에서 실수를 범하기가 더 쉽습니다.
지갑을 현관에 보관할 수도 있지만, 누가 지갑에 접근하는지에 대한 통제력은 훨씬 떨어집니다.
글로벌 변수에 대한 몇 가지 유효한 사용법이 있지만, 따를 가치가 있는 다른 규칙과 마찬가지로 그렇습니다.이것은 일반적인 경우가 아닌 예외입니다.그들의 가장 기존의 지적은 그들이 쓸모가 있다는 것을 지적합니다.
전역 변수를 사용하기로 결정한 경우에는 해당 변수에 대해 설명을 잘 하고 좋은 이름을 지정합니다.사람들이 "boolbIsFound;"와 같은 글로벌 변수를 만들 때 정말 신경이 쓰입니다.
우리는 코드 검토에서 각각의 새로운 글로벌 변수를 평가하고 더 나은 접근 방식이 있는지 확인하는 것을 강조합니다.
짧은 대답은 글로벌 변수가 역사적으로 미묘한 버그의 원인이었다는 것입니다.하지만 (내 기능적인 프로그래머 모자를 쓰고) 모든 변수는 미묘한 버그의 원인이 되었습니다.
기본적으로 글로벌 변수는 변수의 값을 사용하여 코드 조각을 볼 수 없고 변수의 값이 과거에 수행한 다른 코드 조각이 무엇인지 알지 못하면 코드 조각이 무엇을 수행할지 알 수 없다는 것을 의미합니다.
아마도 글로벌 변수는 당신의 경우 나쁘지 않을 것입니다.반면에, 당신은 그것들이 필요합니까?그것들을 사용함으로써 당신은 무엇을 얻습니까?
이러한 경우에도 글로벌 변수로 인해 응용 프로그램의 상태를 파악하기가 더 어려워집니다.디버깅을 방해할 수 있으며 미묘한 버그가 발생할 수 있습니다.
글로벌 변수는 또한 테스트를 더 어렵게 만듭니다.테스트 중에 사용자가 피해야 할 외부 코드에 대한 종속성이 추가됩니다.
그러나 마지막으로, C에서 프로그래밍할 때 글로벌은 피하기 어렵습니다.더 발전된 언어에서, 글로벌은 단순히 대부분의 시간에 무의미합니다.그것들을 사용하는 것은 당신의 코드를 더 명확하게 만들지 못합니다.
C에서, 글로벌이 최고이고, 단순하고, 가장 깨끗한 솔루션인 경우가 많습니다.
따라서 여러분의 경우에는 사례별로 살펴봅니다.아마도 글로벌하게 변하게 될 것입니다. 하지만 변수를 글로벌하게 만들지 마십시오. 지금 뿐만 아니라 코드를 디버그하거나 응용프로그램을 멀티스레드로 만들어야 하는 지금으로부터 1년 후가 가장 좋은 해결책이라고 확신하지 않는 한 말입니다.
글로벌 변수의 경우 변수가 업데이트되는 위치와 시기, 그리고 해당 변수를 업데이트하는 코드 조각을 파악하기가 어려운 경우가 많습니다.누가 업데이트할 수 있는지 또는 변수가 업데이트되는 방식은 제어할 수 없습니다.
응용 프로그램이 작은 경우 추적하는 것은 그리 어렵지 않습니다. 그러나 응용 프로그램이 커지면 커질수록 글로벌 변수가 많을수록 응용 프로그램 코드가 스파게티처럼 보입니다.
간단히 말해서, 유지보수 및 디버깅 악몽이 됩니다.
문제는 마지막 코드의 어떤 비트가 글로벌 상태를 수정했는지 추적하는 것입니다.일반적으로 변수에 대해 더 쉽게 추론할 수 있도록 변수를 가능한 한 작은 범위 내에 유지하려고 합니다.
대부분의 변수를 로컬로 유지하고 범위를 줄이는 것은 더 나은 프로그래밍 방법을 촉진하는 데 도움이 됩니다.또한 변수를 실수로 변경하고 의도하지 않거나 명백하지 않은 결과를 찾기 위해 함수를 추적해야 하는 위험을 줄입니다.코드의 특정 섹션과 관련된 대부분의 변수가 근처에서 정의되고 초기화되기 때문에 코드를 읽고 유지하는 것이 더 쉬워진다고 생각합니다.그렇지 않으면 저는 계속해서 모든 골볼을 정의하는 코드 섹션을 다시 참조하는 것 같습니다.일부 글로벌을 사용하지만, 주로 하위 모듈에 구성 정보를 전달합니다.
생각나는 한 가지 이유는 미래 증명입니다.당신은 지금 당신의 제품에 대한 유일한 개발자일 수 있지만, 다른 사람들이 나중에 그것을 유지할 것이라고 생각할 수 있습니다.물론 특정한 경우에는 그렇지 않을 수도 있습니다.
여러분의 제품이 지금 당장은 작고 깔끔할 수도 있지만, 글로벌 변수를 사용한다고 해서 전체적인 디자인이나 가독성이 복잡해지지는 않을 것입니다. 누가 제품이 더 커지거나 다른 제품에 통합되지 않을 것이라고 말할 수 있겠습니까?그리고 다른 관리자/개발자가 글로벌 변수의 사용을 분류하는 것을 금지합니다.
물론 글로벌 변수를 사용하기로 결정할 수도 있고 프로젝트가 점점 복잡해지는 것처럼 보일 때 다시 돌아가서 일부를 다시 작성할 수도 있습니다. 하지만 왜 추가 작업을 스스로에게 강요합니까?여러분은 (글로벌 대표팀을 기억한다면) 그 일을 하는 것이 너무 많은 노력이라고 결정하고 디자인을 포기할 가능성이 더 높습니다. 이 시점에서 여러분은 곤경에 처해 있습니다!
따라서, 여러분 자신의 두통을 줄이고 미래를 내다보는 눈으로 디자인하십시오.지금 필요한 일은 아마도 미래의 삶을 더 편하게 해줄 것입니다.
만약 그것이 당신을 납득시키지 못했다면, 이 프로젝트를 수행한 개발자들이 되고 그들의 코드가 대법원 앞에서 잘못된 프로그래밍 관행으로 유죄 판결을 받았다고 상상해 보세요: 버기 음주 측정기 코드는 소스 검토의 중요성을 반영합니다.
언급URL : https://stackoverflow.com/questions/872943/why-are-global-variables-bad-in-a-single-threaded-non-os-embedded-application
'programing' 카테고리의 다른 글
Enum에서 문자열을 검색하고 Enum을 반환합니다. (0) | 2023.07.31 |
---|---|
파일이 없는 경우 파일 만들기 (0) | 2023.07.31 |
memcpy 구현을 제공하는 방법 (0) | 2023.07.31 |
아약스 요청에서 X-Requested-With 헤더를 제거할 수 있습니까? (0) | 2023.07.31 |
Spring JPA로 소프트 삭제 처리 (0) | 2023.07.31 |