Программная археология: различия между версиями
[отпатрулированная версия] | [отпатрулированная версия] |
Saramag (обсуждение | вклад) |
KrBot (обсуждение | вклад) м - {{изолированная статья}} |
||
Строка 39: | Строка 39: | ||
== Ссылки == |
== Ссылки == |
||
{{примечания}} |
{{примечания}} |
||
{{изолированная статья}} |
|||
[[Категория:Компьютерный сленг]] |
[[Категория:Компьютерный сленг]] |
Версия от 21:30, 7 августа 2015
Эту страницу предлагается переименовать. |
Компьютерная археология – дисциплина, изучающая плохо документированное или недокументированное устаревшее программное обеспечение, в целях его сопровождения.[1][2] Компьютерная археология включает в себя обратную разработку программ, использование множества инструментов и процессов для извлечения и понимания структуры программы и восстановления замысла разработчиков.[1][3] Компьютерная археология может обнаружить проблемы, связанные с плохой архитектурой приложения и неиспользуемым кодом.[4] Термин используется уже несколько десятилетий[5] и отражает следующую метафору: программист, читающий устаревшее программное обеспечение, ощущает себя так же, как и археолог, исследующий руины древней цивилизации.[6]
Инструменты и методы
В 2001 году на конференции OOPSLA секция компьютерной археологии определила следующие инструменты и методы компьютерной археологии, некоторые из которых относятся к объектно-ориентированному программированию:[6]
- Скриптовые языки для создания статических отчетов и фильтрации отладочного вывода
- Сопровождающая документация в HTML или вики-формате
- Сигнатурный анализ, статистический анализ, инструменты для визуализации ПО
- Инструменты обратной разработки
- Отслеживание системных вызовов (truss, strace)
- Инструменты для поиска ключевых слов в файлах
- Использование IDE для просмотра файлов
- Фреймворки для модульного тестирования (JUnit, CppUnit)
- Создание документации к API (Javadoc, doxygen)
- Отладчики
Энди Хант и Дейв Томас указывают на важность контроля версий, управления зависимостями, инструментов индексирования текста (GLIMPSE, SWISH-E) и «[составления] карты исследования».[6]
Подобно настоящей археологии, компьютерная археология предполагает исследовательскую работу для понимания мыслительных процессов предков.[6] На секции OOPSLA Уорд Каннингем предложил так называемый «синоптический сигнатурный анализ», который дает понимание «духа» программы путем показывания программисту только лишь пунктуации кода (двоеточия, операторные скобки).[7] Также Каннингем предложил рассматривать программы, напечатанные минимально возможным шрифтом для понимания общей структуры программы.[8] Еще одной техникой, предложенной на секции, является использование инструментов аспектно-ориентированного программирования (например, AspectJ) для систематического проведения трассировки кода без прямого редактирования исследуемой программы.[6]
Техники сетевого и временно́го анализа могут обнаружить шаблоны совместной деятельности разработчиков устаревшего ПО, которые, в свою очередь, могут пролить свет на силы и слабости получившегося в итоге кода.[9]
Майкл Розлог из Embarcadero Technologies описал компьютерную археологию как процесс из шести шагов, который позволяет программистам ответить на такие вопросы как «Что досталось мне в наследство?» и «В каких местах этот код ужасен?»[10] Эти шаги, как и обнаруженные секцией OOPSLA, включая визуализацию кода для понимания архитектуры программы, используют метрики программного обеспечения для поиска нарушений дизайна и стиля программирования, модульное тестирование и профилирования для поиска багов и узких мест в производительности, и сбор информации о структуре приложения, восстановленной в процессе.[10] Компьютерная археология может также быть услугой, предоставляемой программистам внешними консультантами.[11]
Митч Розенберг из InfoVentions.net, Inc. утверждает, что «первый закон компьютерной археологии» звучит так:
Оно здесь находится не просто так, и причина может быть одна из трёх:
- Оно должно было быть здесь, но уже не должно.
- Оно никогда не должно было быть здесь, программист, написавший это, не ведал, что творил.
- Оно всё еще должно быть здесь, и это вы не ведаете, что творите.
Следствие этого «закона»: пока причина неизвестна, не следует изменять код (или данные).[12]
См. также
Ссылки
- ↑ 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.
- ↑ “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.
- ↑ 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.
- ↑ Diomidis Spinellis and Georgios Gousios, Beautiful Architecture, O’Reilly, 2009, ISBN 0-596-51798-X, p. 29.
- ↑ An early discussion is Judith E. Grass, "Object-Oriented Design Archaeology with CIA++, " Computing Systems, Vol. 5, No. 1, Winter 1992.
- ↑ 1 2 3 4 5 Andy Hunt and Dave Thomas, «Software Archaeology», IEEE Software, vol. 19, no. 2, pp. 20-22, Mar.
- ↑ Ward Cunningham, «Signature Survey: A Method for Browsing Unfamiliar Code, „ Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001.
- ↑ “Software Archeology» on John D. Cook’s blog The Endeavour, November 10, 2009.
- ↑ 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.
- ↑ 1 2 Michael Rozlog, "Software Archeology: What Is It and Why Should Java Developers Care?, " article on java.sys-con.com, January 28, 2008.
- ↑ Simon Sharwood, Raiders of the Lost Code, ZDNet, November 3, 2004.
- ↑ For example, the 32nd ACM/IEEE International Conference on Software Engineering in Cape Town, South Africa in May 2010