과학 코드는 일반적인 코딩 표준을 무시할만큼 다른 영역입니까?

최근에 나는 다음 사실에 대해 내 마음을 감싸려고 노력했습니다.

한편으로, "건강한", "깨끗한", "잘 작성된"등의 코드에 대한 다양한 코딩 지침 및 표준이 있습니다. 여기에서도 널리 논의되는 "청정 코드"를 참조하십시오. 규칙 예 : 7 줄 길이 방법과 1 ~ 2 단계 들여 쓰기. 따르지 않는 코드는 유지 관리 성이 좋지 않아 죽을 것으로 예상됩니다.

다른 한편으로는 OpenCV, OpenCascade, VTK 등으로 작업 할 수 있습니다. 과학적인 코드입니다. 그들은 2 페이지 길이의 메소드 (나 자신에게 있음)를 가지고 있으며 OpenCascade에는 메소드 또는 클래스가 10 개의 파일로 분할되어 있습니다 (여기 농담 없음) .VTK도 때때로 혼란입니다. 그러나 이러한 프로젝트는 번성하고 유지 관리되고 널리 사용됩니다!

캐치는 어? 어? 과학적으로 수학적으로 많은 코드를 작동하는 방식으로 작성할 수 있습니까? 그러한 프로젝트에 대해 별도의 표준 집합이 있습니까?

순진한 질문 일지 모르지만, 나는 일을하고하지 않는 방법에 대한 규칙을 세우려고 노력하는 프로그래밍 무효화 된 것 같습니다. 이것은 고등학교에서 일하도록 가르치는 방식입니다. 제가 졸업 한 이후로, 제가 프로그래밍해야 할 것들에 대한 가이드 라인 지원이 거의 없었습니다.

과학 코드는 일반적인 코딩 표준을 무시할만큼 다른 영역입니까?

아뇨.

연구 코드는 종종 "버려지고"배경이 아닌 개발자가 아닌 사람들이 작성하지만 학업 자격은 강력합니다. 내가 쓴 연구 코드 중 일부는 현재 나를 울게 만들 것이다 . 그러나 효과가있었습니다!

고려해야 할 사항 중 하나는 프로젝트의 게이트 키퍼가 포함되는 것을 추진한다는 것입니다. 대규모 프로젝트 경우 시작 학술 / 연구 코드 프로젝트로는, 작업 끝, 지금 엉망이다, 누군가가 그것을 리팩토링 할 수있는 주도권을 쥐고있다.

문제를 일으키지 않는 기존 코드를 리팩터링하려면 많은 작업이 필요합니다. 특히 도메인마다 다르거 나 테스트가없는 경우. 것을 당신은 볼 을 OpenCV는 스타일 가이드가 매우 포괄적이며 완벽하지 않더라도. 이것을 기존의 모든 코드에 소급 적용합니까? 그것은 .. 기절 한 마음이 아닙니다.

모든 코드가 작동하면 훨씬 더 어렵습니다. 깨지지 않았기 때문입니다. 왜 고쳐?

그러나 이러한 프로젝트는 번성하고 유지 관리되고 널리 사용됩니다!

이것은 어떤 의미에서 답입니다. 작업 코드는 여전히 유용하므로 유지 관리가 더 쉽습니다.

특히 처음에는 혼란 스러울 수 있습니다. 이 프로젝트들 중 일부는 아마도 일회성 프로젝트로 시작했을 것입니다.

또한 복잡한 알고리즘을 구현하는 경우 더 큰 방법을 사용하는 것이 더 합리적 일 수 있습니다. 과학적 측면에 익숙한 다른 사람들도 알고리즘을 개념적으로 더 잘 이해할 수 있기 때문입니다. 논문 논문은 최적화와 관련이있었습니다. 주요 알고리즘 로직을 하나의 방법으로 사용하는 것이 분리하려는 것보다 이해하기가 훨씬 쉽습니다. 그것은 분명히 "방법 당 7 줄"규칙을 위반했지만 다른 연구원이 내 코드를보고 알고리즘의 수정 사항을 더 빨리 이해할 수 있음을 의미했습니다.

이 구현이 추상화되어 잘 설계되면 프로그래머 가 아닌 사람 에게는이 투명성이 손실됩니다 .

