Tôi nên làm theo phương pháp phần mềm nào khi nghiên cứu?

Tôi thường phân tích dữ liệu của các thử nghiệm và mặc dù tôi có một sơ đồ tổng quát về các bước tôi cần thực hiện, tôi có thể cần phải điều chỉnh nó theo các chi tiết cụ thể của các thử nghiệm hoặc các câu hỏi phía sau. Tôi thường là người duy nhất viết mã.

Tôi đã xem wikipedia nhưng tôi không chắc mình có thể sử dụng phương pháp nào, một phần vì tôi chưa bao giờ làm theo, và một phần vì đôi khi tôi chỉ khám phá dữ liệu, để xem nó trông như thế nào và những lần khác tôi chỉ muốn một câu trả lời. (Và vì tôi không mong đợi nhiều để kiểm tra hoặc có chất lượng nhất định về mã của mình)

Tôi được nhắc hỏi câu hỏi này sau một hoặc hai giờ phát hiện ra rằng hàm r tablephụ thuộc vào thứ tự của các vectơ chứ không phải tên của các phần tử để so sánh chúng với. Sau đó, mặc dù tôi nên kiểm tra hành vi và chức năng mà tôi đã sử dụng với một số dữ liệu giả. Nhưng tôi đã sử dụng bảng sau khi phân tích khác dẫn đến thiếu thông tin, do đó tôi không thể tuân theo phương pháp phát triển dựa trên thử nghiệm (nếu tôi hiểu đúng). Tuy nhiên tôi cảm thấy rằng với một số cải tiến trong cách tôi đối mặt với dự án, tôi có thể hiệu quả hơn, ngoài việc phát hiện lỗi sớm hơn, mà còn tìm cách và những gì cần tìm trong trường hợp tôi nghi ngờ một kết quả, vì vậy xin đừng tập trung vào ví dụ này sai lầm.

Phương pháp phần mềm nào phù hợp nhất trong nghiên cứu?

Về cơ bản, tôi đang hỏi làm thế nào để đảm bảo chất lượng và tiến độ đúng thời gian cũng như giữ được tính đặc thù của nghiên cứu.

Ví dụ về cách tôi làm việc:

Một nhà sinh vật học có một câu hỏi và biết rằng thực hiện một thí nghiệm sẽ dẫn đến dữ liệu quan tâm (nghĩa là mức độ biểu hiện gen trong hai điều kiện), sau đó cô ấy / anh ấy đặt thí nghiệm và hồi tưởng mẫu từ 10 người / chuột / chuột .. Bây giờ tôi phải phân tích dữ liệu cho 10 mẫu đó bằng các thư viện và bài kiểm tra hiện có (hoặc thực hiện các bài kiểm tra mới) nhưng có tính đến câu hỏi mà nhà sinh vật học đã nghĩ đến (tức là gen nào được biểu hiện nhiều hơn trong một điều kiện so với điều kiện khác). Cấu trúc giống như trong các thí nghiệm trước đó (bao gồm 6 điều kiện và một động vật khác) nhưng kiểm tra thống kê, chuẩn hóa, cấu trúc dữ liệu có thể thay đổi. Vì vậy, tôi thường sao chép một phiên bản trước và điều chỉnh nó theo nhu cầu hiện tại.

Điều cần thiết có lẽ không phải là một phương pháp phần mềm, mà là một sự thay đổi chính trị trong giới hàn lâm nhằm khắc phục vấn đề thiếu sự công nhận vai trò của phát triển phần mềm trong khoa học.

Các bền vững Viện Software (Anh) là một tổ chức gần nhất với những gì bạn đang tìm kiếm: làm thế nào để tranh luận để sử dụng có lương tâm hơn về lập trình máy tính trong nghiên cứu khoa học.

Nó cũng cung cấp các gợi ý thông tin cho những người quan tâm đến các phương pháp phát triển phần mềm.

Tuy nhiên, tôi phải chỉ ra rằng các phương pháp thường chi phối các nhóm lập trình viên phần mềm, với các lần lặp và hoàn thiện dần dần các mục tiêu dự án và hoạt động với các cơ sở mã ổn định tồn tại trong một thời gian dài. Chúng dành cho các dự án có độ lớn phức tạp hơn những gì bạn đang làm.

Về lý do tại sao điều này rất rõ ràng (sử dụng lập trình máy tính một cách có ý thức hơn trong nghiên cứu khoa học) đã không được thực hiện và luôn được duy trì, đây là sự thật bất tiện: trong môi trường hành chính học thuật, các nhà khoa học có thể thấy làm giảm tầm quan trọng của máy tính lập trình. Đôi khi, họ có thể được nhìn thấy để cùng nhau từ chối công nhận những đóng góp từ những người liên quan đến phần mềm, ngay cả khi bản chất của sự đóng góp đó phù hợp với kỷ luật khoa học.

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

