조사 할 때 어떤 소프트웨어 방법론을 따라야합니까?

나는 일반적으로 실험의 데이터를 분석하고 수행해야 할 일반적인 단계 스키마가 있지만 실험의 세부 사항이나 뒤에있는 질문에 맞게 조정해야 할 수도 있습니다. 나는 보통 유일한 코딩입니다.

나는 위키 백과를 보았지만 어떤 방법론을 사용할 수 있는지 확실하지 않습니다. 부분적으로는 아무것도 따르지 않았기 때문에 부분적으로는 데이터를 탐색하고 데이터가 어떻게 보이는지 확인하기 때문에 때로는 대답을 원합니다. (그리고 코드에서 테스트하거나 특정 품질을 기대하지 않기 때문에)

한 시간 또는 두 시간 후에 r 함수 table가 벡터의 순서에 의존하고 비교할 요소의 이름이 아니라는 것을 알게 된 후에이 질문을하라는 메시지가 표시 되었습니다. 그런 다음 모의 데이터와 함께 사용한 동작과 기능을 테스트해야했습니다. 그러나 다른 분석 결과 정보가 부족한 후 테이블을 사용했기 때문에 테스트 중심 개발 방법론을 따를 수 없었습니다 (올바로 이해하면). 그러나 프로젝트에 직면하는 방식이 약간 개선되면 더 빨리 오류를 감지하는 것 외에도 더 효율적일 수 있다고 생각하지만 결과를 의심하는 경우 어떻게 찾고 무엇을 찾아야하는지에 초점을 두지 마십시오. 이 예제는 실수입니다.

연구에 가장 적합한 소프트웨어 방법은 무엇입니까?

나는 기본적으로 연구의 특이성을 유지하면서 품질과 시간 경과를 보장하는 방법을 묻고 있습니다.

내가 일하는 방법의 예 :

생물학자는 질문을 염두에두고 실험을 수행하면 관심있는 데이터 (예 : 두 가지 조건에서 유전자 발현 수준)를 갖게된다는 사실을 알고 실험을 설정하고 10 명 / 마우스 / 쥐에서 샘플을 수집합니다. 이제 기존 라이브러리 및 테스트 (또는 새로운 테스트 구현)를 사용하여 생물학자가 염두에 둔 질문 (즉, 어떤 유전자가 다른 조건보다 한 조건에서 더 많이 발현되는지)을 고려하여 10 개의 샘플에 대한 데이터를 분석해야합니다. 구조는 이전 실험 (6 가지 조건 및 다른 동물 관련)과 동일하지만 통계 테스트, 정규화, 데이터 구조가 변경 될 수 있습니다. 따라서 보통 이전 버전을 복사하여 현재 요구에 맞게 조정합니다.

필요한 것은 아마도 소프트웨어 방법론이 아니라 과학에서 소프트웨어 개발에 의해 수행 된 역할에 대한 인식 부족 문제를 해결하는 학계의 정치적 변화 일 것입니다.

소프트웨어 지속 가능성 연구소 (영국) 과학 연구에서 컴퓨터 프로그래밍의 양심적 인 사용을 위해 주장하는 방법 : 당신이 찾고있는 무엇을 조직에 가장 가까운 것입니다.

또한 소프트웨어 개발 방법론에 관심이있는 사람들을위한 정보 포인터를 제공합니다.

그러나 방법론은 일반적으로 프로젝트 목표의 반복 및 점진적 개선을 통해 소프트웨어 프로그래머 팀을 지배하며 오랫동안 지속되는 안정적인 코드 기반으로 작동한다는 점을 지적해야합니다. 그것들은 당신이하고있는 것보다 훨씬 복잡한 프로젝트를위한 것입니다.

왜 이렇게 명백히 정확한 것 (과학 연구에서 컴퓨터 프로그래밍을보다 양심적으로 사용)이 달성되지 않았고 항상지지 받았는지에 대해서는 불편한 진실이 있습니다. 프로그램 작성. 기여의 본질이 과학 분야에 적합하더라도 소프트웨어와 관련된 사람들의 기여에 대한 인식을 거부하기 위해 함께 묶인 것처럼 보일 수도 있습니다.

