과학 소프트웨어를위한 지속적인 통합

저는 소프트웨어 엔지니어가 아닙니다. 저는 지구과학 분야의 박사 과정 학생입니다.

거의 2 년 전에 저는 과학 소프트웨어를 프로그래밍하기 시작했습니다. CI (Continuous Integration)를 사용한 적이 없었습니다. 주로 처음에는 그것이 존재하는지 몰랐고이 소프트웨어를 작업하는 유일한 사람이었습니다.

이제 소프트웨어의 기반이 실행되고 있기 때문에 다른 사람들이 소프트웨어에 관심을 갖기 시작하고 소프트웨어에 기여하기를 원합니다. 계획은 다른 대학의 다른 사람들이 핵심 소프트웨어에 추가 기능을 구현하는 것입니다. (버그가 생길 우려가 있습니다). 또한 소프트웨어가 상당히 복잡해져 테스트하기가 점점 어려워졌으며 계속해서 작업 할 계획입니다.

이 두 가지 이유 때문에 CI 사용에 대해 점점 더 생각하고 있습니다. 소프트웨어 엔지니어 교육을받은 적이없고 주변 사람들이 CI에 대해 들어 본 적이 없으며 (우리는 과학자, 프로그래머는 없음) 프로젝트를 시작하기가 어렵다는 것을 알게되었습니다.

조언을 얻고 싶은 몇 가지 질문이 있습니다.

먼저 소프트웨어 작동 방식에 대한 간단한 설명 :

• 소프트웨어는 모든 필수 설정이 포함 된 하나의 .xml 파일로 제어됩니다. 입력 인수로 .xml 파일의 경로를 전달하여 소프트웨어를 시작하면 실행되고 결과가있는 몇 개의 파일이 작성됩니다. 한 번의 실행은 ~ 30 초가 걸릴 수 있습니다.

• 과학적인 소프트웨어입니다. 거의 모든 함수에는 여러 입력 매개 변수가 있으며 그 유형은 대부분 복잡한 클래스입니다. 이 클래스의 인스턴스를 만드는 데 사용되는 큰 카탈로그가있는 여러 .txt 파일이 있습니다.

이제 내 질문에 봅시다 :

1. 단위 테스트, 통합 테스트, 엔드 투 엔드 테스트? : 내 소프트웨어는 현재 수백 개의 함수와 ~ 80 개의 클래스를 가진 약 30.000 줄의 코드입니다. 이미 구현 된 수백 가지 함수에 대한 단위 테스트 작성을 시작하는 것은 다소 이상합니다. 그래서 나는 단순히 테스트 케이스를 만드는 것에 대해 생각했습니다. 10-20 개의 서로 다른 .xml 파일을 준비하고 소프트웨어를 실행하십시오. 이것이 엔드-투-엔드 테스트라고하는 것 같아요? 나는 종종 당신이 이것을해서는 안된다는 것을 읽었지만 이미 작동중인 소프트웨어가 있다면 시작으로 괜찮을까요? 또는 이미 작동중인 소프트웨어에 CI를 추가하려고 시도하는 것은 어리석은 생각입니까?

2. 함수 매개 변수를 작성하기 어려운 경우 단위 테스트를 어떻게 작성합니까? 내가 함수가 있다고 가정 double fun(vector<Class_A> a, vector<Class_B>)일반적으로, 나는 타입의 객체 생성하기 위해 여러 텍스트 파일에서 첫 번째 읽을 필요 Class_A와 Class_B. Class_A create_dummy_object()텍스트 파일을 읽지 않고 같은 더미 함수를 만드는 것에 대해 생각했습니다 . 나는 또한 일종의 직렬화 구현에 대해 생각했다 . (클래스 객체의 생성은 여러 텍스트 파일에만 의존하기 때문에 테스트를 계획하지 않습니다)

3. 결과가 매우 다양한 경우 테스트를 작성하는 방법은 무엇입니까? 내 소프트웨어는 큰 몬테카를로 시뮬레이션을 사용하고 반복적으로 작동합니다. 일반적으로 반복 횟수는 ~ 1000 회이며 매 반복마다 몬테카를로 시뮬레이션을 기반으로 ~ 500-20.000 개의 객체 인스턴스를 생성합니다. 한 번의 반복으로 인해 하나의 결과 만 조금 다른 경우에는 다음에 나오는 전체 반복이 완전히 다릅니다. 이 상황을 어떻게 처리합니까? 최종 결과가 매우 다양하기 때문에 이것이 종단 간 테스트에 비해 큰 포인트라고 생각합니다.