동료 응답자에게 :이 질문은 하나 이상의 과학 영역에서 계산 집약적 인 작업을위한 오픈 소스 라이브러리의 코드 기반을 말합니다. 이 질문은 일회용 코드에 관한 것이 아닙니다. 답변을 작성하기 전에 강조 표시된 모든 부분을 파악할 수 있도록 잠시 멈추십시오.

사람들은 종종 모든 오픈 소스 프로젝트가 "저는 수천 / 수백만의 다른 사람들이 널리 사용하고 사용할 라이브러리에 대한 좋은 아이디어를 가지고 있습니다"라고 시작한다고 생각합니다. 그러면 모든 프로젝트가 그렇게됩니다.

많은 프로젝트가 시작되어 죽는 것이 현실입니다. 엄청나게 적은 비율의 프로젝트가 OpenCV 또는 VTK 등의 수준으로 "만들었습니다".

OpenCV는 인텔의 연구 프로젝트로 시작되었습니다. Wikipedia는이를 "일련의 프로젝트"의 일부로 설명합니다. 최초의 비 베타 출시는 2006 년 또는 처음 시작된 지 7 년 후였습니다. 처음에는 목표가 완벽한 코드가 아니라 의미있는 베타 릴리스 인 것으로 생각됩니다.

또한 OpenCV의 "소유권"이 크게 변경되었습니다. 모든 책임 당사자가 동일한 표준을 채택하여 프로젝트 기간 동안 유지하지 않는 한, 표준이 변경됩니다.

또한 Clean Code가 영감을 얻은 Agile Manifesto가 공개되기 전에 OpenCV가 몇 년 동안 있었음을 지적해야합니다 (VTK는 거의 10). VTK는 Clean Code가 출판되기 17 년 전에 시작되었습니다 (OpenCV는 "9 년 전만").

과학자들은 개발자가 아닙니다. 그들의 임무는 코드 자체를 작성하는 것이 아닙니다. 그들의 임무는 문제를 해결하는 것이며, 프로그래밍은 그들이 사용할 수있는 도구 중 하나 일뿐입니다.

전문 개발자가 직접 작성하는 대부분의 엔터프라이즈 코드는 엉망입니다. 이 코드의 대부분은 디자인 패턴을 사용하거나 오용하지 않습니다. 대부분의 의견은 TheDailyWTF의 후보입니다 . 따라서 우리 업계에서는 코드를 작성하는 사람들의 결과를 볼 수 있습니다. 프로그램을 쓰지 않는 사람들은 무엇을 기대하십니까?

실제 전문 개발자가 커리어 중에 배우는 모든 관행 이 과학자에게 도움이됩니까? 전혀. 모든 과학자가 5-10 년 동안 소프트웨어 개발을 배우는 데 인생을 보낼 수 있습니까? 아마 아닙니다. 따라서 코드 품질은 그대로입니다.

또 다른 요소는 문화입니다. 쌍이 깨끗한 코드를 작성하지 않으면 왜 그렇습니까? 아무도 신경 쓰지 않기 때문에 추가 노력을 기울이려는 경향이 없습니다.

마지막으로, 대부분의 과학 코드는 수명이 비교적 짧습니다. 특정 리서치에 대한 코드를 작성하고 리서치가 완료되면 코드를 재사용하지 않습니다. 일단이 습관을 가지게되면 인용하는 것과 같은 재사용 가능한 라이브러리와 버리기 코드 사이에서 차이를 만드는 것은 어렵습니다.

무시합니까? 다시 생각하고 조정 하시겠습니까? 확실한. 많은 과학 코드는 수학 집약적이고 성능이 중요합니다. 함수 호출의 오버 헤드와 같은 것은 실제로 문제가 될 수 있으므로 일반적인 상업용 앱에서보다 더 깊게 중첩 된 구조로 끝날 수 있습니다. 그렇다고해서 먼저 수천 번의 미세 최적화에 뛰어 들어야한다는 의미는 아닙니다. 여전히 올바른 알고리즘을 선택하는 데 중점을두고 효과를 측정 할 수있는 최적화 만 수행해야합니다.

차이점 중 일부는 명백하고 사소합니다. 코딩 지침은 일반적으로 의미있는 변수 이름을 선택해야하며 단일 문자 이름은 즉시 의심됩니다. 과학 응용 프로그램은 여전히 ​​의미있는 변수 이름을 원하지만 가장 의미있는 이름은 잘 알려진 방정식의 변수를 참조하는 단일 문자 일 수도 있습니다.