• http://www.scientific-computing.com/news/news_news.story.php?news_id=2737
• https://news.ycombinator.com/item?id=10553837

직장에는 누락 된 일과 할 수있는 일이 있습니다.

빠진 것들 :

• 지침 부족
• 감독 부족 또는 질문 할 사람
• 사용하는 도구에 대해 잘 알고있는 멘토 부족 또는 컴퓨터 프로그래머 (예 : R)
• 반복성 및 학습 목적으로 소프트웨어 재사용, 보관, 버전 제어 또는 이전에 개발 된 소프트웨어의 문서 부족

요컨대, 전반적인 문화는 관련된 사람들이 실제로 과학 연구에 컴퓨터 프로그래밍을 더 양심적으로 사용하는 것에 관심이 없다는 것입니다.

할 수있는 일 :

• 도구 학습에 더 많은 시간을 할애하십시오.
  • 프로그래밍 언어에 대한 설명서 및 코드 샘플을 읽는 데 더 많은 시간을 보내십시오
  • 사용하는 도구를 사랑하는 법을 배워야합니다.
• 다음 몇 년 동안 같은 그룹의 사람들에게 노예가 될 다음 컴퓨터 프로그래머의 이익을 위해 무언가를 적어보십시오.
  • 위키는 훌륭 할 것입니다.
• 소스 버전 관리를 설정하십시오
  • 일반적으로 재사용되는 코드 스 니펫을 검색 할 수 있습니다.
  • 특정 실험에 사용 된 코드의 스냅 샷을 저장할 수 있습니다

경력 소프트웨어 개발자의 경우 이러한 특성에 대한 지침은 다음에서 찾을 수 있습니다.

• Joel 테스트 : Joel Spolsky의 코드를 개선하는 12 단계

이는 소프트웨어 개발 비즈니스를 운영하기위한 기본 요구 사항으로 간주됩니다. 그러나 당신이 무관심의 전쟁과 싸울 때는 우선 순위를 정해야합니다. 툴로 더 나아지고, 정보를 작성하고 유지하며, 소스 코드 버전을 유지하는 것은 유일한 환경에있어 최소한입니다.

방법론에 너무 신경 쓰지 말고 소프트웨어 개발 자체에 대한 요구 사항을 추적 해야하는 것에 더 집중하십시오.

여기서 당신과 비슷한 위치에 짧은 체재를 한 것은 내 개인적인 경험에서 추출 할 수있는 것입니다.

알고리즘의 정확성

아마도 가장 중요한 부분은 소프트웨어가 의도 한대로 작동한다는 것을 증명할 수 있어야합니다. 여기서 자동 테스트는 최고의 동맹입니다. 적절한 데이터 세트 없이는 어려울 수 있지만 실제로는 고유 한 데이터 세트를 만드는 습관을 들여야합니다. 그러나 그 목적은 다소 다르므로 데이터에서 추세를 추출하지는 않지만 소프트웨어가 알려진 데이터 세트에서 예측 가능하고 정확한 결과를 생성하도록합니다. 예를 들어 패턴 인식의 경우 멀티 공연 유전자 구성이 필요하지 않으며 알고리즘이 패턴을 감지하는 데 몇 줄의 텍스트만으로 충분할 수 있습니다.

나는 코너 케이스, 불가능한 케이스를 나타 내기 위해 데이터를 만들었습니다. 나는 예상되는 표준보다 극단에 더 집중하는 경향이 있었다. 이 상황이 실제 데이터 세트에서 발생하는 것을 볼 수없는 것만 테스트하는 것을 기억할 수 있습니다. 테스트하지 않았 으면 데이터 세트의 잠재적 손상 또는 오류를 식별하는 데 필요한 오류 감지 및 로깅을 설정하지 않았을 것입니다. 좋은 테스트 세트를 만드는 것이 실제 코드 전후에 관계없이 더 중요하다고 생각하지만 TDD는이 부분에 적합합니다.