CI에 대한 다른 조언은 높이 평가됩니다.

복잡한 주제와 일반적인 과학적 개발 프로세스 (일명 작동 할 때까지 해킹하면 일반적으로 테스트 가능한 디자인이 아님) 때문에 과학 소프트웨어를 테스트하는 것은 어렵습니다. 과학을 재현 할 수 있어야한다는 점을 고려하면 약간 아이러니하다. “일반”소프트웨어와 비교하여 변경되는 것은 테스트가 유용한 지 여부 (예!)가 아니라 어떤 종류의 테스트가 적합한 지입니다.

임의성 처리 : 모든 소프트웨어 실행을 재현 할 수 있어야합니다. Monte Carlo 기술을 사용하는 경우 난수 생성기에 특정 시드를 제공 할 수 있어야합니다.

• rand()글로벌 상태에 의존 하는 C의 함수를 사용할 때 이것을 잊어 버리기 쉽습니다 .
• 이상적으로, 난수 생성기는 함수를 통해 명시 적 객체로 전달됩니다. C ++ 11의 random표준 라이브러리 헤더는 이것을 훨씬 쉽게 만듭니다.
• 소프트웨어의 모듈에서 임의의 상태를 공유하는 대신 첫 번째 RNG에서 임의의 숫자로 시드되는 두 번째 RNG를 만드는 것이 유용하다는 것을 알았습니다. 그리고, 다른 모듈에 의한 RNG 요청의 수가 변경되면, 제 1 RNG에 의해 생성 된 시퀀스는 동일하게 유지된다.

통합 테스트 는 완벽합니다. 소프트웨어의 다른 부분이 올바르게 작동하는지 확인하고 구체적인 시나리오를 실행하는 데 능숙합니다.

• 최소 품질 수준 인 "충돌하지 않음"은 이미 좋은 테스트 결과가 될 수 있습니다.
• 더 강력한 결과를 얻으려면 일부 기준과 비교하여 결과를 확인해야합니다. 그러나 이러한 검사는 반올림 오류를 고려하여 다소 관용적이어야합니다. 전체 데이터 행 대신 요약 통계를 비교하는 것도 도움이 될 수 있습니다.
• 기준선에 대한 검사가 너무 취약하면 출력이 유효하고 일부 일반 특성을 만족하는지 확인하십시오. 이들은 일반적이거나 (“선택된 위치는 2km 이상 떨어져 있어야합니다”) 시나리오에 따라 다릅니다 (예 :“선택된 위치는이 영역 내에 있어야합니다”).

통합 테스트를 실행할 때는 테스트 러너를 별도의 프로그램 또는 스크립트로 작성하는 것이 좋습니다. 이 테스트 실행기는 필요한 설정을 수행하고 테스트 할 실행 파일을 실행하고 결과를 확인한 후 정리합니다.

소프트웨어를 위해 설계되지 않았기 때문에 단위 테스트 스타일 검사는 과학 소프트웨어에 삽입하기가 매우 어려울 수 있습니다. 특히, 테스트중인 시스템에 외부 종속성 / 상호 작용이 많은 경우 단위 테스트가 어려워집니다. 소프트웨어가 순수한 객체 지향이 아닌 경우 일반적으로 이러한 종속성을 모의 / 스텁 할 수 없습니다. 순수한 수학 함수와 유틸리티 함수를 제외하고는 그러한 소프트웨어에 대한 단위 테스트를 피하는 것이 가장 좋습니다.

몇 가지 테스트조차 테스트가없는 것보다 낫습니다. “통합해야한다”라는 체크와 함께 이미 통합 통합을 시작하는 것이 좋습니다. 나중에 언제든지 다시 돌아와서 더 많은 테스트를 추가 할 수 있습니다. 그런 다음 코드가 깨질 가능성이 높은 코드 영역의 우선 순위를 지정할 수 있습니다 (예 : 더 많은 개발 활동을 얻음). 단위 테스트에서 다루지 않은 코드 부분을 확인하려면 코드 범위 도구를 사용할 수 있습니다.

