Якої програмної методології я повинен дотримуватися, коли я роблю дослідження?

Я зазвичай аналізую дані експериментів, і хоча у мене є загальна схема кроків, які мені потрібно зробити, мені може знадобитися підлаштувати їх до специфіки експериментів або до питань, що стоять позаду. Я, як правило, єдиний.

Я переглянув вікіпедію, але не впевнений, яку методологію я можу використовувати, частково тому, що я ніколи не дотримувався жодної, а частково тому, що інколи просто вивчаю дані, щоб побачити, як вони виглядають, а в інший раз просто хочу відповіді. (І тому, що я не дуже сподіваюся на тестування або мати певну якість свого коду)

Мене запропонували задати це питання через годину-дві, виявивши, що функція r tableпокладається на порядок векторів, а не на назву елементів для порівняння. Тоді я хоч і повинен був перевірити поведінку та функції, де я використовувався з деякими глузуючими даними. Але я використав таблицю після того, як інший аналіз призвів до браку інформації, тому я не міг дотримуватися тестової методології розробки (якби я зрозумів це правильно). Однак я відчуваю, що з деяким вдосконаленням у тому, як я стикаюся з проектом, я міг би бути більш ефективним, окрім виявлення помилок швидше, але також як і на що звернути увагу, якщо я сумніваюся в результаті, тому, будь ласка, не зосереджуйтесь лише ця приклад помилка.

Яка програмна методологія найкраще підходить для досліджень?

Я в основному запитую, як забезпечити якісний і своєчасний прогрес, а також зберегти специфіку досліджень.

Приклад того, як я працюю:

Біолог має на увазі питання і знає, що проведення експерименту призведе до наявності даних, що цікавлять (тобто, рівень експресії генів у двох умовах), тоді він / він встановив експеримент і пригадав зразки від 10 людей / мишей / щурів. Тепер я повинен проаналізувати ці дані для цих 10 зразків, використовуючи існуючі бібліотеки та тести (або впроваджуючи нові тести), але враховуючи питання, які біолог мав на увазі (тобто які гени виражені в одній умові, ніж в інших). Структура така ж, як і в попередніх експериментах (в яких брали участь 6 умов та інша тварина), але статистичний тест, нормалізація, структура даних можуть змінюватися. Тому я зазвичай копіюю попередню версію і адаптую її до поточних потреб.

Можливо, потрібна не програмна методологія, а політична зміна в наукових колах, яка фіксує питання про невпізнання ролі, яку відіграє розробка програмного забезпечення в науці.

Інститут програмного забезпечення в області стійкого розвитку (Великобританія) є організацією , ближче всього до того , що ви шукаєте: як доводи в користь більш сумлінного використання комп'ютерних програм в області наукових досліджень.

Він також пропонує інформаційні вказівки для тих, хто цікавиться методологіями розробки програмного забезпечення.

Однак я маю зазначити, що методології, як правило, керують командами програмних програмістів з ітераціями та поступовим уточненням цілей проекту та працюють зі стабільними базами коду, які тривають довгий час. Вони призначені для проектів, які на порядок складніші за те, що ви робите.

Щодо того, чому ця дуже очевидно правильна річ (більш сумлінне використання комп’ютерного програмування в наукових дослідженнях) не виконана і завжди підтримується, ось незручна істина: в академічних адміністративних умовах вчені можуть погіршити значення, яке грає комп'ютер програмування. Іноді їх можна бачити, як вони збираються разом, щоб заперечувати визнання внесків людей, які займаються програмним забезпеченням, навіть якщо характер цього внеску відповідає науковій дисципліні.

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

На вашому робочому місці є речі, яких бракувало, і речі, які ви можете зробити.

Речі, яких не вистачало:

• Відсутність вказівок
• Відсутність нагляду або особи, щоб задати питання
• Відсутність менторів або комп'ютерних програмістів, які добре обізнані з інструментами, якими ви користуєтесь (наприклад, R)
• Відсутність повторного використання програмного забезпечення, архівації, контролю версій або документації раніше розробленого програмного забезпечення для повторюваності та навчальних цілей

Коротше кажучи, загальна культура полягає в тому, що залучені люди не дуже зацікавлені ... ви здогадалися ... більш сумлінне використання комп'ютерного програмування в наукових дослідженнях.

Що ви можете зробити:

• Приділіть більше часу навчанню своїх інструментів.
  • Витратьте більше часу на читання документації та зразків коду для мов програмування
  • Вам доведеться навчитися любити інструменти, якими ви користуєтесь.
• Спробуйте щось записати на благо наступного комп'ютерного програміста, який буде поневолений в одній групі людей протягом наступних двох років
  • Вікі буде чудовим.
• Спробуйте встановити контроль версії джерела
  • Вміти отримувати часто використовувані фрагменти коду
  • Вміти зберегти знімок коду, який використовується в конкретному експерименті

Для розробників програмного забезпечення для кар’єри такі рекомендації можна знайти в:

• Тест Джоеля: 12 кроків до кращого коду Джоела Спольського

