Вязкость (программирование): различия между версиями
| [отпатрулированная версия] | [отпатрулированная версия] |
РоманСузи (обсуждение | вклад) добавил к см. также для повышения связности |
РоманСузи (обсуждение | вклад) дополнение |
||
| Строка 5: | Строка 5: | ||
Вязкость может быть связана не только с самим программным обеспечением, но и со средой разработки. Неэффективная, медлительная среда разработки может мешать следованию образцам надлежащей практики и вынуждает прибегать к сомнительной практике. Факторы, влияющие на вязкость среды, могут включать в себя [[Процесс разработки программного обеспечения|процесс разработки]], процедуры [[Повторное использование кода|повторного использования кода]], организационные и правовые ограничения{{sfn|Suryanarayana, Samarthyam, Sharma|2014}}. |
Вязкость может быть связана не только с самим программным обеспечением, но и со средой разработки. Неэффективная, медлительная среда разработки может мешать следованию образцам надлежащей практики и вынуждает прибегать к сомнительной практике. Факторы, влияющие на вязкость среды, могут включать в себя [[Процесс разработки программного обеспечения|процесс разработки]], процедуры [[Повторное использование кода|повторного использования кода]], организационные и правовые ограничения{{sfn|Suryanarayana, Samarthyam, Sharma|2014}}. |
||
В языках программирования и других системах для нотации, исследователи Томас Грин и Мариан Петре выделяют вязкость в качестве одного из [[Когнитивные измерения|когнитивных измерений]]. При этом вязкость подразделяется на кумулятивную (knock-on), насколько одно изменение вызывает другие для восстановления согласованности кода, и повторительную (repetitive), выражающуюся как «сопротивление изменениям». Так, Sidiqqi и другие провели сравнение вязкости [[декларативный язык программирования|декларативных]] и [[процедурный язык программирования|процедурных языков программирования]]. Выяснилось, что [[Бейсик]] имеет низкую повторительную вязкость по сравнению с [[Пролог (язык программирования)|Пролог]]ом. С кумулятивной вязкостью ситуация оказалась обратной. Было показано, что вязкость вызывается целым набором разнонаправленных факторов, а сама вязкость относится как к используемой нотации (коду), так и к испрользуемому инструментарию{{книга |
|||
| автор = Rinderle-Ma, S. and Sadiq, S. and Leymann, F. |
|||
| заглавие = Business Process Management Workshops: BPM 2009 International Workshops, Ulm, Germany, September 7, 2009, Revised Papers |
|||
| издательство = Springer |
|||
| год = 2010 |
|||
| allpages = |
|||
| pages = 480 |
|||
| isbn = 9783642121852 |
|||
}}. |
|||
== См. также == |
== См. также == |
||
* [[Код с запашком]] |
* [[Код с запашком]] |
||
* [[Технический долг]] |
* [[Технический долг]] |
||
* [[Когнитивные измерения]] |
|||
== Примечания == |
== Примечания == |
||
Версия от 17:32, 12 апреля 2015
Вя́зкость — отрицательное качество программного кода (или среды разработки), один из признаков плохого проектирования, выражающихся в пониженной податливости программной системы изменениям (англ. changeability). О вязкости программного обеспечения говорят, когда внесение изменений, относящихся к некоторому аспекту программной системы, без нарушения заложенных в проект принципов связано с большими затратами времени и усилий[1][2]. Сниженные возможности изменения могут быть вызваны: сложностью выделения компонентов, затрагиваемых изменениями; непропорциональным объёмом необходимых модификаций в сравнении с объёмом изменений в требованиях к ПО; глубоким влиянием изменений на систему в целом[3]. В случае, когда в систему сложно вносить изменения сразу по многим направлениям, говорят о жёсткости («закрепощённости»[4]) программного обеспечения (англ. software rigidity). Другим проявлением плохой податливости изменениям, наряду с вязкостью и жёсткостью, является неустойчивость[5] (англ. fragility — хрупкость) . Изменение в одной части хрупкого программного обеспечения может вызвать несколько проблем в других частях, даже напрямую не связанных с изменённым компонентом[1].
В процессе разработки и сопровождения программного обеспечения вязкость ставит программистов перед выбором: сохранить ли основы первоначального дизайна при реализации нового требования или же нарушить их, используя «хакерские приёмы» и следуя путём «наименьшего сопротивления»[2]. Из-за нехватки времени и непонимания проекта первоначальный замысел нарушается всё чаще[1].
Вязкость может быть связана не только с самим программным обеспечением, но и со средой разработки. Неэффективная, медлительная среда разработки может мешать следованию образцам надлежащей практики и вынуждает прибегать к сомнительной практике. Факторы, влияющие на вязкость среды, могут включать в себя процесс разработки, процедуры повторного использования кода, организационные и правовые ограничения[2].
В языках программирования и других системах для нотации, исследователи Томас Грин и Мариан Петре выделяют вязкость в качестве одного из когнитивных измерений. При этом вязкость подразделяется на кумулятивную (knock-on), насколько одно изменение вызывает другие для восстановления согласованности кода, и повторительную (repetitive), выражающуюся как «сопротивление изменениям». Так, Sidiqqi и другие провели сравнение вязкости декларативных и процедурных языков программирования. Выяснилось, что Бейсик имеет низкую повторительную вязкость по сравнению с Прологом. С кумулятивной вязкостью ситуация оказалась обратной. Было показано, что вязкость вызывается целым набором разнонаправленных факторов, а сама вязкость относится как к используемой нотации (коду), так и к испрользуемому инструментариюRinderle-Ma, S. and Sadiq, S. and Leymann, F. Business Process Management Workshops: BPM 2009 International Workshops, Ulm, Germany, September 7, 2009, Revised Papers. — Springer, 2010. — P. 480. — ISBN 9783642121852..
См. также
Примечания
- ↑ 1 2 3 Amra and others, 2014.
- ↑ 1 2 3 Suryanarayana, Samarthyam, Sharma, 2014.
- ↑ Spinellis, 2006.
- ↑ Мартин, Ньюкирк, Косс, 2004, с. 151.
- ↑ Мартин, Ньюкирк, Косс, 2004, с. 152.
Литература
- Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика = 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.