수동 테스트 : 특히 복잡한 문제 도메인의 경우 모든 것을 자동으로 테스트 할 수 없습니다. 예를 들어 현재 확률 적 검색 문제를 해결하고 있습니다. 소프트웨어가 항상 동일한 결과를 생성하는지 테스트하면 테스트를 중단하지 않고는 개선 할 수 없습니다. 대신 수동 테스트를 보다 쉽게 ​​수행 할 수있었습니다 . 고정 된 시드로 소프트웨어를 실행하고 시각화를 얻습니다.결과에 따라 (환경 설정에 따라 R, Python / Pyplot 및 Matlab을 통해 데이터 세트의 고품질 시각화를 쉽게 수행 할 수 있습니다). 이 시각화를 사용하여 상황이 크게 잘못되지 않았 음을 확인할 수 있습니다. 마찬가지로 로깅 출력을 통해 소프트웨어의 진행 상황을 추적하는 것은 최소한 로깅 할 이벤트 유형을 선택할 수있는 경우 실행 가능한 수동 테스트 기술이 될 수 있습니다.

이미 구현 된 수백 가지 함수에 대한 단위 테스트 작성을 시작하는 것은 다소 이상합니다.

위에서 언급 한 기능 을 변경할 때 테스트 를 작성하는 것이 좋습니다 . 기존 기능에 대해 수백 개의 단위 테스트를 작성하지 않아도되므로 시간이 많이 소요됩니다. 소프트웨어가 (아마도) 정상적으로 작동하고 있습니다. 이 테스트의 요점은 향후 변경으로 인해 이전 동작이 중단되지 않도록하는 것 입니다. 특정 기능을 다시 변경하지 않으면 테스트하는 데 시간이 걸리지 않을 것입니다 (현재 작동하고 항상 작동하며 계속 작동 할 것이므로). 레거시 코드를 이용한 효과적인 작업을 읽는 것이 좋습니다.이쪽의 마이클 페더스. 그는 의존성 파괴 기술, 특성화 테스트 (복제 동작을 유지하기 위해 테스트 스위트에 복사 / 붙여 넣기 기능 출력) 등을 포함하여 이미 존재하는 것들을 테스트하는 훌륭한 일반적인 전략을 가지고 있습니다.

함수 매개 변수를 작성하기 어려운 경우 단위 테스트를 어떻게 작성합니까?

이상적으로는 그렇지 않습니다. 대신 매개 변수를보다 쉽게 ​​만들 수 있으므로 디자인을 쉽게 테스트 할 수 있습니다. 물론 디자인 변경에는 시간이 걸리며 이러한 리팩토링은 기존 프로젝트와 같은 프로젝트에서 어려울 수 있습니다. TDD (Test Driven Development)가이를 도울 수 있습니다. 매개 변수를 만들기가 매우 어려운 경우 테스트 우선 스타일로 테스트를 작성하는 데 많은 어려움이 있습니다.

단기적으로는 모의를 사용하되 장기적으로 모의 지옥과 문제를 조롱하는 것에주의하십시오. 소프트웨어 엔지니어로 성장하면서 모의는 거의 항상 큰 문제를 해결하고 핵심 문제를 해결하지 않는 미니 냄새라는 것을 깨달았습니다. 나는 카펫에 약간의 개똥에 주석 호일 조각을 넣으면 여전히 냄새가 나기 때문에 "터프 랩핑"이라고합니다. 당신이해야 할 일은 실제로 일어나서 똥을 퍼 내고 쓰레기통에 버린 다음 쓰레기를 꺼냅니다. 이것은 분명히 더 많은 일이며, 손에 약간의 대변이 생길 위험이 있지만 장기적으로는 당신과 건강에 더 좋습니다. 당신이 그 멍청이를 계속 감싸면 집에서 더 오래 살고 싶지 않을 것입니다. mocks는 본질적으로 비슷합니다.

예를 들어 Class_A700 개 파일을 읽어야하기 때문에 인스턴스화하기 어려운 경우 이를 조롱 할 수 있습니다. 다음으로 알다시피, 모의는 구식이되고 실제 Class_A 는 모의와는 전혀 다른 일을하며 테스트는 실패 하더라도 여전히 통과 합니다 . 더 나은 솔루션은 구성 요소 Class_A를 보다 쉽게 ​​사용 / 테스트하고 구성 요소를 테스트하는 것입니다. 실제로 디스크에 충돌하는 하나의 통합 테스트를 작성 Class_A하여 전체적으로 작동 하는지 확인하십시오 . 또는 Class_A디스크에서 읽을 필요없이 간단한 문자열 (데이터를 나타내는)로 인스턴스화 할 수 있는 생성자가 있을 수 있습니다.

