소프트웨어 고고학

Software archaeology

소프트웨어 고고학 또는 소스 코드 고고학은 소프트웨어 [1][2]유지보수의 일부로서 문서화되어 있지 않거나 문서화되어 있지 않은 레거시 소프트웨어 구현에 대한 연구입니다.고고학과 유사하게 [3]명명된 소프트웨어 고고학은 소프트웨어 모듈의 역엔지니어링, 프로그램 구조를 추출하고 이해하고 설계 [1][4]정보를 복구하기 위한 다양한 도구와 프로세스의 적용을 포함한다.소프트웨어 고고학에서는 제대로 설계되지 않았거나 사용되지 않은 소프트웨어 모듈을 생산한 문제가 있는 팀 프로세스를 발견할 수 있으며, 경우에 따라서는 의도적으로 난독화 코드를 [5]발견할 수도 있습니다.이 용어는 수십 [6]년 동안 사용되어 왔고, 꽤 자연스러운 은유를 반영한다: 레거시 코드를 읽는 프로그래머는 고대 [7]문명의 잔해를 탐험하는 고고학자와 같은 상황에 있다고 느낄 수 있다.

기술

2001년 OOPSLA(Object-oriented Programming, Systems, Languages and Applications) 컨퍼런스에서 소프트웨어 고고학에 관한 워크숍에서 다음과 같은 소프트웨어 고고학 기법을 확인하였습니다.그 중 일부는 객체 지향 프로그래밍에 [7]특화되어 있습니다.

보다 일반적으로 Andy Hunt와 Dave Thomas는 버전 관리, 종속성 관리, 텍스트 색인 도구(예: LIEP 및 SWISH-E), 그리고 [7]탐색을 시작할 때 지도를 그리는 것이 중요하다고 지적합니다.

진정한 고고학처럼 소프트웨어 고고학도 [7]전임자들의 사고 과정을 이해하기 위한 조사 작업을 포함한다.OOPSLA 워크숍에서 워드 커닝햄은 세미콜론이나 [8]컬리브릿지처럼 구두점만 표시함으로써 프로그램의 전체적인 "느낌"을 주는 시놉틱 시그니처 분석 기법을 제안했다.같은 맥락에서 커닝햄은 전체적인 [9]구조를 이해하기 위해 프로그램을 2포인트 폰트로 볼 것을 제안했다.워크숍에서 확인된 또 다른 기술은 AspectJ와 같은 애스펙트 지향 프로그래밍 도구를 사용하여 레거시 프로그램을 [7]직접 편집하지 않고 트레이스 코드를 체계적으로 도입하는 것이었습니다.

네트워크 및 시간 분석 기술은 레거시 소프트웨어 개발자의 협업 활동 패턴을 밝혀낼 수 있으며,[10] 이는 생성된 소프트웨어 아티팩트의 장단점을 밝혀줄 수 있습니다.

Embacadero Technologies의 Michael Rozlog는 소프트웨어 고고학을 "내가 방금 물려받은 것은 무엇인가?"와 "코드의 무서운 부분은 어디에 있는가?"와 같은 질문에 대답할 수 있는 6단계 프로세스라고 설명했습니다.[11]이러한 절차에는 OOPSLA 워크숍에서 식별된 절차와 마찬가지로 시각화를 사용하여 프로그램 설계를 시각적으로 표현하고, 소프트웨어 메트릭을 사용하여 설계 및 스타일 위반을 찾아내고, 유닛 테스트와 프로파일링을 사용하여 버그 및 성능 병목 현상을 찾아내고, 프로페셔널이 복구한 설계 정보를 조립하는 것이 포함됩니다.소프트웨어 고고학은 외부 [12]컨설턴트에 의해 프로그래머에게 제공되는 서비스가 될 수도 있다.[11]

InfoVentions.net, Inc.의[citation needed] Mitch Rosenberg는 소프트웨어 고고학의 제1법칙(그는 이것을 코드 또는 데이터 고고학이라고 부릅니다)은 다음과 같습니다.

여기에 있는 모든 것에는 이유가 있으며, 다음과 같은 세 가지 이유가 있을 수 있습니다.

  1. 예전에는 있어야 했지만 지금은 필요 없다.
  2. 거기에 있을 필요도 없었고 코드를 작성한 사람은 전혀 몰랐습니다.
  3. 아직 거기 있어야 하는데 넌 전혀 몰라

이 "법칙"의 결론은 어떤 것이 원인인지 알 때까지 코드(또는 데이터)를 수정해서는 안 된다는 것입니다.

소프트웨어 고고학은 최근 소프트웨어 엔지니어링 [13]회의에서 계속 논의의 주제가 되고 있습니다.

프로그래머-고고학자의 직업은 Vernor Vinge의 A Deepness in the Sky에서 두드러지게 나타납니다.[14]

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Robles, Gregorio; Gonzalez-Barahona, Jesus M.; Herraiz, Israel (2005). "An Empirical Approach to Software Archaeology" (PDF). Poster Proceedings of the International Conference on Software Maintenance.
  2. ^ Ambler, Scott W. "Agile Legacy System Analysis and Integration Modeling". agilemodeling.com. Retrieved 2010-08-20. Without accurate documentation, or access to knowledgeable people, your last resort may be to analyze the source code for the legacy system... This effort is often referred to as software archaeology.
  3. ^ Moyer, Bryon (4 March 2009). "Software Archeology: Modernizing Old Systems" (PDF). Embedded Technology Journal.
  4. ^ Hopkins, Richard; Jenkins, Kevin (2008). "5. The Mythical Metaman". Eating the IT Elephant: Moving from greenfield development to brownfield. Addison-Wesley. p. 93. ISBN 978-0-13-713012-2.
  5. ^ Spinellis, Diomidis; Gousios, Georgios (2009). "2. A Tale of Two Systems § Lack of Cohesion". Beautiful Architecture. O'Reilly. p. 29. ISBN 978-0-596-51798-4.
  6. ^ 초기 논의는
  7. ^ a b c d e Hunt, Andy; Thomas, Dave (March–April 2002). "Software Archaeology" (PDF). IEEE Software. 19 (2): 20–22. doi:10.1109/52.991327.
  8. ^ Cunningham, Ward (2001). "Signature Survey: A Method for Browsing Unfamiliar Code". Workshop Position Statement, Software Archeology: Understanding Large Systems, OOPSLA 2001.
  9. ^ Cook, John D. (10 November 2009). "Software Archeology". The Endeavour.
  10. ^ de Souza, Cleidson; Froehlich, Jon; Dourish, Paul (2005). "Seeking the Source: Software Source Code as a Social and Technical Artifact" (PDF). Proceedings of the 2005 International ACM SIGGROUP Conference on Supporting Group Work. pp. 197–206. doi:10.1145/1099203.1099239. ISBN 1595932232.
  11. ^ a b Rozlog, Michael (28 January 2008). "Software Archeology: What Is It and Why Should Java Developers Care?". java.sys-con.com.
  12. ^ Sharwood, Simon (3 November 2004). "Raiders of the Lost Code". ZDNet.
  13. ^ 예를 들어, 입니다.
  14. ^ Rees, Gareth (2013-06-12). "Software archaeology and technical debt".

외부 링크