"핀 맵이 다 바뀌었대요!" 라는 청천벽력 같은 소식에도 웃으며 대처하는 법.
HAL_GPIO_WritePin을 직접 쓰는 습관을 버리고, OCP 원칙을 적용한 클린 코드 작성법 3가지를 정리했습니다.
솔직히 말해서, 프로젝트 초반에 짠 코드가 마지막까지 그대로 가는 경우는 거의 없습니다. 핀이 부족해서 다른 칩으로 기능을 넘기거나, 단가 문제로 MCU 기종이 바뀌기도 하죠. 😭 이때 '찾기 및 바꾸기'로 대응하는 건 하수입니다. 고수들은 애초에 하드웨어가 바뀔 것을 대비해서 '벽'을 세웁니다. 오늘은 그 벽을 세우는 실전 팁을 공유할게요.
꿀팁 1. main.c에서 HAL_ 함수를 완전히 퇴출시키세요 🚫
가장 먼저 할 일은 main.c 파일 상단에서 stm32f4xx_hal.h를 포함하지 않아도 되게 만드는 것입니다. main.c가 HAL의 존재를 아는 순간, 이미 의존성이 생겨버린 겁니다. 대신 여러분이 만든 driver_led.h 같은 전용 헤더만 보게 하세요.
📌 실전 체크리스트
-
- LED 상태를 바꿀 때 함수 하나로 끝나는가? (예:
-
main.c에 HAL_GPIO_... 코드가 있는가? (있다면 즉시 래핑 필요)- LED 상태를 바꿀 때 함수 하나로 끝나는가? (예:
Update_LED_Status(ERR))
꿀팁 2. OCP 원칙: 수정에는 닫고 확장에는 열어라 🔓
이게 무슨 말일까요? Open-Closed Principle은 펌웨어에서 특히 중요합니다. LED 제어 방식이 MCU 직접 제어에서 I2C Expander로 확장(Open)되어도, 메인 루프의 비즈니스 로직 수정은 최소화(Closed)해야 한다는 뜻입니다.
변경에 강한 설계 (OCP 적용)
- 단계 1:
Led_SetState(LED_OFF)함수 정의 - 단계 2:
led.c내부에서HAL_GPIO_WritePin호출 - 단계 3: 하드웨어 변경 시
led.c내부만 I2C 통신 코드로 수정
꿀팁 3. 유지보수 비용을 미리 계산해 보세요 💰
추상화를 하는 데는 분명 시간이 더 듭니다. 하지만 하드웨어가 한 번이라도 바뀌는 순간, 이 투자는 수십 배의 보상으로 돌아옵니다. 시니어들이 괜히 고집스럽게 구조를 짜는 게 아니랍니다.
🔢 추상화 이득 계산기
수정해야 할 포인트 개수: 개
자주 묻는 질문 ❓
Q: 코드 양이 많아져서 메모리를 더 차지하지 않나요?
A: 함수 한두 개 더 생기는 것은 수십 바이트 수준입니다. STM32F4 같은 환경에서는 전혀 문제 되지 않는 미미한 양입니다.
Q: 다른 개발자들이 이 구조를 싫어하면 어쩌죠?
A: 왜 이렇게 짰는지 '요구사항 변경' 시나리오를 들어 설득해 보세요. 좋은 설계의 가치를 아는 동료라면 반드시 동의할 겁니다.
기술적인 정답은 프로젝트 상황에 따라 다를 수 있지만, '나중에 고생하지 않는 코드'를 지향하는 마음가짐은 모두에게 필요합니다. 여러분의 코드가 하드웨어에 휘둘리지 않고 당당하게 독립할 수 있도록, 오늘 배운 팁들을 꼭 실전에서 써먹어 보시길 바랍니다! 😊

