Методы промышленного стиля для того, чтобы повысить производительность в маленькой научной среде

1) И git, и mercurial будут работать под Windows нативно - нет необходимости в Cygwin - среде, которую я бы избегал, если это возможно.

2) Не понимаю, почему вы считаете, что должны использовать emacs.

3) Вы не проверяете код в определенное время суток или с определенной частотой - вы проверяете его, когда внесли явное изменение, которое было протестировано и работает. Или, если вы работаете над своей веткой, когда это удобно.

Здорово, что вы идете по этому маршруту. Вот несколько вещей, которые можно добавить к этому списку:

1) Добавьте тестирование в свой рабочий цикл. То есть, как только какой-то сегмент был написан, попросите других людей, которые над ним не работали, просмотреть код. Затем напишите тесты, чтобы убедиться, что новый код хорошо интегрируется с другим кодом и дает желаемые результаты, и, наконец, сделайте эти тесты частью процесса ночной сборки.

2) Начните процесс сборки за ночь. Или, по крайней мере, какой-то автоматизированный процесс, который перестраивает ваш код каждый раз, когда кто-то проверяет его. Пусть он запускает все ваши тесты для этой сборки.

Как упоминали другие, регистрация через регулярные промежутки времени не очень важна. Зарегистрируйтесь, когда вы достигли вехи (вы внесли изменение, которое работает с остальной частью кода, и оно правильно построено. Автоматизированные сборки гораздо важнее. Они подтверждают, что вы проверили все соответствующие изменения.

Я думаю, что вы можете быть немного смущены размещением системы управления версиями по сравнению с клиентами для управления версиями. Клиенты для CVS, SVN, Git и других практически повсеместно доступны для окон. Хостинг доступен от многих веб-хостинговых компаний. Это может быть хорошим вариантом,так как это также эффективно даст вам резервную копию вашей кодовой базы за ~ 100 $ / год. В качестве альтернативы вы можете просто загрузить сервер на бюджетный ПК и поместить его в шкаф где-нибудь, хотя стоимость электроэнергии, вероятно, столько же, сколько вы заплатили бы за хостинг.

Использование одной IDE для всех языков не важно вообще, важна согласованность в проектах одного языка. Все ваши проекты на одном языке, вероятно, должны иметь общий стандарт кодирования. Они также должны быть построены на одном и том же компиляторе и/или работать на одном интерпретаторе/виртуальной машине и иметь актуальные файлы проекта для любой IDE, которую вы используете (если применимо).

Попытка следовать каким-то лучшим практикам принесет вам много пользы, но вы можете обнаружить, что многие люди не очень заинтересованы в том, чтобы следовать им. Старайтесь рекламировать преимущества тонкими способами, чтобы не запугать своих коллег - если им понравится то, что они увидят, они могут со временем принять некоторые из ваших предложений.

Научная среда, где многие люди заботятся только о том, чтобы побыстрее закончить университет или получить одобрение своих заявок на финансирование, похоже, воспитывает ковбойский стиль кодирования. Если вы сможете заставить людей задуматься о качестве и воспроизводимости, вы уже победили.

Что я нашел полезного:

• Всегда старайтесь разбивать свой код на небольшие подпроекты, которые можно легко протестировать. Выполняйте тесты при каждой проверке. Вы можете использовать подмодули git для сборки ваших "приложений".
• Если репозиторий могут коммитить несколько человек, используйте что-то вроде astyle для согласованного форматирования (вероятно, это менее актуально для Python-кода).
• Создайте что-то вроде gitweb/cgit/..., чтобы люди могли получать tarball'ы с кодом и привыкать к мысли, что контроль исходных текстов полезен.
• Попробуйте найти приятеля-кодера в вашей группе/сообществе. Рецензирование кода очень трудно делать в среде, где люди склонны "просто сделать это", часто отбрасывая хороший стиль/здравый смысл за борт.

есть ли способ извлекать файлы LabVIEW в DVCS, например git?

Нет причин, по которым файлы LabVIEW не могли быть в DVCS, я использую Mercurial. Однако, поскольку файлы LabVIEW обрабатываются как двоичные файлы, размер вашего репо будет быстро расти.

Из коробки LabVIEW предоставляет только трехстороннее слияние , чтобы использовать функцию сравнения двух необходимых ревизий LV-diff , с несколькими настройками ] для поддержки инструментов, которые изменяют только расположение файлов (например, дублируют имена файлов).

Также важно добавить * .lvlps и * .aliases в ваш список игнорирования, эти файлы не имеют полезного значения на другом компьютере.