Специфіка наукового по

Наукове ПЗ має ряд особливостей, які рідко зустрічаються в сучасному комерційному програмуванні:

gt; Використовувані алгоритми вкрай складні. Розібратися в них з ходу часто не можуть навіть доктора наук, не кажучи вже про студентів або «простих» програмістів.

gt; Низька універсальність. По суті працює принцип «все, що можна зробити стандартними методами, вже давно зроблено». Для вирішення нової наукової задачі програму часто доводиться модифікувати і адаптувати.

gt; Унікальна модель поширення. Наукове ВО «рекламується» практично тільки через реферовані наукові журнали. Причому статті про самих програмах зазвичай публікуються вже після того, як за допомогою цих програм були отримані і опубліковані якісь цікаві наукові результати. Без цього програму ніхто не буде сприймати всерйоз.




gt; «Залишковий» фінансування. Вчені вкрай рідко отримують цілеспрямоване фінансування на розвиток ПО. Найчастіше ця діяльність розглядається лише як похідна від конкретної наукової задачі. Тільки найбільші і популярні програми удостоюються окремих грантів.




gt; Вчений - це не програміст. Програми пишуться самими вченими, які зазвичай не мають освіти в сфері ІТ. На перше місце ставиться виконання потрібної наукової задачі, а культурі розробки (системі збірки, переносимості, стандартам оформлення коду, документації) приділяється мало уваги.

gt; Важка спадщина минулого. Кодова база багатьох програм дуже стара і сходить до 70/80-х років минулого століття. Ці шари коду практично неможливо підтримувати, тому що вони написані на «мертвих» мовах начебто Fortran-77 і абсолютно не вписуються в сучасні стандарти програмування.

gt; Фрагментація розробки. Різні модулі програм пишуться в основному аспірантами або співробітниками, що працюють за тимчасовими контрактами. Вони працюють над кодом протягом 2-3 років, поки для них є фінансування, а потім змінюють місце роботи, кидаючи код в «напівсирому» вигляді. Оскільки культура програмування не є пріоритетом, через кілька років виникає класичне «спагетті», розібратися в якому стає все важче.

gt; Складність налагодження і тестування. Порівняти результати роботи програм часто просто нема з чим, тому що це і є горезвісний «передній край науки». Щоб налагодити програму, її доводиться скрупульозно перевіряти на безлічі тестових прикладів з відомими результатами, але і це не дає повної гарантії. В реальній задачі можуть зустрітися абсолютно несподівані комбінації даних, що порушують збіжність чисельних алгоритмів, що викликають несподівані переповнення і виникнення сумно знаменитих «corner cases». gt;

gt; Вимоги до користувачів. Часто незрозуміло, що є «глюком» програми, а що - специфікою досліджуваного об`єкта. Для інтерпретації отриманого результату потрібна хороша наукова кваліфікація користувача. Крім того, працює принцип «сміття на вході - сміття на виході». Наукове ПЗ не може відсікти «сміття» на вході, тому що заздалегідь невідомо, для якого об`єкта його будуть застосовувати. Наприклад, маса об`єкта в деяких випадках може виявитися негативною (повітряну кульку з гелієм в розганяється машині) і «відсікати» негативну масу програма не має права. Розуміти, що таке «сміття», повинен сам користувач.