제퍼넷 로고

의료 기기 소프트웨어 개선을 위한 3가지 Git 팁

시간

힘내 팁 의료 기기의료기기 소프트웨어는 매우 다양합니다. 낮은 수준의 펌웨어 드라이버부터 데이터 분석 및 AI, 웹 개발 및 사이버 보안에 이르기까지 기술은 다양하며 각각 고유한 특징이 있습니다.
이 모든 다양성 중에서 유비쿼터스적인 기술은 바로 Git입니다! 버전 제어 시스템(VCS)은 항상 존재하며 이를 실제로 알아가는 데 약간의 시간을 투자할 가치가 있습니다. 기본 사항을 넘어서면 Git을 사용하면 추적성을 희생하지 않고도 의료 기기 소프트웨어를 더 빠르게 개발할 수 있습니다.

의료 기기 소프트웨어에는 일반적인 소프트웨어 모범 사례를 넘어서는 추가 책임 계층이 필요합니다. 한 가지 예는 구성 관리 및 소프트웨어 버전 간 변경 사항에 대한 기록 유지와 관련이 있으며, 이는 소프트웨어 개발의 명확한 기록을 유지하는 것을 의미합니다.

Git을 최대한 활용하려면 Git이 어떻게 작동하는지에 대한 자신만의 정신적 모델을 만드는 데 약간의 시간을 투자해야 합니다. Git을 더 잘 사용하는 데 도움이 되는 놀라운 세 가지 깨달음을 살펴보겠습니다.

  1. 모든 것을 커밋할 필요는 없습니다!

최상의 상태에서는 Git이 방해가 되지 않습니다. 프로그래머로서 내가 원하는 곳은 "코드 모드"입니다. 여기서는 새로운 기능을 해킹하거나 버그를 수정하거나 둘 다 수행하는 데 시간이 걸리는 것을 잊어버립니다. 여기에는 코드를 작성하는 것과 향후 리뷰어를 위한 합리적인 기록을 구축하는 것 사이에 긴장감이 있습니다. 내가 마지막으로 하고 싶은 일은 프로그래밍을 중단하고 VCS에 대해 생각하고 변경 사항이 리뷰어를 찾는 방법에 대해 생각하는 것입니다. 결국 커밋을 작고 독립적으로 만드는 것이 좋습니다.

당신이 프로그래밍에 푹 빠져서 아무것도 커밋하지 않고 관련 없는 몇 가지 변경 사항을 적용했다고 가정해 보겠습니다. 너 뭐하니? Git은 커밋되지 않은 모든 로컬 변경 사항이 있는 "작업 복사본"을 "스테이징 영역"에서 분리합니다. 더하다 커밋하려는 변경 사항.

다음은 SPI 드라이버, 디스플레이 드라이버 및 일부 비즈니스 로직을 사용하여 프로젝트를 작업할 때 준비 영역을 사용하는 방법을 보여주는 예입니다. 아마도 소스는 다음과 같이 구성되어 있을 것입니다.

|– 드라이버/
| |- spi.c
| |- spi.h
| |– 디스플레이.c
| |– 디스플레이.h
|– 앱/
| |– app.c
|– …

SPI 드라이버를 즐겁게 구축했지만 그 과정에서 디스플레이에서 페이지를 보다 원활하게 렌더링하기 위한 아이디어가 생겼습니다. 디스플레이 드라이버에 몇 가지 변경 사항을 추가했으며 이제 spi.c와 display.c 모두에 변경 사항이 적용되었습니다. 한꺼번에 커밋하면("git add .") 관련 없는 변경 사항이 뒤엉켜 git 위생이 좋지 않습니다. 디스플레이 드라이버를 현명하게 사용하려고 노력하는 동안 버그가 발생했다면 어떻게 될까요? 이 패치를 되돌린 다음 SPI에만 관련된 부분을 선택하여 해당 패치가 삭제되는 것을 방지해야 합니다. 형편없어!