결과가 매우 다양한 경우 테스트를 작성하는 방법은 무엇입니까?

몇 가지 팁 :

1) 역수를 사용하십시오 (또는 일반적으로 속성 기반 테스트). fft는 [1,2,3,4,5]무엇입니까? 몰라. 무엇입니까 ifft(fft([1,2,3,4,5]))? 있어야합니다 [1,2,3,4,5](또는 그 가까이에 부동 소수점 오류가 발생할 수 있음).

2) "알려진"주장을 사용하십시오. 결정자 함수를 작성하면 결정자가 100x100 행렬인지를 말하기가 어려울 수 있습니다. 그러나 ID 행렬의 결정 요인이 100x100 인 경우에도 1이라는 것을 알고 있습니다. 또한 함수는 (0으로 가득 찬 100x100과 같이) 비가역 행렬에서 0을 반환해야한다는 것을 알고 있습니다.

3) 정확한 어설 션 대신 거친 어설 션을 사용하십시오 . 얼마 전에 이미지 사이에 매핑을 만들고 넥타이를 일치시켜 두 이미지를 등록하여 두 이미지를 등록하는 코드를 작성했습니다. 하위 픽셀 수준에서 등록 할 수 있습니다. 어떻게 테스트 할 수 있습니까? 같은 것들:

EXPECT_TRUE(reg(img1, img2).size() < min(img1.size(), img2.size()))

겹치는 부분에만 등록 할 수 있으므로 등록 된 이미지 는 가장 작은 이미지보다 작거나 같아야합니다.)

scale = 255
EXPECT_PIXEL_EQ_WITH_TOLERANCE(reg(img, img), img, .05*scale)

자체적으로 등록 된 이미지는 자체에 근접해야하지만 알고리즘으로 인해 부동 소수점 오류보다 약간 더 많은 오류가 발생할 수 있으므로 각 픽셀이 유효한 범위의 +/- 5 % (0-255)인지 확인하십시오. 일반적인 범위입니다 (회색조). 최소한 같은 크기 여야합니다. 당신은 심지어 연기 테스트를 할 수 있습니다 (즉, 호출하고 충돌하지 않는지 확인하십시오). 일반적으로이 기술은 테스트를 실행하기 전에 최종 결과를 (쉽게) 계산할 수없는 대규모 테스트에 더 좋습니다.

4) RNG에 난수 시드를 사용하거나 저장하십시오.

런 은 재현 가능해야합니다. 그러나 재현 가능한 실행을 얻는 유일한 방법 은 난수 생성기에 특정 시드를 제공하는 것 입니다. 때때로 무작위성 테스트 는 가치가 있습니다. 과학 코드에서 무작위로 생성 된 퇴화 사례에서 발생 하는 버그를 보았습니다 . 항상 동일한 시드로 함수를 호출하는 대신 임의의 시드를 생성 한 다음 해당 시드를 사용하고 시드 값을 기록하십시오. 이렇게하면 모든 실행에 서로 다른 임의의 시드가 있지만 충돌이 발생하면 디버그 한 로그를 시드하여 결과를 다시 실행할 수 있습니다. 나는 실제로 이것을 실제로 사용했고 버그를 없애 버렸으므로 언급 할 것이라고 생각했습니다.단점 : 테스트 실행을 기록해야합니다. 거꾸로 : 정확성과 버그 핵작.

HTH.

1. 시험의 종류

   • 이미 구현 된 수백 가지 함수에 대한 단위 테스트 작성을 시작하는 것은 다소 이상합니다.

     다른 방식으로 생각해보십시오. 여러 기능을 수행하는 패치가 엔드 투 엔드 테스트 중 하나를 위반하는 경우 어떤 문제가 있는지 어떻게 알 수 있습니까?

     전체 프로그램보다 개별 기능에 대한 단위 테스트를 작성하는 것이 훨씬 쉽습니다 . 개별 기능을 제대로 다루는 것이 훨씬 쉽습니다 . 단위 테스트가 부러진 코너 케이스를 모두 잡을 것이라고 확신 할 때 함수를 리팩토링하는 것이 훨씬 쉽습니다.

     이미 존재하는 함수에 대한 단위 테스트 작성은 레거시 코드베이스에서 작업 한 사람에게는 완벽하게 정상입니다. 그것들은 처음에 기능에 대한 이해를 확인하는 좋은 방법이며, 일단 작성된 후에는 예기치 않은 행동 변화를 찾는 좋은 방법입니다.

   • 엔드 투 엔드 테스트도 가치가 있습니다. 작성하기가 더 쉬우면, 반드시 먼저 수행하고 다른 테스트에 가장 관심이있는 기능을 다루기 위해 단위 테스트를 추가하십시오. 한 번에 모두 할 필요는 없습니다.

   • 예, 기존 소프트웨어에 CI를 추가하는 것이 합리적이고 정상입니다.