Tại nơi làm việc của bạn, có những thứ còn thiếu và những thứ bạn có thể làm.

Những thứ còn thiếu:

• Thiếu hướng dẫn
• Thiếu sự giám sát hoặc người đặt câu hỏi
• Thiếu người cố vấn hoặc lập trình viên máy tính am hiểu các công cụ bạn sử dụng (ví dụ R)
• Thiếu sử dụng lại phần mềm, lưu trữ, kiểm soát phiên bản hoặc tài liệu của phần mềm được phát triển trước đó, cho mục đích học tập và lặp lại

Nói tóm lại, văn hóa tổng thể là những người liên quan không thực sự quan tâm đến ... bạn đoán nó ... sử dụng lập trình máy tính một cách có ý thức hơn trong nghiên cứu khoa học.

Những điều bạn có thể làm:

• Dành nhiều thời gian hơn để học các công cụ của bạn.
  • Dành nhiều thời gian hơn để đọc tài liệu và mẫu mã cho ngôn ngữ lập trình của bạn
  • Bạn sẽ phải học cách yêu thích các công cụ bạn sử dụng.
• Hãy cố gắng viết ra một cái gì đó, vì lợi ích của lập trình viên máy tính tiếp theo, những người sẽ bị bắt làm nô lệ cho cùng một nhóm người trong vài năm tới
  • Một wiki sẽ là tuyệt vời.
• Cố gắng thiết lập kiểm soát phiên bản nguồn
  • Có thể truy xuất các đoạn mã thường được sử dụng lại
  • Có thể lưu ảnh chụp nhanh mã được sử dụng trong một thử nghiệm cụ thể

Đối với các nhà phát triển phần mềm nghề nghiệp, các hướng dẫn về bản chất này có thể được tìm thấy trong:

• Bài kiểm tra Joel: 12 bước để mã tốt hơn của Joel Spolsky

Đây được coi là các yêu cầu cơ bản để điều hành một doanh nghiệp phát triển phần mềm. Tuy nhiên, khi bạn đang chiến đấu với một cuộc chiến thờ ơ, một mình, bạn cần phải ưu tiên. Làm tốt hơn với các công cụ, viết ra và duy trì thông tin, giữ các phiên bản của mã nguồn là mức tối thiểu cho một môi trường duy nhất.

Đừng bận tâm quá nhiều về phương pháp mà hãy cố gắng tập trung hơn vào những gì bạn cần để theo dõi, yêu cầu của bạn, cho chính sự phát triển phần mềm.

Đã thực hiện một kỳ nghỉ ngắn ở một vị trí tương đối giống với bạn ở đây là những gì tôi có thể rút ra từ kinh nghiệm cá nhân của mình.

Độ chính xác của thuật toán

Có lẽ là khía cạnh quan trọng nhất, bạn sẽ có thể chứng minh rằng phần mềm của bạn làm những gì nó được thiết kế để làm. Ở đây kiểm tra tự động là đồng minh tốt nhất của bạn. Tôi nhận ra rằng có thể khó thực hiện nếu không có bộ dữ liệu phù hợp nhưng thực sự bạn nên tạo thói quen tạo bộ dữ liệu của riêng mình. Tuy nhiên, mục đích của chúng hơi khác nhau, bạn không cố gắng trích xuất xu hướng từ dữ liệu nhưng đảm bảo phần mềm tạo ra kết quả chính xác và có thể dự đoán được từ một tập dữ liệu đã biết. Vì vậy, để nhận dạng mẫu chẳng hạn, bạn không cần trang điểm di truyền nhiều gig, chỉ cần một vài dòng văn bản là đủ để đảm bảo thuật toán phát hiện mẫu.

Tôi đã sử dụng để tạo dữ liệu của mình để đại diện cho các trường hợp góc, trường hợp không thể. Tôi có xu hướng tập trung nhiều hơn vào các thái cực hơn là các chỉ tiêu dự kiến. Nhiều lần tôi có thể nhớ việc kiểm tra một thứ không thể chỉ để thấy tình huống này phát sinh trong tập dữ liệu thực tế. Nếu tôi không kiểm tra nó, tôi sẽ không đặt các phát hiện lỗi và ghi nhật ký cần thiết để xác định các lỗi hoặc lỗi tiềm ẩn trong tập dữ liệu. TDD phù hợp với phần này mặc dù việc tạo ra một bộ kiểm tra tốt là tôi nghĩ quan trọng hơn bất kể bạn làm điều đó trước hay sau mã thực tế.

