Программная археология: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[непроверенная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
добавлена ссылка на соответствующую статью Википедии
Нет описания правки
Метка: редактор вики-текста 2017
 
(не показано 8 промежуточных версий 3 участников)
Строка 1: Строка 1:
'''Программная археология''' — дисциплина, изучающая слабо документированное или недокументированное [[унаследованное программное обеспечение]], в целях его [[Сопровождение программного обеспечения|сопровождения]]<ref name="RGBH">Gregorio Robles, Jesus M. Gonzalez-Barahona, and Israel Herraiz, «[http://herraiz.org/papers/english/icsm05short.pdf An Empirical Approach to Software Archaeology], „ ''Poster Proceedings of the International Conference on Software Maintenance'', 2005.</ref><ref>“[http://www.agilemodeling.com/essays/agileLegacyIntegrationModeling.htm Agile Legacy System Analysis and Integration Modeling]» by Scott W. Ambler at agilemodeling.com, accessed 20 August 2010: "Without accurate documentation, or access to knowledgeable people, your last resort may be to analyze the source code for the legacy system.</ref>. Программная археология включает в себя [[Обратная разработка|обратную разработку]] приложений, использование инструментальных средств и технологических процессов для извлечения и понимания структуры кода, восстановления замысла его разработчиков<ref name="RGBH" /><ref>Richard Hopkins and Kevin Jenkins, ''[https://books.google.com/books?id=GYvP0u2k2uMC&pg=PA93 Eating the IT Elephant: Moving from greenfield development to brownfield]'', Addison-Wesley, 2008, ISBN 0-13-713012-0, p. 93.</ref>. Компьютерная археология может обнаружить проблемы, связанные с неудачной архитектурой приложения и [[Мёртвый код|отмершим (неиспользуемым) кодом]]<ref>Diomidis Spinellis and Georgios Gousios, ''[https://books.google.com/books?id=h34pwy005nYC&pg=PA29 Beautiful Architecture]'', O’Reilly, 2009, ISBN 0-596-51798-X, p. 29.</ref>. Термин используется уже несколько десятилетий<ref>An early discussion is Judith E. Grass, "[http://www.usenix.org/publications/compsystems/1992/win_grass.pdf Object-Oriented Design Archaeology with CIA++], " ''Computing Systems'', Vol. 5, No. 1, Winter 1992.</ref> и отражает следующую метафору: разработчик, читающий код унаследованного программного обеспечения, ощущает себя так же, как и археолог, исследующий памятники древней цивилизации<ref name="AndyDave">Andy Hunt and Dave Thomas, «[http://media.pragprog.com/articles/mar_02_archeology.pdf Software Archaeology]», ''IEEE Software'', vol. 19, no. 2, pp. 20-22, Mar.</ref>.
'''Программная археология''' — дисциплина, изучающая слабо документированное или недокументированное [[унаследованное программное обеспечение]], в целях его [[Сопровождение программного обеспечения|сопровождения]]<ref name="RGBH">Gregorio Robles, Jesus M. Gonzalez-Barahona, and Israel Herraiz, «[http://herraiz.org/papers/english/icsm05short.pdf An Empirical Approach to Software Archaeology] {{Wayback|url=http://herraiz.org/papers/english/icsm05short.pdf |date=20200120210715 }}, „ ''Poster Proceedings of the International Conference on Software Maintenance'', 2005.</ref><ref>“[http://www.agilemodeling.com/essays/agileLegacyIntegrationModeling.htm Agile Legacy System Analysis and Integration Modeling] {{Wayback|url=http://www.agilemodeling.com/essays/agileLegacyIntegrationModeling.htm |date=20210323180819 }}» by Scott W. Ambler at agilemodeling.com, accessed 20 August 2010: "Without accurate documentation, or access to knowledgeable people, your last resort may be to analyze the source code for the legacy system.</ref>. Программная археология включает в себя [[Обратная разработка|обратную разработку]] приложений, использование специальных инструментальных средств и технологических процессов для извлечения и понимания структуры кода, восстановления замысла его разработчиков<ref name="RGBH" /><ref>Richard Hopkins and Kevin Jenkins, ''[https://books.google.com/books?id=GYvP0u2k2uMC&pg=PA93 Eating the IT Elephant: Moving from greenfield development to brownfield] {{Wayback|url=https://books.google.com/books?id=GYvP0u2k2uMC&pg=PA93 |date=20150323030114 }}'', Addison-Wesley, 2008, ISBN 0-13-713012-0, p. 93.</ref>. Программная археология помогает обнаружить проблемы, связанные с неудачной архитектурой приложения и [[Мёртвый код|отмершим (неиспользуемым) кодом]]<ref>Diomidis Spinellis and Georgios Gousios, ''[https://books.google.com/books?id=h34pwy005nYC&pg=PA29 Beautiful Architecture] {{Wayback|url=https://books.google.com/books?id=h34pwy005nYC&pg=PA29 |date=20150322232939 }}'', O’Reilly, 2009, ISBN 0-596-51798-X, p. 29.</ref>. Термин используется уже несколько десятилетий<ref>An early discussion is Judith E. Grass, "[http://www.usenix.org/publications/compsystems/1992/win_grass.pdf Object-Oriented Design Archaeology with CIA++], " ''Computing Systems'', Vol. 5, No. 1, Winter 1992.</ref> и отражает следующую метафору: разработчик, читающий код унаследованного программного обеспечения, ощущает себя так же, как и археолог, исследующий памятники древней цивилизации<ref name="AndyDave">Andy Hunt and Dave Thomas, «[http://media.pragprog.com/articles/mar_02_archeology.pdf Software Archaeology] {{Wayback|url=http://media.pragprog.com/articles/mar_02_archeology.pdf |date=20201109083435 }}», ''IEEE Software'', vol. 19, no. 2, pp. 20-22, Mar.</ref>.


== Инструменты и методы ==
== Инструменты и методы ==
В 2001 году на конференции {{abbr|OOPSLA|Object-Oriented Programming, Systems, Languages & Applications, объектно-ориентированное программирование, системы, языки и приложения}} секция программной археологии определила следующие инструменты и методы программной археологии, некоторые из которых относятся к [[Объектно-ориентированное программирование|объектно-ориентированному программированию]]<ref name="AndyDave" />:
В 2001 году на конференции {{abbr|OOPSLA|Object-Oriented Programming, Systems, Languages & Applications, объектно-ориентированное программирование, системы, языки и приложения}} секция программной археологии определила следующие инструменты и методы программной археологии, некоторые из которых относятся к [[Объектно-ориентированное программирование|объектно-ориентированному программированию]]<ref name="AndyDave" />:
* [[Сценарный язык|Скриптовые языки]] для создания статических отчетов и фильтрации отладочного вывода
* [[Сценарный язык|Скриптовые языки]] для создания статических отчетов и фильтрации отладочного вывода
* Изучение существующей сопровождающей документации в формате HTML, PDF, CHM, MSHC или Wiki
* Изучение существующей сопровождающей документации в формате HTML, PDF, CHM, MSHC или Wiki
*Создание сопровождающей документации на API ([[Javadoc]], [[doxygen]]), добавление документирующих комментариев в кодовую базу приложения
* Создание сопровождающей документации на API ([[Javadoc]], [[doxygen]]), добавление документирующих комментариев в кодовую базу приложения
* [[Сигнатурный анализ]], статистический анализ, инструменты для визуализации ПО
* Изучение сообщений подсистемы объяснений<ref>{{Книга|автор=Гаврилова Т. А., Хорошевский В. Ф.|заглавие=Базы знаний интеллектуальных систем|ответственный=|год=2000.|издание=|место=СПб.|издательство=Питер|страницы=|страниц=|isbn=}}</ref> (при сопровождении экспертных систем)
*[[Сигнатурный анализ]], статистический анализ, инструменты для визуализации ПО
* Инструменты [[Обратная разработка|обратной разработки]]
* Инструменты [[Обратная разработка|обратной разработки]]
* Отслеживание системных вызовов (truss, strace)
* Отслеживание системных вызовов (truss, strace)
Строка 15: Строка 14:
* [[Отладчик]]и и профилировщики
* [[Отладчик]]и и профилировщики


В целях систематической [[Трассировка (программирование)|трассировки]] вызовов функций без широкомасштабного редактирования кодовой базы исследуемого приложения можно успешно применять [[аспектно-ориентированное программирование]] (например, [[AspectJ]]<ref name="AndyDave" /> для Java, [https://github.com/ArxOne/MrAdvice MrAdvice] для C# .NET), разработав аспектные классы для получения средствами рефлексии информации о состоянии стека вызовов, отфильтровывания из него нужной информации и записи ее в журнальный файл или окно протокола работы (т.н. лога) приложения.
В целях систематической [[Трассировка (программирование)|трассировки]] вызовов функций без широкомасштабного редактирования кодовой базы исследуемого приложения можно успешно применять [[аспектно-ориентированное программирование]] (например, [[AspectJ]]<ref name="AndyDave" /> для Java, [https://github.com/ArxOne/MrAdvice MrAdvice] для C# .NET), разработав аспектные классы для получения средствами рефлексии информации о состоянии стека вызовов, отфильтровывания из него нужной информации и записи её в журнальный файл или окно протокола работы (т. н. лога) приложения.

При сопровождении экспертной системы важным источником информации о логике её работы являются сообщения подсистемы объяснений<ref>{{Книга|автор=Гаврилова Т. А., Хорошевский В. Ф.|заглавие=Базы знаний интеллектуальных систем|ответственный=|год=2000.|издание=|место=СПб.|издательство=Питер|страницы=|страниц=|isbn=}}</ref>.


[[:en:Andy Hunt (author)|Энди Хант]] и [[:en:Dave Thomas (programmer)|Дейв Томас]] указывают на важность использования системы [[Система управления версиями|контроля версий]], контейнера управления зависимостями, инструментов индексирования текста (GLIMPSE, SWISH-E) и «[составления] карты исследования»<ref name="AndyDave" />.
[[:en:Andy Hunt (author)|Энди Хант]] и [[:en:Dave Thomas (programmer)|Дейв Томас]] указывают на важность использования системы [[Система управления версиями|контроля версий]], контейнера управления зависимостями, инструментов индексирования текста (GLIMPSE, SWISH-E) и «[составления] карты исследования»<ref name="AndyDave" />.


Подобно настоящей археологии, программная археология предполагает исследовательскую работу для понимания мыслительных процессов предшественников<ref name="AndyDave" />. На секции OOPSLA [[Каннингем, Уорд|Уорд Каннингем]] предложил так называемый «синоптический сигнатурный анализ», который дает в первом приближении понимание «духа» программы путём показа разработчику только лишь пунктуации кода (двоеточия, [[Блок (программирование)|операторные скобки]])<ref>[[Каннингем, Уорд|Ward Cunningham]], «[http://c2.com/doc/SignatureSurvey/ Signature Survey: A Method for Browsing Unfamiliar Code], „ Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001.</ref>. Также Каннингем предложил рассматривать программы, напечатанные минимально возможным шрифтом, для понимания общей структуры программы<ref>“[http://www.johndcook.com/blog/2009/11/10/oftware-archeology/ Software Archeology]» on John D. Cook’s blog ''The Endeavour'', November 10, 2009.</ref>.
Подобно настоящей археологии, программная археология предполагает исследовательскую работу для понимания мыслительных процессов предшественников<ref name="AndyDave" />. На секции OOPSLA [[Каннингем, Уорд|Уорд Каннингем]] предложил так называемый «синоптический сигнатурный анализ», который дает в первом приближении понимание «духа» программы путём показа разработчику только лишь пунктуации кода (двоеточия, [[Блок (программирование)|операторные скобки]])<ref>[[Каннингем, Уорд|Ward Cunningham]], «[http://c2.com/doc/SignatureSurvey/ Signature Survey: A Method for Browsing Unfamiliar Code] {{Wayback|url=http://c2.com/doc/SignatureSurvey/ |date=20100822050624 }}, „ Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001.</ref>. Также Каннингем предложил рассматривать программы, напечатанные минимально возможным шрифтом, для понимания общей структуры программы<ref>“[http://www.johndcook.com/blog/2009/11/10/oftware-archeology/ Software Archeology] {{Wayback|url=http://www.johndcook.com/blog/2009/11/10/oftware-archeology/ |date=20120306152253 }}» on John D. Cook’s blog ''The Endeavour'', November 10, 2009.</ref>.


Методы сетевого и временно́го анализа, расширение [https://marketplace.visualstudio.com/items?itemName=git-archaeology.git-archeology Git Archaeology] для Microsoft Visual Studio могут помочь обнаружить шаблоны совместной деятельности разработчиков унаследованного ПО, которые, в свою очередь, могут пролить свет на силы и слабости получившегося в итоге кода<ref>Cleidson de Souza, Jon Froehlich, and Paul Dourish, "[http://www.dourish.com/publications/2005/DeSouzaFroehlichDourish-SeekingSource-GROUP.pdf Seeking the Source: Software Source Code as a Social and Technical Artifact], " Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work, pp. 197—206.</ref>.
Методы сетевого и временно́го анализа, расширение [https://marketplace.visualstudio.com/items?itemName=git-archaeology.git-archeology Git Archaeology] для Microsoft Visual Studio могут помочь обнаружить шаблоны совместной деятельности разработчиков унаследованного ПО, которые, в свою очередь, могут пролить свет на силы и слабости получившегося в итоге кода<ref>Cleidson de Souza, Jon Froehlich, and Paul Dourish, "[http://www.dourish.com/publications/2005/DeSouzaFroehlichDourish-SeekingSource-GROUP.pdf Seeking the Source: Software Source Code as a Social and Technical Artifact] {{Wayback|url=http://www.dourish.com/publications/2005/DeSouzaFroehlichDourish-SeekingSource-GROUP.pdf |date=20150923220106 }}, " Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work, pp. 197—206.</ref>.


Майкл Розлог из [[Embarcadero Technologies]] описал программную археологию как процесс из шести шагов, который позволяет разработчикам ответить на такие вопросы: «Что досталось мне в наследство?» и «В каких местах этот код ужасен?»<ref name="Rozlog">Michael Rozlog, "[http://java.sys-con.com/node/487614 Software Archeology: What Is It and Why Should Java Developers Care?], " article on java.sys-con.com, January 28, 2008.</ref> Эти шаги, как и обнаруженные секцией OOPSLA, включая визуализацию кода для понимания архитектуры приложения, используют [[Метрика программного обеспечения|метрики программного обеспечения]] для поиска нарушений принципов проектирования и стиля программирования, [[модульное тестирование]] и [[Профилирование (информатика)|профилирование]] для поиска дефектов ПО (т.н. [[Программная ошибка|багов)]] и узких мест в производительности, а также сбор информации о структуре приложения, восстановленной в процессе<ref name="Rozlog" /> программно-археологических раскопок. Программная археология может также быть услугой, предоставляемой штатным разрабочикам внешними консультантами<ref>Simon Sharwood, [http://www.zdnetasia.com/raiders-of-the-lost-code-39199788.htm Raiders of the Lost Code], [[ZDNet]], November 3, 2004.</ref>.
Майкл Розлог из [[Embarcadero Technologies]] описал программную археологию как процесс из шести шагов, который позволяет разработчикам ответить на такие вопросы: «Что досталось мне в наследство?» и «В каких местах этот код ужасен?»<ref name="Rozlog">Michael Rozlog, "[http://java.sys-con.com/node/487614 Software Archeology: What Is It and Why Should Java Developers Care?] {{Wayback|url=http://java.sys-con.com/node/487614 |date=20150713140525 }}, " article on java.sys-con.com, January 28, 2008.</ref> Эти шаги, как и обнаруженные секцией OOPSLA, включая визуализацию кода для понимания архитектуры приложения, используют [[Метрика программного обеспечения|метрики программного обеспечения]] для поиска нарушений принципов проектирования и стиля программирования, [[модульное тестирование]] и [[Профилирование (информатика)|профилирование]] для поиска дефектов ПО (т. н. [[Программная ошибка|багов)]] и узких мест в производительности, а также сбор информации о структуре приложения, восстановленной в процессе программно-археологических раскопок<ref name="Rozlog" />. Программная археология может также быть услугой, предоставляемой штатным разрабочикам внешними консультантами<ref>Simon Sharwood, [http://www.zdnetasia.com/raiders-of-the-lost-code-39199788.htm Raiders of the Lost Code] {{Wayback|url=http://www.zdnetasia.com/raiders-of-the-lost-code-39199788.htm |date=20120314033052 }}, [[ZDNet]], November 3, 2004.</ref>.


{{Якорь|DataArchaeology}}
{{Якорь|DataArchaeology}}
Строка 33: Строка 34:
# ''Ему не нужно было быть здесь, а программист, написавший это, не ведал, что творил''.
# ''Ему не нужно было быть здесь, а программист, написавший это, не ведал, что творил''.
# ''Оно '''всё еще''' должно быть здесь, и это '''Вы''' не ведаете, что творите''.
# ''Оно '''всё еще''' должно быть здесь, и это '''Вы''' не ведаете, что творите''.
''Следствие этого «закона»: пока причина неизвестна, не следует изменять код (или данные)''<ref>For example, the [http://portal.acm.org/toc.cfm?id=1806799 32nd ACM/IEEE International Conference on Software Engineering] in Cape Town, South Africa in May 2010</ref>}}.
''Следствие этого «закона»: пока причина неизвестна, не следует изменять код (или данные)''<ref>For example, the [http://portal.acm.org/toc.cfm?id=1806799 32nd ACM/IEEE International Conference on Software Engineering] in Cape Town, South Africa in May 2010</ref>}}


== См. также ==
== См. также ==

Текущая версия от 12:20, 11 мая 2024

Программная археология — дисциплина, изучающая слабо документированное или недокументированное унаследованное программное обеспечение, в целях его сопровождения[1][2]. Программная археология включает в себя обратную разработку приложений, использование специальных инструментальных средств и технологических процессов для извлечения и понимания структуры кода, восстановления замысла его разработчиков[1][3]. Программная археология помогает обнаружить проблемы, связанные с неудачной архитектурой приложения и отмершим (неиспользуемым) кодом[4]. Термин используется уже несколько десятилетий[5] и отражает следующую метафору: разработчик, читающий код унаследованного программного обеспечения, ощущает себя так же, как и археолог, исследующий памятники древней цивилизации[6].

Инструменты и методы

[править | править код]

В 2001 году на конференции OOPSLA секция программной археологии определила следующие инструменты и методы программной археологии, некоторые из которых относятся к объектно-ориентированному программированию[6]:

В целях систематической трассировки вызовов функций без широкомасштабного редактирования кодовой базы исследуемого приложения можно успешно применять аспектно-ориентированное программирование (например, AspectJ[6] для Java, MrAdvice для C# .NET), разработав аспектные классы для получения средствами рефлексии информации о состоянии стека вызовов, отфильтровывания из него нужной информации и записи её в журнальный файл или окно протокола работы (т. н. лога) приложения.

При сопровождении экспертной системы важным источником информации о логике её работы являются сообщения подсистемы объяснений[7].

Энди Хант и Дейв Томас указывают на важность использования системы контроля версий, контейнера управления зависимостями, инструментов индексирования текста (GLIMPSE, SWISH-E) и «[составления] карты исследования»[6].

Подобно настоящей археологии, программная археология предполагает исследовательскую работу для понимания мыслительных процессов предшественников[6]. На секции OOPSLA Уорд Каннингем предложил так называемый «синоптический сигнатурный анализ», который дает в первом приближении понимание «духа» программы путём показа разработчику только лишь пунктуации кода (двоеточия, операторные скобки)[8]. Также Каннингем предложил рассматривать программы, напечатанные минимально возможным шрифтом, для понимания общей структуры программы[9].

Методы сетевого и временно́го анализа, расширение Git Archaeology для Microsoft Visual Studio могут помочь обнаружить шаблоны совместной деятельности разработчиков унаследованного ПО, которые, в свою очередь, могут пролить свет на силы и слабости получившегося в итоге кода[10].

Майкл Розлог из Embarcadero Technologies описал программную археологию как процесс из шести шагов, который позволяет разработчикам ответить на такие вопросы: «Что досталось мне в наследство?» и «В каких местах этот код ужасен?»[11] Эти шаги, как и обнаруженные секцией OOPSLA, включая визуализацию кода для понимания архитектуры приложения, используют метрики программного обеспечения для поиска нарушений принципов проектирования и стиля программирования, модульное тестирование и профилирование для поиска дефектов ПО (т. н. багов) и узких мест в производительности, а также сбор информации о структуре приложения, восстановленной в процессе программно-археологических раскопок[11]. Программная археология может также быть услугой, предоставляемой штатным разрабочикам внешними консультантами[12].

Митч Розенберг (InfoVentions.net) утверждает, что «первый закон программной археологии» звучит так:

Оно здесь находится не просто так, и причина может быть одна из трёх:

  1. Оно должно было быть здесь, но уже не должно.
  2. Ему не нужно было быть здесь, а программист, написавший это, не ведал, что творил.
  3. Оно всё еще должно быть здесь, и это Вы не ведаете, что творите.

Следствие этого «закона»: пока причина неизвестна, не следует изменять код (или данные)[13]

Примечания

[править | править код]
  1. 1 2 Gregorio Robles, Jesus M. Gonzalez-Barahona, and Israel Herraiz, «An Empirical Approach to Software Archaeology Архивная копия от 20 января 2020 на Wayback Machine, „ Poster Proceedings of the International Conference on Software Maintenance, 2005.
  2. Agile Legacy System Analysis and Integration Modeling Архивная копия от 23 марта 2021 на Wayback Machine» by Scott W. Ambler at agilemodeling.com, accessed 20 August 2010: "Without accurate documentation, or access to knowledgeable people, your last resort may be to analyze the source code for the legacy system.
  3. Richard Hopkins and Kevin Jenkins, Eating the IT Elephant: Moving from greenfield development to brownfield Архивная копия от 23 марта 2015 на Wayback Machine, Addison-Wesley, 2008, ISBN 0-13-713012-0, p. 93.
  4. Diomidis Spinellis and Georgios Gousios, Beautiful Architecture Архивная копия от 22 марта 2015 на Wayback Machine, O’Reilly, 2009, ISBN 0-596-51798-X, p. 29.
  5. An early discussion is Judith E. Grass, "Object-Oriented Design Archaeology with CIA++, " Computing Systems, Vol. 5, No. 1, Winter 1992.
  6. 1 2 3 4 5 Andy Hunt and Dave Thomas, «Software Archaeology Архивная копия от 9 ноября 2020 на Wayback Machine», IEEE Software, vol. 19, no. 2, pp. 20-22, Mar.
  7. Гаврилова Т. А., Хорошевский В. Ф. Базы знаний интеллектуальных систем. — СПб.: Питер, 2000..
  8. Ward Cunningham, «Signature Survey: A Method for Browsing Unfamiliar Code Архивная копия от 22 августа 2010 на Wayback Machine, „ Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001.
  9. Software Archeology Архивная копия от 6 марта 2012 на Wayback Machine» on John D. Cook’s blog The Endeavour, November 10, 2009.
  10. Cleidson de Souza, Jon Froehlich, and Paul Dourish, "Seeking the Source: Software Source Code as a Social and Technical Artifact Архивная копия от 23 сентября 2015 на Wayback Machine, " Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work, pp. 197—206.
  11. 1 2 Michael Rozlog, "Software Archeology: What Is It and Why Should Java Developers Care? Архивная копия от 13 июля 2015 на Wayback Machine, " article on java.sys-con.com, January 28, 2008.
  12. Simon Sharwood, Raiders of the Lost Code Архивная копия от 14 марта 2012 на Wayback Machine, ZDNet, November 3, 2004.
  13. For example, the 32nd ACM/IEEE International Conference on Software Engineering in Cape Town, South Africa in May 2010