Программная археология: различия между версиями
[непроверенная версия] | [непроверенная версия] |
→Инструменты и методы: добавление ссылки на проект |
→Инструменты и методы: был пропущен пробел |
||
Строка 22: | Строка 22: | ||
Методы сетевого и временно́го анализа, расширение [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], " 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?], " 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>. |
||
{{Якорь|DataArchaeology}} |
{{Якорь|DataArchaeology}} |
Версия от 11:13, 3 декабря 2020
Программная археология — дисциплина, изучающая слабо документированное или недокументированное унаследованное программное обеспечение, в целях его сопровождения[1][2]. Компьютерная археология включает в себя обратную разработку приложений, использование инструментальных средств и технологических процессов для извлечения и понимания структуры кода, восстановления замысла его разработчиков[1][3]. Компьютерная археология может обнаружить проблемы, связанные с неудачной архитектурой приложения и отмершим (неиспользуемым) кодом[4]. Термин используется уже несколько десятилетий[5] и отражает следующую метафору: программист, читающий унаследованное программное обеспечение, ощущает себя так же, как и археолог, исследующий памятники древней цивилизации[6].
Инструменты и методы
В 2001 году на конференции OOPSLA секция программной археологии определила следующие инструменты и методы программной археологии, некоторые из которых относятся к объектно-ориентированному программированию[6]:
- Скриптовые языки для создания статических отчетов и фильтрации отладочного вывода
- Изучение существующей сопровождающей документации в формате HTML, PDF, CHM, MSHC или Wiki
- Создание сопровождающей документации на API (Javadoc, doxygen), добавление документирующих комментариев в кодовую базу приложения
- Сигнатурный анализ, статистический анализ, инструменты для визуализации ПО
- Инструменты обратной разработки
- Отслеживание системных вызовов (truss, strace)
- Инструменты для поиска ключевых слов в файлах
- Использование интегрированной среды разработки (IDE) для просмотра, поиска и редактирования файлов кода приложения
- Платформы для модульного тестирования (JUnit, CppUnit)
- Отладчики и профилировщики
В целях систематической трассировки вызовов функций без широкомасштабного редактирования кодовой базы исследуемого приложения можно успешно применять аспектно-ориентированное программирование (например, AspectJ[6] для Java, MrAdvice для C# .NET), разработав аспектные классы для получения средствами рефлексии информации о состоянии стека вызовов, отфильтровывания из него нужной информации и записи ее в журнальный файл или окно протокола работы (т.н. лога) приложения.
Энди Хант и Дейв Томас указывают на важность использования системы контроля версий, контейнера управления зависимостями, инструментов индексирования текста (GLIMPSE, SWISH-E) и «[составления] карты исследования»[6].
Подобно настоящей археологии, программная археология предполагает исследовательскую работу для понимания мыслительных процессов предшественников[6]. На секции OOPSLA Уорд Каннингем предложил так называемый «синоптический сигнатурный анализ», который дает в первом приближении понимание «духа» программы путём показа разработчику только лишь пунктуации кода (двоеточия, операторные скобки)[7]. Также Каннингем предложил рассматривать программы, напечатанные минимально возможным шрифтом, для понимания общей структуры программы[8].
Методы сетевого и временно́го анализа, расширение Git Archaeology для Microsoft Visual Studio могут помочь обнаружить шаблоны совместной деятельности разработчиков унаследованного ПО, которые, в свою очередь, могут пролить свет на силы и слабости получившегося в итоге кода[9].
Майкл Розлог из Embarcadero Technologies описал программную археологию как процесс из шести шагов, который позволяет разработчикам ответить на такие вопросы: «Что досталось мне в наследство?» и «В каких местах этот код ужасен?»[10] Эти шаги, как и обнаруженные секцией OOPSLA, включая визуализацию кода для понимания архитектуры приложения, используют метрики программного обеспечения для поиска нарушений принципов проектирования и стиля программирования, модульное тестирование и профилирование для поиска дефектов ПО (т.н. багов) и узких мест в производительности, а также сбор информации о структуре приложения, восстановленной в процессе[10] программно-археологических раскопок. Программная археология может также быть услугой, предоставляемой штатным разрабочикам внешними консультантами[11].
Митч Розенберг (InfoVentions.net) утверждает, что «первый закон программной археологии» звучит так:
Оно здесь находится не просто так, и причина может быть одна из трёх:
- Оно должно было быть здесь, но уже не должно.
- Ему не нужно было быть здесь, а программист, написавший это, не ведал, что творил.
- Оно всё еще должно быть здесь, и это Вы не ведаете, что творите.
Следствие этого «закона»: пока причина неизвестна, не следует изменять код (или данные)[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