대신 Git의 강력한 기능을 사용하세요. 준비 영역 작업 복사본에서 원자적인 변경 사항을 찾아냅니다. SPI와 관련된 변경 사항만 먼저 추가하고 이를 커밋함으로써, 그때 디스플레이 드라이버 변경 사항을 추가하면 훌륭하고 독립적이지만 동일한 작업 복사본에서 나온 두 개의 커밋을 만들었습니다.

git add 드라이버/spi.c
자식 커밋 …
git add 드라이버/display.c
자식 커밋 …

다음 커밋이 무엇인지 생각할 필요가 없다는 점에 주목하세요. 전에 당신은 변경합니다. 대신, 나중에 코딩으로 돌아가서 변경 사항에 대한 커밋을 빌드할 수 있습니다! Git은 프로그래밍에 빠져도 처벌하지 않습니다. 카페인이 가득한 버그 수정 세션 후에 문제를 해결하는 데 도움이 됩니다.

원자적 변경 사항이 개별 파일에 국한되면 독립적인 변경 사항을 다른 커밋으로 티징하는 것이 쉽습니다. 그러나 다음에 적용되는 app.c에 변경 사항이 있으면 어떻게 될까요? SPI 및 디스플레이 변경? 다시 한 번 Git이 이를 다루었습니다.

  1. –patch를 사용하여 개별 변경 사항 추가

준비 영역에 대해 배우는 것도 중요하지만 단일 파일 내에서 새로운 역량의 세계가 열립니다. "git add" 명령에는 "-patch/-p" 옵션이 있어 전달한 파일을 하나씩 살펴보며 커밋에 필요한 것만 가져올 수 있습니다. 추가 사항, 제공된 덩어리 분할, 편집을 통해 직접 라인 선택 등을 통해 매우 구체적인 정보를 얻을 수 있습니다. 커밋을 하나씩 빌드하는 것의 보너스는 변경 사항이 마음 속에 생생하기 때문에 아마도 더 나은 커밋 메시지를 작성할 수 있다는 것입니다.

팁: 사용 "singleKey" 구성 옵션 덩어리 탐색을 더 빠르게 만듭니다(git config –global Interactive.singleKey true). 이것이 작동하려면 Term::ReadKey 모듈이 필요합니다.

“–patch” 옵션은 “add” 외에 더 많은 명령에서 사용할 수 있습니다. 파일에서 특히 수동적이고 공격적인 코멘트 하나를 던지고 싶으십니까? "git 재설정 -패치"! 아니면 나중에 사용할 수 있도록 한두 줄만 보관함에 저장하고 싶으신가요? "git stash -패치"!

  1. 힘내 역사

“역사는 나에게 친절할 것이다. 왜냐하면 나는 역사를 쓸 생각이기 때문이다.”

  • 다음 PR을 여는 당신

이제 원자 커밋을 쉽게 결합할 수 있으므로 Git 기록을 통해 전달하는 스토리의 더 큰 그림을 볼 수 있습니다. 예를 들어, 소프트웨어에 새로운 기능을 적용하는 친숙한 "두 단계 전진, 한 단계 후퇴" 패턴으로 며칠 동안 새로운 기능을 작업해 왔습니다.

코드베이스에 새 모듈을 도입했지만 실수로 다른 곳에 버그가 발생했습니다. 따라서 이 버그를 수정하고 커밋합니다. 변화. 새로운 코드를 도입한 다음 이전에 도입한 버그나 회귀를 수정하는 이러한 패턴은 한동안 계속됩니다. 마지막으로 모든 것을 패치했으며 멋진 새 기능을 "기본" 분기에 다시 병합할 준비가 되었습니다.

아마도 기능 분기는 다음과 비슷할 것입니다.

$ git log –oneline –graph feature_branch
* (feature_branch) 경계 케이스 문제가 수정되었습니다.
* 디스플레이 드라이버를 리팩터링합니다.
* 페이지별 렌더링이 개선되었습니다.
* 디스플레이는 페이지별로 렌더링됩니다.
* (기본) …