Phiên bản

Quá thường xuyên phần này bị bỏ rơi. Một lược đồ phiên bản tốt cho mã của bạn và các gói được sản xuất / thực thi sẽ giúp vô cùng để giữ tiến trình của bạn theo thứ tự. Để có thể khôi phục chính xác mã đã được sử dụng để tạo kết quả thu được trước đó có thể giúp đỡ khi theo dõi các lỗi hoặc sai lệch. Sự phân nhánh cũng có thể giúp ích khi thử nghiệm các phương pháp hoặc thuật toán khác nhau.

Đảm bảo bạn gắn thẻ mã được sử dụng trong các tính toán thực tế, Kiểm tra phiên bản ngữ nghĩa nếu bạn cần trợ giúp về cách đặt tên các phiên bản.

Xây dựng tự động

Một hệ quả đến điểm trên. Hãy chắc chắn rằng bạn tự động hóa càng nhiều càng tốt quá trình xây dựng và đóng gói phần mềm của bạn. Bạn không cần phải đi đầy đủ, chỉ đủ để làm cho nó trở nên tầm thường để tạo ra hệ thống cuối cùng từ nguồn và phụ thuộc. Mục tiêu ở đây là để giúp bạn tiết kiệm thời gian nhưng cũng có nghĩa là có thể tái tạo để tạo lại phần mềm từ nguồn, bao gồm cả phụ thuộc và các phần bên ngoài khác. Groovy, Maven, ant, Scons, cmake, nhưng là một mẫu nhỏ của các công cụ tự động hóa xây dựng và hệ thống kịch bản có thể giúp đỡ.

Nếu bạn muốn đi xa hơn, hãy cài đặt Jenkins hoặc teamcity hoặc bất kỳ hệ thống tích hợp liên tục nào khác. Đã thêm tiền thưởng nếu bạn phải duy trì nhiều máy chủ hoặc công nhân cho tính toán phân tán. Hầu hết các hệ thống này sẽ có phương tiện để giúp bảo trì. Ngoài ra, bạn sẽ có thể tự động hóa hoàn toàn các lần chạy thử, do đó bạn không cần đợi kết quả trước khi tiếp tục, chỉ cần cam kết và nhận thư sau. Tôi đã có một hệ thống mất hàng giờ để vượt qua các bộ thử nghiệm. Đưa ra tự động hóa này là đầu tư tốt nhất trong thời gian của tôi. Đặc biệt là như vậy nếu bạn đã có sẵn các kịch bản để xây dựng mọi thứ.

Cách ly môi trường

Nhà nghiên cứu dành lượng thời gian không phù hợp để cô lập một tập hợp các biến quan tâm duy nhất hoặc nhỏ từ các hệ thống phức tạp thông qua các giao thức của chúng. Điều này cũng nên được mở rộng cho thực tiễn phát triển phần mềm của bạn. Bạn cũng có thể kiểm tra việc container hóa bằng Docker hoặc Vagrant. Nó sẽ cho phép bạn kiểm soát tốt hơn môi trường mà phần mềm được chạy.

Bạn không cần phải có một đội ngũ lớn trước khi điều này được đền đáp, tôi đã ở một mình trong hầu hết thời gian nhưng được hưởng lợi rất nhiều khi đưa những thứ này vào vị trí. Sự an tâm và thời gian tiết kiệm được nó cung cấp vượt xa chi phí mà nó khiến tôi phải trả giá.

1. Bạn có thể sử dụng R? Đó là những gì nó làm.

2. Giữ mã của bạn đơn giản . Đi để dễ đọc và đừng lo lắng về hiệu suất trừ khi đó là một vấn đề. Các phương pháp tồn tại để cố gắng giữ cho các nhóm lập trình viên không đặt các lỗi vào mã của nhau, ngay cả khi nhóm là một người.

3. Điều đó nói rằng, kỷ luật mã hóa là siêu quan trọng. Tôi đã thấy mã từ các nhà khoa học và nhà toán học tiên tiến được đào tạo bài bản, và điều đó thật kinh khủng . Họ hoàn toàn bỏ qua định dạng. Họ squish mã với nhau giống như nó được đóng gói chân không. Tên biến của họ là hoàn toàn bí ẩn. Họ không viết bình luận, hoặc họ viết bình luận khó hiểu, hoặc các bình luận nói một điều trong khi mã nói điều khác. Đừng làm những điều đó. Luôn luôn nghĩ về những thay đổi trong tương lai mà bạn hoặc người khác có thể phải thực hiện.