2. 단위 테스트 작성 방법

   객체가 실제로 비싸거나 복잡한 경우 모의를 작성하십시오. 다형성을 사용하는 대신 실제 객체를 사용하는 테스트와 별도로 모의를 사용하여 테스트를 연결할 수 있습니다.

   어쨌든 인스턴스를 작성하는 쉬운 방법이 있어야합니다. 더미 인스턴스를 작성하는 기능은 일반적이지만 실제 작성 프로세스를 테스트하는 것도 합리적입니다.

3. 변수 결과

   결과에 대한 일부 변형 이 있어야합니다 . 단일 숫자 값이 아닌 테스트하십시오.

   몬테 카를로 코드가 매개 변수로 허용하는 경우 모의 의사 난수 생성기를 제공 할 수 있습니다. 이는 적어도 잘 알려진 알고리즘에 대해 결과를 예측할 수 있지만 매번 동일한 숫자를 반환하지 않으면 취하기가 어렵습니다.

1. CI를 추가하는 것은 결코 멍청한 생각이 아닙니다. 경험을 통해 사람들이 자유롭게 기여할 수있는 오픈 소스 프로젝트를 진행할 때이 방법을 알고 있습니다. CI를 사용하면 코드가 프로그램을 중단하는 경우 사람들이 코드를 추가하거나 변경하지 못하게 할 수 있으므로 작동하는 코드베이스가 거의 없습니다.

   테스트를 고려할 때 코드 흐름이 정상적으로 작동하는지 확인하기 위해 엔드 투 엔드 테스트 (통합 테스트의 하위 범주라고 생각)를 확실히 제공 할 수 있습니다. 통합 테스트의 일부로 테스트 중에 발생한 다른 오류를 보상 할 수 있으므로 함수가 올바른 값을 출력하는지 확인하려면 최소한 기본 단위 테스트를 제공해야합니다.

2. 테스트 객체 생성은 실제로 어렵고 힘든 작업입니다. 당신은 더미 객체를 만들고 싶을 것입니다. 이러한 객체에는 기본 값이지만 가장자리 값이 있어야 출력 값을 확실히 알 수 있습니다.

3. 이 주제에 관한 책의 문제점은 CI (및 devops의 다른 부분)의 환경이 너무 빨리 진화하여 책의 어떤 것이라도 몇 개월 후에는 구식이 될 것이라는 점입니다. 도움이 될만한 책은 없지만 Google은 항상 귀하의 구주가되어야합니다.

4. 테스트를 여러 번 실행하고 통계 분석을 수행해야합니다. 이렇게하면 여러 실행의 중앙값 / 평균을 가져와 분석과 비교하여 어떤 값이 올바른지 알 수있는 일부 테스트 사례를 구현할 수 있습니다.

몇 가지 팁 :

• 깨진 코드가 코드베이스에 입력되는 것을 막으려면 GIT 플랫폼에 CI 도구를 통합하십시오.
• 다른 개발자가 피어 검토를 수행하기 전에 코드 병합을 중지하십시오. 이렇게하면 오류를보다 쉽게 ​​알 수 있으며 깨진 코드가 코드베이스에 입력되는 것을 다시 방지 할 수 있습니다.

amon 이전의 답변에서 이미 몇 가지 중요한 점을 언급했습니다. 좀 더 추가하겠습니다 :

1. 과학 소프트웨어와 상용 소프트웨어 개발의 차이점

과학 소프트웨어의 경우 일반적으로 과학 문제에 중점을 둡니다. 문제는 이론적 배경을보다 잘 다루고, 최상의 수치 방법을 찾는 등의 문제입니다. 소프트웨어는 작업의 일부에 불과합니다.

대부분의 경우 소프트웨어는 한 명 또는 소수의 사람 만 작성합니다. 종종 특정 프로젝트를 위해 작성되었습니다. 프로젝트가 완료되고 모든 것이 공개되면 대부분의 경우 소프트웨어가 더 이상 필요하지 않습니다.

