개발을 하거나, 코딩 테스트 문제를 풀다보면
컴파일러 환경에 따라서 표준이 어떻다는 얘기가 나온다.
예를 들어, GCC환경에선 가능한 것이 MSVC환경에선 불가능한 코드가 있다.
그만큼, 표준이라는 것은 정말 중요하다.
A-SPICE / ISO 26262 / MISRA-C 등에서도
차량전장SW 분야의 직/간접적인 코드 표준을 제시하고 있다.
준수하지 않으면 당연히 품질이 망가진다.
제조업은 품질이 1등이다. 절대 잊어선 안되는 사실이다.
서비스SW의 경우 얼렁뚱땅 사용자 환경이 좋지 못하다.(특히나 게임 분야) 등으로 넘어가는 케이스가 많지만, 제조업SW의 경우 제품 자체가 환경이고 그것을 파는 것이니까
-
전역 변수 최대한 사용하지 않기 :
어디에 해당 변수가 선언되었는지 알기 힘들어지기 때문에 코드 가독성이 저하된다. 변수 수정 시 어느 지점에서 값이 변경되었는지 파악하기가 힘들어진다. 변수 이름이 겹치거나 의도치 않게 덮어쓰기가 발생할 수 있다.
또한, 결합도 측면에서 문제가 발생한다. 전역 변수라서 모듈간 같이 접근한다면? 의도치 않은 동작(오동작)으로 이어진다.
도요타 Recall 사태를 생각해보면... 전역 변수 남발이 품질을 낮추고 결국 안전문제까지 발생해 사용자는 피해를 입고, 회사는 큰 금전적 타격을 입게 되었다. -
매직 넘버 사용하지 않기 : 매직 넘버는 유지보수에 있어 추후 어떤의도로 값을 사용했는지 확인하기 어렵기 때문이다. (하드 코딩해서 쓰지말자.)
실제로 나도 프로젝트 당시에 센서를 직접 측정해서 하드코드로 몇 이상/이하 등의 분기문으로 제어 로직을 만들곤 했었다. 아주 좋지 못한 습관이다. -
조건문은 항상 명시적으로 비교 연산을 사용하기:
특히 C언어에서는 0이 아니면 모두 true로 간주되기 때문에, 예상치 못한 값도 true 처리될 수 있으니 명확한 비교로 방지하는 것이 좋다.
나쁜 예: if (flag) ...
좋은 예: if (flag == true) …
-
분기점(Branch Point)을 최소화하기 :
복잡한 조건문이나 불필요한 분기점은 코드의 흐름을 이해하기 어렵게 만들고, 디버깅이나 테스트 시 예상치 못한 흐름을 유발할 수 있다. 또한 CPU의 분기 예측 실패(branch misprediction)로 성능 저하가 발생할 수 있다. -
코드 리뷰 문화 정착 :
자동화 도구가 잡아내지 못하는 구조적 문제나 로직의 복잡성 개선,
서로의 코드를 보며 표준을 학습하고 품질에 대한 책임감을 공유 -
묵시적 형변환 자제(코드 가독성 저하되고, 데이터 손실 가능)
-
코드 재사용 시 새로운 환경에 맞는 검증과 수정하기
(아리안 4호에서 사용되던 소프트웨어를 아리안 5호에 재사용하면서 오버플로우 문제로 터진 사건과 같은 상황 방지 위해서)
실제로 작업 산출물은 모두 재사용 대상이다.
하지만 면밀히 확인하지 않고 시스템이 바뀌었는데 그대로 재사용한다면?
품질 저하/오동작 기타 등등 잠재적 리스크 혹은 Issue가 발생할 수 있다.
몇가지 예시만을 들었지만, A-SPICE / ISO 26262 / MISRA-C 문서들을 참고하면서,
표준을 지키기 위한 마인드와 실제 연습이 필요하다.
LOC가 긴 코드를 짠 경험이 없고, 혼자 개발하는 경우에는 전역변수 사용이나 분기 반복구조의 사용을 본인은 이해하겠지만...
실제론 LOC도 길고, 서로 나눠서 개발하고 통합하고 테스트하게 된다...
모두가 표준을 지켜야 고품질을 유지하면서, 안전한 제품을 생산해 낼 수 있다.