버전 관리

이 부분이 너무 자주 빠졌습니다. 코드 및 생산 된 패키지 / 실행 파일에 대한 올바른 버전 관리 스키마는 진행 상황을 엄청나게 유지하는 데 도움이됩니다. 이전에 얻은 결과를 생성하는 데 사용 된 코드를 정확하게 복구 할 수 있으면 버그 나 불일치를 추적 할 때 도움이 될 수 있습니다. 다른 접근법이나 알고리즘을 실험 할 때도 브랜칭이 도움이 될 수 있습니다.

실제 계산에 사용 된 코드에 태그를 지정했는지 확인하십시오 . 버전 이름 지정에 도움이 필요한 경우 시맨틱 버전 관리를 확인하십시오 .

자동화 된 빌드

위의 포인트에 대한 추론. 소프트웨어 빌드 및 패키징 프로세스를 최대한 자동화하십시오. 소스와 의존성에서 최종 시스템을 만들기에 충분할 정도로 충분한 돈을 벌 필요는 없습니다. 여기서의 목표는 시간을 절약하는 동시에 종속성 및 기타 외부 장치를 포함하여 소스에서 소프트웨어를 재생성 할 수있는 재현 가능한 수단을 갖추는 것입니다. Groovy, Maven, ant, Scons, cmake는 빌드 자동화 도구 및 스크립팅 시스템의 일부 샘플 일뿐입니다.

추가 비용을 지불하려면 Jenkins 또는 teamcity 또는 기타 지속적인 통합 시스템을 설치하십시오. 분산 컴퓨팅을 위해 여러 서버 또는 작업자를 유지 관리해야하는 경우 보너스가 추가되었습니다. 이러한 시스템의 대부분은 유지 관리에 도움이됩니다. 또한 테스트 실행을 완전히 자동화 할 수 있으므로 계속하기 전에 결과를 기다릴 필요가 없으며 나중에 메일을 커밋하고받을 수 있습니다. 테스트 세트를 통과하는 데 몇 시간이 걸리는 시스템이 있습니다. 이 자동화를 세우는 것이 내 시간의 최고의 투자였습니다. 특히 모든 것을 빌드 할 스크립트가 이미 있다면.

환경 격리

연구원은 프로토콜을 통해 복잡한 시스템의 단일 또는 소규모 관심 변수 세트를 분리하는 데 많은 시간을 소비합니다. 이것은 또한 소프트웨어 개발 관행으로 확장되어야합니다. Docker 또는 Vagrant를 사용하여 컨테이너화를 확인할 수도 있습니다. 소프트웨어가 실행되는 환경을보다 잘 제어 할 수 있습니다.

돈을 지불하기 전에 큰 팀을 가질 필요는 없습니다. 저는 대부분의 시간 동안 혼자 있었지만 이들을 대신하여 큰 도움을 받았습니다. 마음의 평안과 시간이 절약되면 비용이 너무 많이 들었습니다.

1. R을 사용할 수 있습니까? 그게 다야.

2. 코드를 단순하게 유지하십시오 . 가독성을 높이고 문제가 아닌 한 성능에 대해 걱정하지 마십시오. 팀이 한 사람이라도 프로그래머 팀이 서로의 코드에 버그를 넣지 않도록하는 방법론이 있습니다.

3. 즉, 코딩 규칙 은 매우 중요합니다. 나는 매우 숙련 된 고급 과학자와 수학자의 코드를 본 적이, 그리고 그건 끔찍한 . 그들은 형식을 완전히 무시합니다. 진공 포장 된 것처럼 코드를 함께 압축합니다. 그들의 변수 이름은 완전히 신비합니다. 그들은 주석을 쓰지 않거나, 엉뚱한 주석을 쓰거나, 주석은 한 가지를 말하지만 코드는 다른 것을 말합니다. 그런 일을하지 마십시오. 항상 당신이나 다른 사람들이해야 할 미래의 변화를 미리 생각하십시오.