기존의 모든 답변은이 질문을 포괄적으로 다루었습니다. 그러나 OpenCV 와 같은 것들 사이 의 진정한 반포 가 무엇인지 지적하고 싶습니다 . 좋은 비즈니스 관행에 따라 개발 된 코드 (Code Complete, Clean Code, SOLID 등)

일반적으로 소스 코드가 KISS라는 많은 비즈니스 이점이 있습니다 . "간단하고 멍청하게 유지하십시오." 관련 YAGNI- "You Are n't Gonna Need It"도 있습니다.

불행하게도 과학 영역에서 계산 집약적 인 소프트웨어의 경우 소스 코드가 간결하거나 간결하지 않습니다 .

전통적으로 OpenCV는 일반화 부족 (다른 옵션을 지원하기위한 많은 코드 복제)으로 어려움을 겪었지만 VTK는 과도한 일반화 (템플릿)로 어려움을 겪었습니다.

초기에 OpenCV의 특정 부분은 원래 C로 개발되었습니다. 나중에 OpenCV는 오늘날 익숙한 C ++ API를 채택했습니다. 일부 알고리즘은 C ++ 인터페이스 (추상 기본 클래스) 및 C ++ 템플릿을 이용하도록 다시 작성되었습니다. 다른 알고리즘은 단순히 원래 C 코드의 래퍼였습니다. 이 코드의 나머지는 "imgproc"모듈에 흩어져 있습니다.

OpenCV에는 많은 SIMD 프로그래밍 (벡터화)이 포함되어 있습니다. 현재까지 C ++의 SIMD 프로그래밍에는 여전히 내장 함수 (intel.com) , (arm.com)이 필요 합니다.

SIMD 내장 함수는 컴파일러가 변수의 레지스터 할당을 처리한다는 점을 제외하고 어셈블리 언어와 유사하며 컴파일러는 성능 향상을 위해 명령 순서를 바꿀 수있는 자유가 있습니다. SIMD 내장 함수를 사용하도록 작성된 알고리즘은 유지 관리 비용이 많이 듭니다. 이것이 제가 이전 에 SIMD 프로그래밍 코드베이스의 유지 보수 비용에 대해 질문 한 이유 입니다.

SIMD 프로그래밍을하지 않는 사람은 SIMD를 우아하게 캡슐화 할 수 있고 더 이상 낮은 수준의 SIMD 프로그래밍이 더 이상 필요하지 않다고 쉽게 믿게 될 수 있습니다. 이것은 실제로 진실과는 거리가 멀다. 나는 누군가가 SIMD (프랙탈이 아닌)에서 유용한 알고리즘을 구현하려고 시도하고 제안 된 캡슐화에서 사용하기 어려움을 보도록 도전합니다.

다음은 계산 소프트웨어가 KISS 또는 YAGNI가 될 수없는 이유를 분석하려고 할 때의 아이디어 목록입니다. 그러나 이러한 모든 아이디어는 지나치게 일반화되어 있으며 위의 관찰을 뒷받침하지 않는 것 같습니다.

주요 기여 요인은 다음과 같습니다.

• 소프트웨어 성능
• 많은 알고리즘 옵션과 장단점을 지원할 필요성
• 다양한 하드웨어 플랫폼 및 컴파일러를 지원해야 함
  • 이것은 소프트웨어 성능 문제와 복합적입니다. 성능은 많은 하드웨어 플랫폼 및 컴파일러에 적합해야합니다.
• 자원 부족, 다른 요인을 손상시키지 않고 코드 품질을 향상시킬 수있는 지식이 부족한 사람들로 인해 지속적인 코드 기반 현대화 부족
  • 오픈 소스 프로젝트 는 공통점의 비극으로 어려움을 겪고 있습니다 .
  • 보조금을받는 오픈 소스 프로젝트는 특정 결과물을 충족해야했습니다. 일반적으로 코드 품질은 그 일부가 아닙니다.
  • 특히 점진적인 코드 품질 향상을 제안하거나 제안 할 수있는 지식이 부족한 사람들도 있습니다 . 이것은 "안구 누락"문제입니다 . 많은 사람들이 코드의 혜택을 누리지 만 코드를 읽는 데 시간이 많이 걸리지 않았습니다.
