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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[непроверенная версия][отпатрулированная версия]
Содержимое удалено Содержимое добавлено
оформление
Строка 5: Строка 5:
* [[Сценарный язык|Скриптовые языки]] для создания статических отчетов и фильтрации отладочного вывода
* [[Сценарный язык|Скриптовые языки]] для создания статических отчетов и фильтрации отладочного вывода
* Сопровождающая документация в HTML или вики-формате
* Сопровождающая документация в HTML или вики-формате
* [[Сигнатурный анализ|Сигнатурный анализ]], статистический анализ, инструменты для визуализации ПО
* [[Сигнатурный анализ]], статистический анализ, инструменты для визуализации ПО
* Инструменты [[Обратная разработка|обратной разработки]]
* Инструменты [[Обратная разработка|обратной разработки]]
* Отслеживание системных вызовов (truss, strace)
* Отслеживание системных вызовов (truss, strace)
Строка 37: Строка 37:
* [[Abandonware]]
* [[Abandonware]]


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



Версия от 21:51, 22 июня 2016

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

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

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

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

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

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

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

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

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

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

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

.

См. также

Примечания

  1. 1 2 Gregorio Robles, Jesus M. Gonzalez-Barahona, and Israel Herraiz, «An Empirical Approach to Software Archaeology, „ Poster Proceedings of the International Conference on Software Maintenance, 2005.
  2. 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.
  3. Richard Hopkins and Kevin Jenkins, Eating the IT Elephant: Moving from greenfield development to brownfield, Addison-Wesley, 2008, ISBN 0-13-713012-0, p. 93.
  4. Diomidis Spinellis and Georgios Gousios, Beautiful Architecture, 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», IEEE Software, vol. 19, no. 2, pp. 20-22, Mar.
  7. Ward Cunningham, «Signature Survey: A Method for Browsing Unfamiliar Code, „ Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001.
  8. Software Archeology» on John D. Cook’s blog The Endeavour, November 10, 2009.
  9. Cleidson de Souza, Jon Froehlich, and Paul Dourish, "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.
  10. 1 2 Michael Rozlog, "Software Archeology: What Is It and Why Should Java Developers Care?, " article on java.sys-con.com, January 28, 2008.
  11. Simon Sharwood, Raiders of the Lost Code, ZDNet, November 3, 2004.
  12. For example, the 32nd ACM/IEEE International Conference on Software Engineering in Cape Town, South Africa in May 2010