Вони вважаються основними вимогами для ведення бізнесу з розробки програмного забезпечення. Однак, коли ви ведете боротьбу з апатичною війною, вам потрібно визначити пріоритет. Покращення роботи з інструментами, записування та збереження інформації, зберігання версій вихідного коду - мінімальний мінімум для єдиного середовища.

Не сильно зациклюйтеся на методології, але постарайтеся зосередити увагу на тому, що вам потрібно слідкувати за своїми вимогами щодо самої розробки програмного забезпечення.

Провівши коротке перебування на позиції, порівняно з вашою, ось що я можу отримати з особистого досвіду.

Алгоритмічна точність

Мабуть, найважливіший аспект, ви повинні мати можливість довести, що ваше програмне забезпечення робить те, що було розроблено. Тут автоматичне тестування - ваш найкращий союзник. Я усвідомлюю, що без належного набору даних важко обійтися, але насправді ви повинні створити звичку створювати власні набори даних. Однак їх призначення дещо інше, ви не намагаєтеся витягнути тенденцію з даних, але гарантуєте, що програмне забезпечення дає передбачувані та правильні результати з відомого набору даних. Отже, для розпізнавання шаблону, наприклад, вам не потрібен багатогранний генетичний склад, лише декількох рядків тексту може бути достатньо, щоб алгоритм виявив шаблон.

Я використовував свої дані для представлення кутових справ, неможливих справ. Я схилявся зосереджуватися більше на крайнощах, ніж на очікуваній нормі. Багато разів я можу згадати тестування на щось неможливе, лише побачити, як ця ситуація виникає у фактичному наборі даних. Якби я не перевіряв її, я б не встановлював виявлення помилок та реєстрацію даних, необхідних для виявлення потенційних пошкоджень чи помилок у наборі даних. TDD добре підходить для цієї частини, хоча для створення гарного тестового набору я думаю, що важливіше незалежно від того, чи будете ви це робити до або після фактичного коду.

Версія

Занадто часто ця частина залишається поза увагою. Хороша схема версій для вашого коду та вироблених пакунків / виконуваних файлів допоможе безперебійно підтримувати свій прогрес у порядку. Вдається відновити саме той код, який використовувався для створення попередньо отриманих результатів, може допомогти при відстеженні помилок або розбіжностей. Розгалуження може також допомогти при експерименті з різними підходами чи алгоритмами.

Переконайтеся, що ви позначили код, який використовується у фактичних обчисленнях. Перевірте семантичне версія, якщо вам потрібна допомога щодо іменування версій.

Автоматизована збірка

Дослідження до точки вище. Переконайтеся, що ви максимально автоматизували процес створення та упаковки свого програмного забезпечення. Вам не потрібно виходити на повну суму, достатньо, щоб зробити тривіальним створення кінцевої системи з джерела та залежностей. Мета полягає в тому, щоб заощадити ваш час, а також мати відтворене значення для відновлення програмного забезпечення з джерела, включаючи залежності та інші зовнішні програми. Groovy, Maven, ant, Scons, cmake - це лише невеликий зразок інструментів автоматизації побудови та скриптових систем, які можуть допомогти.

Якщо ви хочете пройти додаткову милю, встановіть Дженкінс або teamcity або будь-яку іншу систему безперервної інтеграції. Доданий бонус, якщо вам доведеться підтримувати кілька серверів або працівників для розподілених обчислень. Більшість із цих систем матимуть засоби, які допоможуть у обслуговуванні. Крім того, ви зможете повністю автоматизувати тестові запуски, тому вам не потрібно чекати результатів, перш ніж продовжувати, просто введіть і отримайте пошту пізніше. У мене була система, яка займала години, щоб пройти тестові набори. Постановка цієї автоматики була найкращою інвестицією мого часу. Тим більше, що якщо у вас вже є сценарії, щоб все будувати.

Ізоляція навколишнього середовища

Дослідник витрачає невиправдану кількість часу, виділяючи окремий чи малий набір змінних, що цікавлять складні системи, за допомогою своїх протоколів. Це також слід поширити на вашу практику розробки програмного забезпечення. Ви також можете перевірити наявність контейнерів за допомогою Docker або Vagrant. Це дасть вам кращий контроль над середовищем, в якому працює програмне забезпечення.

Вам не потрібно мати велику команду, перш ніж це окупиться, я більшу частину часу все ще отримав користь, поставивши їх на місце. Душевний спокій та час врятували це за умови, що набагато переважили накладні витрати, що коштувало мені на це.

1. Чи можете ви використовувати R? Ось для чого це.

2. Зберігайте простий код . Займіться читабельністю, і не турбуйтеся про продуктивність, якщо це не проблема. Існують методики, які намагаються утримати команди програмістів не вводити помилок у код один одного, навіть якщо в команді одна людина.

3. Однак, дисципліна кодування є надзвичайно важливою. Я бачив код висококваліфікованих передових вчених та математиків, і це жахливо . Вони повністю ігнорують форматування. Вони зліплюють код разом, як у вакуумі. Їх змінні назви абсолютно загадкові. Вони не пишуть коментарів, або пишуть недостовірні коментарі, або коментарі говорять одне, а код говорить інше. Не роби цього. Завжди продумайте майбутні зміни, які вам або іншим, можливо, доведеться внести.