상용 소프트웨어는 일반적으로 오랜 기간 동안 대규모 팀에서 개발합니다. 이를 위해서는 아키텍처, 설계, 단위 테스트, 통합 테스트 등을위한 많은 계획이 필요합니다.이 계획에는 상당한 시간과 경험이 필요합니다. 과학적인 환경에서는 일반적으로 그럴 시간이 없습니다.

프로젝트를 상용 소프트웨어와 유사한 소프트웨어로 변환하려면 다음을 확인해야합니다.

• 시간과 자원이 있습니까?
• 소프트웨어의 장기적인 관점은 무엇입니까? 일을 마치고 대학을 떠날 때 소프트웨어는 어떻게됩니까?

2. 엔드 투 엔드 테스트

소프트웨어가 점점 복잡해지고 여러 사람이 소프트웨어를 개발하고 있다면 테스트는 필수입니다. 그러나 아몬 이미 언급, 과학 소프트웨어 단위 테스트를 추가하는 것은 매우 어려운 일이다. 따라서 다른 접근 방식을 사용해야합니다.

소프트웨어는 대부분의 과학 소프트웨어와 같이 파일에서 입력을 가져 오므로 여러 샘플 입력 및 출력 파일을 작성하는 데 적합합니다. 각 릴리스에서 해당 테스트를 자동으로 실행하고 결과를 샘플과 비교해야합니다. 이것은 단위 테스트를 대체 할 수있는 좋은 방법입니다. 이 방법으로도 통합 테스트를받습니다.

물론 재현 가능한 결과를 얻으려면 amon이 이미 쓴 것과 같은 난수 생성기에 동일한 시드를 사용해야합니다 .

예제는 소프트웨어의 일반적인 결과를 다루어야합니다. 여기에는 파라미터 공간 및 수치 알고리즘의 경우도 포함되어야합니다.

실행하는 데 너무 많은 시간이 필요하지 않지만 일반적인 테스트 사례를 다루는 예제를 찾아야합니다.

3. 지속적인 통합

테스트 예제를 실행하는 데 시간이 다소 걸릴 수 있으므로 지속적인 통합이 불가능하다고 생각합니다. 추가 부품에 대해 동료와 논의해야 할 수도 있습니다. 예를 들어, 사용 된 숫자 방법과 일치해야합니다.

따라서 이론적 배경과 수치 방법, 신중한 테스트 등을 논의한 후 잘 정의 된 방식으로 통합을 수행하는 것이 좋습니다.

나는 지속적인 통합을 위해 어떤 종류의 자동화를 갖는 것이 좋은 생각이라고 생각하지 않습니다.

그건 그렇고, 버전 관리 시스템을 사용하고 있습니까?

4. 수치 알고리즘 테스트

테스트 결과를 확인할 때와 같이 수치 결과를 비교하는 경우 부동 숫자가 동일한 지 확인하지 않아야합니다. 반올림 오류가 항상있을 수 있습니다. 대신 차이가 특정 임계 값보다 낮은 지 확인하십시오.

알고리즘을 다른 알고리즘과 비교하여 확인하거나 과학적 문제를 다른 방식으로 공식화하고 결과를 비교하는 것이 좋습니다. 둘 이상의 독립적 인 방법을 사용하여 동일한 결과를 얻는 경우 이는 이론과 구현이 올바르다는 것을 나타냅니다.

테스트 코드에서 이러한 테스트를 수행하고 프로덕션 코드에 가장 빠른 알고리즘을 사용할 수 있습니다.

나의 충고는 당신이 노력하는 방법을 신중하게 선택하는 것입니다. 내 분야 (생물 정보학)에서는 최신 알고리즘이 너무 빨리 변경되어 오류 교정에 에너지를 소비하는 것이 알고리즘 자체에 더 잘 사용될 수 있습니다.

즉, 가치있는 것은 다음과 같습니다.

• 알고리즘 측면에서 당시 가장 좋은 방법입니까?
• 다른 컴퓨팅 플랫폼 (다른 HPC 환경, OS 특징 등)으로 포팅하는 것이 얼마나 쉬운가
• 견고성-내 데이터 세트에서 실행됩니까?

방탄 코드베이스를 구축하려는 본능은 고귀하지만 상용 제품이 아니라는 것을 기억할 가치가 있습니다. 가능한 한 휴대 가능하고 오류가 발생하지 않도록 (사용자 유형에 따라) 다른 사람이 편리하게 참여한 다음 알고리즘 자체에 집중