이 분기를 병합하면 이 모든 기록도 함께 전달됩니다. 그게 역사야 아무도 신경쓰지 않아. 5년 후에는 프로젝트 이력을 검토할 때 한 커밋에서 도입되어 바로 다음 커밋에서 수정된 버그에 대해 아무도 신경 쓰지 않을 것입니다. 개발 중에 이러한 커밋을 체크포인트로 삼게 되지만 모든 것이 작동하자마자 거기에 어떻게 도달했는지 기억할 필요가 없습니다. 검토자는 기능 이전에서 기능 이후로 프로젝트를 가져오는 최소한의 변경 세트를 보고 싶어하며 그 사이에 몇 가지 중요한 이정표가 있을 수도 있습니다. 그러면 이것을 어떻게 처리합니까? 기능이 100% 작성되어 작동할 때까지 어떤 것이든 커밋할 수 있지만 개발 중간에는 위험한 지점입니다.

Git은 사용자가 커밋 기록을 대화형으로 편집할 수 있도록 하는 "git rebase –interactive"를 통해 다시 한 번 구제에 나섰습니다. 기록에서 커밋을 재정렬, 편집, 삭제 또는 "스쿼시"할 수 있습니다. 대화형 리베이스에 유의하세요. Git 기록을 변경합니다. 그것은 잠재적으로 매우 위험하게 만듭니다. 조심하지 않으면 여기에서 저장소가 심각하게 손상될 수 있습니다.

"dev/*"와 같은 템플릿과 일치하는 브랜치의 개발자에게만 "되감기" 권한을 허용하도록 git 원격 호스트를 설정하는 것이 좋습니다. 이렇게 하면 개발자가 무엇을 하든 메인 브랜치와 기타 중요한 체크포인트가 그대로 유지됩니다. 내 프로젝트에서는 "tmp/*" 및 "dev/*"와 일치하는 분기에서만 "되감기"가 허용됩니다. 변경 사항이 공유 기능 분기 또는 "기본"에 적용되면 기록이 더 이상 변경되지 않습니다! 가능하다면 승인된 풀 요청에서 비롯된 것이 아닌 한 "메인" 브랜치에 대한 푸시를 금지하여 이 아이디어를 논리적인 결론으로 ​​가져가세요.

예제 기능 분기를 다시 살펴보면 다음과 같이 정리 후 기록이 표시됩니다.

$ git rebase –대화형 main..feature_branch
$ git log –oneline –graph feature_branch
* (feature_branch) 디스플레이 드라이버를 리팩터링합니다.
* 디스플레이는 페이지별로 렌더링됩니다.
* (기본) …

두 개의 버그 수정 커밋이 상위 커밋으로 압축되었습니다. 이는 기능 개발 오류로 인한 소음 없이 코드베이스에 도입되는 새로운 기능을 명확하게 보여주는 멋지고 깔끔한 기록을 만듭니다.

신뢰할 수 있는 기록을 유지하는 것은 VCS를 사용하는 이유 중 하나입니다. 구성 관리는 의료 기기 소프트웨어에 대한 IEC 62304의 핵심 요구 사항입니다. 대화형 리베이스를 사용하면 기록을 명확하게 만들고 두 릴리스 사이에서 소프트웨어가 어떻게 진행되었는지 쉽게 확인할 수 있습니다.

결론

명확한 기록을 유지하는 것은 의료 기기 소프트웨어 개발의 중요한 측면입니다. 의료 기기 제품을 위한 흥미롭고 광범위한 기능을 개발할 때 Git의 강력한 스테이징 영역과 대화형 리베이스 기능을 사용하면 빠르게 진행하고 중단을 줄일 수 있습니다.

이미지 : Adobe Stock

리바이 퍼켓은 소프트웨어 엔지니어 스타피쉬 메디컬에서 전기공학 학위를 취득한 그는 전자공학과 고품질 임베디드 소프트웨어 간의 격차를 해소합니다. Levi는 모든 수준의 의료 기기 소프트웨어에서 일하며 기업이 새로운 의료 기기를 위한 효과적이고 혁신적이며 안전한 소프트웨어를 개발하도록 돕습니다.



이 공유…

spot_img

최신 인텔리전스

spot_img