LabVIEW 프로젝트를 오래 쓰는 사람들의 공통 습관

같은 LabVIEW로 만든 프로젝트인데
어떤 건 몇 년을 버티고,
어떤 건 1~2년 만에 손도 못 대는 상태가 된다.

기술 수준의 차이일까?
꼭 그렇지는 않다.

오래 살아남는 프로젝트를 보면
공통적으로 보이는 건
코딩 실력보다 습관이다.

---

LabVIEW를 오래 쓰는 사람들은
처음부터 거창한 구조를 만들지 않는다.
대신, 망가질 상황을 미리 떠올린다.

---

1) “지금 말고, 나중”을 항상 같이 생각한다

기능을 하나 추가할 때도
이 질문을 먼저 던진다.

• 이 기능이 하나 더 늘어나면?
• 장비가 바뀌면?
• 요구사항이 조금만 달라지면?

지금은 편한 선택이
나중에는 발목을 잡을 수 있다는 걸
경험으로 알고 있다.

그래서 항상
“조금 덜 편한 쪽”을 택한다.

---

2) 구조를 바꾸는 걸 미루지 않는다

오래 쓰는 사람들은
구조가 불편해지기 시작하는 시점을 안다.

• VI 설명이 길어질 때
• 수정 하나가 두세 군데를 건드릴 때
• “이거 건들면 무섭다”는 말이 나올 때

이 신호를 느끼면
기능 추가보다 구조 정리를 먼저 한다.

리팩토링은
시간이 남아서 하는 게 아니라
시간을 벌기 위해 하는 거라는 걸 안다.

---

3) 장비 의존 코드를 반드시 분리한다

장비가 바뀌지 않을 거라는 가정은
항상 틀린다.

오래 쓰는 프로젝트일수록

• 통신
• 초기화
• 타이밍
• 에러 특성

이 부분을 한 덩어리로 묶어둔다.

그래야
장비가 바뀌어도
전체 프로젝트를 다시 보지 않아도 된다.

---

4) 설명할 수 없는 구조는 만들지 않는다

오래 쓰는 사람들은
자기 코드에 대해 이런 질문을 스스로 던진다.

“이 구조를 말로 설명할 수 있는가?”

• 왜 이 VI가 여기 있는지
• 왜 이 데이터가 이 경로로 흐르는지
• 왜 이 타이밍에 이 판단을 하는지

설명할 수 없다면
그 구조는 아직 완성되지 않은 상태다.

LabVIEW는
보여주기 쉬운 만큼
설명하기 어려운 구조도 쉽게 만들어진다.

---

5) 문서보다 ‘의도’를 남긴다

모든 걸 문서로 남기지는 않는다.
대신 중요한 선택에는
의도를 남긴다.

• 왜 이 방식을 택했는지
• 어떤 대안을 버렸는지
• 어디까지를 가정했는지

이 한 줄이
몇 달 뒤의 자신이나
다른 개발자를 살린다.

---

LabVIEW를 오래 쓰는 사람들은
툴을 믿기보다
자기 선택을 더 믿는다.

• 구조를 의심하고
• 편의를 경계하고
• 나중을 먼저 생각한다

그래서 프로젝트도 오래 산다.

이제 LabVIEW 이야기는
여기서 한 번 끊는다.

다음부터는
조금 더 낮은 레벨,
조금 더 날것의 세계로 내려가 보려 한다.

같은 실수가
왜 C에서는 더 크게 터지는지.

그 이야기는
다음 축에서 이어간다.