Вязкость (программирование)

О вязкости программного обеспечения говорят, когда внесение изменений, относящихся к некоторому аспекту программной системы, без нарушения заложенных в проект принципов связано с большими затратами времени и усилий^[1][2]. Сниженные возможности изменения могут быть вызваны: сложностью выделения компонентов, затрагиваемых изменениями; непропорциональным объёмом необходимых модификаций в сравнении с объёмом изменений в требованиях к ПО; глубоким влиянием изменений на систему в целом^[3].

В процессе разработки и сопровождения программного обеспечения вязкость ставит программистов перед выбором: сохранить ли первоначальные проектные решения при реализации нового требования или же нарушить их, используя «хакерские приёмы» и следуя путём «наименьшего сопротивления»^[2]. Из-за нехватки времени и непонимания проекта первоначальный замысел нарушается всё чаще^[1].

Вязкость может быть связана не только с самим программным обеспечением, но и со средой разработки. Неэффективная, медлительная среда разработки может мешать следованию правильному подходу и вынуждает прибегать к сомнительной практике. Факторы, влияющие на вязкость среды, могут включать в себя процесс разработки, процедуры повторного использования кода, организационные и правовые ограничения^[2].

В языках программирования и других системах для нотации, исследователи Томас Грин и Мариан Петре выделяют вязкость в качестве одного из когнитивных измерений. При этом вязкость подразделяется на кумулятивную (англ. knock-on), отражающую степень, в которой одно изменение вызывает другие для восстановления согласованности кода, и повторительную (англ. repetitive), выражающуюся как «сопротивление изменениям». Так, при сравнении вязкости декларативных и процедурных языков программирования выяснилось, что Бейсик имеет низкую повторительную вязкость по сравнению с Прологом. С кумулятивной вязкостью ситуация оказалась обратной. Было показано, что вязкость вызывается целым набором разнонаправленных факторов, а сама вязкость относится как к используемой нотации (коду), так и к используемому инструментарию^[4].

Помимо вязкости, существуют и другие близкие, но не эквивалентные ей особенности программного обеспечения, препятствующие внесению изменений.

• Жёсткость (англ. software rigidity — «закрепощённость») ^[5] программного обеспечения проявляется, когда в систему сложно вносить изменения сразу по многим направлениям.
• Неустойчивость (англ. fragility — «хрупкость») ^[6] проявляется, когда незначительное изменение в одной части может вызвать несколько проблем в других частях, даже напрямую не связанных с изменённым компонентом^[1].

• Код с запашком
• Технический долг

• Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика = Agile software development. Principles, Patterns, and Practices. — Вильямс, 2004. — 752 с. — ISBN 0-13-597444-5.
• Suryanarayana, G. and Samarthyam, G. and Sharma, T. Refactoring for Software Design Smells: Managing Technical Debt. — Elsevier Science, 2014. — P. 14. — 258 p. — ISBN 9780128016466.
• Spinellis, D. Code Quality: The Open Source Perspective. — Pearson Education, 2006. — P. 403. — 608 p. — ISBN 9780768685121.
• Amra, N.K. and Bedoya, H. and Cairns, T. and Cruikshank, D. and Diedrich, R. and Eberhard, J. and Evans, M. and Florez, A. and Gantner, S. and Gorzinski, J. and others. Modernizing IBM i Applications from the Database up to the User Interface and Everything in Between. — IBM Redbooks, 2014. — P. 30. — 720 p. — ISBN 9780738439860.

• Nicholas P. Wilde. Using Cognitive Dimensions in the Classroom as a Discussion Tool for Visual Language Design  (неопр.). University of Montana - Missoula. Дата обращения: 14 ноября 2014. Архивировано из оригинала 24 сентября 2015 года.