• 코드 검토, 단위 테스트, 정적 분석 등과 같은 코드 품질 게이트 부족
  • 대규모 프로젝트의 경우 이러한 코드 품질 게이트는 수동 단계가 아니라 각각 인프라 (웹 기반 시스템, 단위 테스트 시스템, 빌드 자동화 시스템 등)가 필요합니다.

위의 기여 요인 중 일부는 비즈니스 소프트웨어 개발의 대변자 입니다.

• 일반적으로 비즈니스 소프트웨어는 계산 소프트웨어에서 볼 수있는 높은 데이터 처리량을 처리 할 필요가 없습니다.
• 비즈니스 소프트웨어는 단일 운영 체제 및 컴퓨터 아키텍처에 연결될 수 있습니다.
• 비즈니스 소프트웨어는 포함 할 기능을 결정하는 데 검소 할 수 있습니다. 실제로 비즈니스 소프트웨어 개발은 ​​비즈니스 사례가 좋은 경우가 아니라면 관리자가 새로운 기능을 거부 할 것을 권장합니다.
  • 내부 비즈니스 소프트웨어 사용자는 코드를 변경할 필요없이 작업을 다르게 수행하도록 교육받을 수 있습니다.
  • 상용 비즈니스 소프트웨어가 누락 된 기능 하나 때문에 고객 한 명을 잃었지만 단순성과 사용 편의성 향상으로 인해 두 명의 새로운 고객을 확보 한 경우 ( "선택의 역설" 참조 ) 전체적으로 순 이익입니다. 이 기능 하나가없는 것.
• 비즈니스 소프트웨어는 지속적인 수익원에 의해 지원되므로 지속적인 코드 기반 현대화에 일부를 소비 할 수 있습니다.

과학 코드는 일반적인 코딩 표준을 무시할만큼 다른 영역입니까?

"공통 코딩 표준"이라고하는 것에 따라 다릅니다. 나는 민첩한 극단을 "공통"이라고 부르지 않을 것이다. 특히, 8 줄의 길이가 너무 길거나 너무 들여 쓰기가 너무 복잡한 함수는 숫자 / 과학 프로그래밍 분야에서 우스운 표준입니다.

매우 간단한 행렬 곱하기 행렬 함수는 7 줄 이상이며 세 수준의 들여 쓰기가 있습니다. 이 기능은 효율성에 대해 염려해야 할 것보다 상당히 복잡해집니다. 이것은 효율성이 중요한 일반적인 작업입니다. 그것을 조각으로 나누는 것은 당신이 원하지 않는 것입니다. 매트릭스 분해는 더욱 복잡해질 것입니다.

나는 완전히 다른 관점이기 때문에 이것을 새로운 답변으로 게시하기로 결정했습니다.

컴퓨터 비전과 이미지 이해 측면에서 "깨끗한 코드"라고 생각되는 코드 샘플을 살펴 보겠습니다.

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/seamless_cloning_impl.cpp

MATLAB 및 과학 컴퓨팅에 익숙한 사용자에게는 C ++ 코드가 가장 깨끗한 MATLAB 코드만큼 간결합니다.

이제 전체 라이브러리 코드베이스 (이 예제의 OpenCV)가이 코드 샘플과 동일한 표준으로 작성되지 않은 이유는 무엇입니까?

우리는 큰 과학 라이브러리의 코드베이스를 추상화 레벨 로 계층화 해야합니다 .

상기 낮은 수준 , 당신은 다시 구현 추가 및 뺄셈을 그대로이다. 또는 말 그대로 각 작업을 각 플랫폼에서 가장 빠른 구현으로 다시 매핑합니다.

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

중간 수준은 CPU 실행 시간의 90 %가 소요됩니다 - 우리가 아마 80 %있는 내 "더러운"코드를 찾을 수있는 곳입니다. (우리가 과학 연구와 소프트웨어 개발 노력을 따로 세어 보면 개발 노력의 80 %-90 %가 중간 수준에서 소비되었을 것입니다.)

상기 높은 수준의 , 우리는 연구자에 의해 쓰여진 깨끗한 코드를 가지고있다.

이러한 수준이 혼합되지 않도록하려면 소스 코드 구성의 우수성이 필요합니다. 이것은 코딩 표준을 넘어서고 , 오픈 소스 청지기 직분 과 더 관련이 있습니다.

예를 들어, 때때로 하나의 오픈 소스 프로젝트를 두 개로 나누기로 결정한 경우가 있습니다. 코드 커밋으로 이러한 일을 수행 할 수는 없습니다.