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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
(Показать все непатрулированные изменения)
[отпатрулированная версия][непроверенная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
м бот: добавление заголовков в сноски; исправление двойных сносок, см. ЧаВо
Нет описания правки
Метка: редактор вики-текста 2017
 
(не показано 45 промежуточных версий 19 участников)
Строка 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, ''[http://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, ''[http://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 или вики-формате
* Создание сопровождающей документации на API ([[Javadoc]], [[doxygen]]), добавление документирующих комментариев в кодовую базу приложения
* Сигнатурный анализ, статистический анализ, инструменты для визуализации ПО
* [[Сигнатурный анализ]], статистический анализ, инструменты для визуализации ПО
* Инструменты [[Обратная разработка|обратной разработки]]
* Инструменты [[Обратная разработка|обратной разработки]]
* Отслеживание системных вызовов (truss, strace)
* Отслеживание системных вызовов (truss, strace)
* Инструменты для поиска ключевых слов в файлах
* Инструменты для поиска ключевых слов в файлах
* Использование [[Интегрированная среда разработки|IDE]] для просмотра файлов
* Использование [[Интегрированная среда разработки|интегрированной среды разработки (IDE)]] для просмотра, поиска и редактирования файлов кода приложения
* Фреймворки для [[Модульное тестирование|модульного тестирования]] ([[JUnit]], CppUnit)
* Платформы для [[Модульное тестирование|модульного тестирования]] ([[JUnit]], CppUnit)
* [[Отладчик]]и и профилировщики
* Создание документации к API ([[Javadoc]], [[doxygen]])
* [[Отладчик|Отладчики]]


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


При сопровождении экспертной системы важным источником информации о логике её работы являются сообщения подсистемы объяснений<ref>{{Книга|автор=Гаврилова Т. А., Хорошевский В. Ф.|заглавие=Базы знаний интеллектуальных систем|ответственный=|год=2000.|издание=|место=СПб.|издательство=Питер|страницы=|страниц=|isbn=}}</ref>.
⚫
Подобно настоящей археологии, компьютерная археология предполагает исследовательскую работу для понимания мыслительных процессов предков.<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> Еще одной техникой, предложенной на секции, является использование инструментов [[Аспектно-ориентированное программирование|аспектно-ориентированного программирования]] (например, [[AspectJ]]) для систематического проведения [[Трассировка (программирование)|трассировки]] кода без прямого редактирования исследуемой программы.<ref name="AndyDave" />


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


⚫
Подобно настоящей археологии, программная археология предполагает исследовательскую работу для понимания мыслительных процессов предшественников<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>.
⚫
Майкл Розлог из [[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>


⚫
Методы сетевого и временно́го анализа, расширение [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>.
⚫
{{Шаблон:Якорь|DataArchaeology}}
⚫
Митч Розенберг из InfoVentions.net, Inc. утверждает, что "первый закон компьютерной археологии" звучит так:


⚫
Майкл Розлог из [[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}}
⚫
Митч Розенберг (InfoVentions.net) утверждает, что «первый закон программной археологии» звучит так:

{{Цитата|
''Оно здесь находится не просто так, и причина может быть одна из трёх:''
''Оно здесь находится не просто так, и причина может быть одна из трёх:''
# ''Оно должно было быть здесь, но уже не должно''
# ''Оно должно было быть здесь, но уже не должно''.
# ''Оно никогда не должно было быть здесь, программист, написавший это, не ведал, что творил''
# ''Ему не нужно было быть здесь, а программист, написавший это, не ведал, что творил''.
# ''Оно '''всё еще''' должно быть здесь, и это '''вы''' не ведаете, что творите''
# ''Оно '''всё еще''' должно быть здесь, и это '''Вы''' не ведаете, что творите''.
''Следствие этого "закона": пока причина неизвестна, не следует изменять код (или данные).''
''Следствие этого «закона»: пока причина неизвестна, не следует изменять код (или данные)''<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>}}


== См. также ==
== См. также ==
* [[Ретрокомпьютинг]]
* [[Рефакторинг]]
* [[Рефакторинг]]
* [[Abandonware]]
* [[Abandonware]]


== Ссылки ==
== Примечания ==
{{примечания}}
<references />

{{изолированная статья}}


[[Категория:Компьютерный сленг]]
[[Категория:Компьютерный сленг]]
[[Категория:Сопровождение программного обеспечения]]
[[Категория:Сопровождение программного обеспечения]]
[[Категория:Ретрокомпьютинг]]

Текущая версия от 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
Источник — https://ru.wikipedia.org/w/index.php?title=Программная_археология&oldid=137730543