code refactoring what you need know about it
코드 리팩토링 이해 : 테스터의 관점
'리팩토링'이라는 용어는 주로 필요한 코드 정리 / 재 설계를 나타내는 데 사용됩니다.
이 튜토리얼에서는 리팩토링의 정의를 이해하고, 코드 리팩토링의 필요성을 논의하고, 리팩토링 코드가 다양한 프로젝트 팀 구성원에게 미치는 영향을 검토합니다. 또한 가장 중요한 질문에 대한 답에 대해서도 논의 할 것입니다. 테스터로서 리팩토링에 대해 알아야하는 이유는 무엇입니까?
PL SQL 개발자 인터뷰 질문 및 답변
또한 개념을 명확히하기 위해 몇 가지 사례 연구에 대해서도 논의 할 것입니다.
학습 내용 :
리팩토링 소개
우선, 실제로 리팩토링이 무엇인지 먼저 이해합시다.
리팩토링은 기본적으로 기존 기능을 유지하면서 코드 및 / 또는 데이터베이스를 개선하는 관행 또는 프로세스입니다. 아이디어는 비효율적이고 지나치게 복잡한 코드를 더 효율적이고, 가급적이면 더 간단하고 쉬운 코드로 변환하는 것입니다.
코드 리팩토링은 애자일 소프트웨어 개발 접근 방식을 따름으로써 더 많은 팀과 함께 추진력을 얻었습니다. 프로젝트 팀은 종종 새로운 기능을 구현하거나 기존 기능 및 깨끗한 코드의 기능을 확장 할 시간이 제한되어 있습니다. 이해하고 유지하기 쉬운 코드는 확실히 반복 마감일을 맞추는 데 큰 도움이됩니다.
코드 리팩토링의 필요성
응용 프로그램이나 모듈의 원래 기능을 유지하고 있다면 왜 리팩토링을해야합니까?라는 질문이 생깁니다. 특정 모듈이나 코드를 리팩토링해야하는 이유는 다음과 같습니다.
- 코드 냄새
- 기술 부채
- 애자일 소프트웨어 개발 접근 방식 등
다음 섹션에서 이러한 사항에 대해 자세히 설명합니다.
# 1) 코드 냄새 :
음식에서 냄새가 나기 시작하면 음식이 나빠질 가능성이 가장 높다는 것을 우리 모두 이해할 수 있습니다. 이것은 코드에서도 마찬가지입니다! 코드 냄새는 코드에 심각한 문제가있을 수 있음을 나타냅니다.
다음은 몇 가지 일반적인 코드 냄새입니다.
- 중복되거나 동일한 코드가 있습니다.
- 나머지 코드에서 사용되지 않는 선언 된 변수입니다.
- 복잡한 코드 디자인.
- 너무 적게 수행하고 정의 된 클래스의 존재를 정당화하지 않는 코드 클래스입니다. 이러한 클래스를 lazy 클래스 또는 freeloader라고합니다.
- 세분화되고 단순화 될 가능성이있는 너무 많은 조건 및 루프의 존재.
- 코드의 한 부분이 변경되면 다른 부분에서도 변경 사항을 구현해야하는 방식으로 코드가 빌드됩니다.
코드 냄새는 시간이 지날수록 더 분명해집니다. 애플리케이션 또는 시스템이 성장함에 따라 결국 이러한 코드 냄새가 코드 개발, 유지 관리 및 극단적 인 시나리오의 시스템 성능에 영향을 미치기 시작합니다.
# 2) 기술 부채 :
소프트웨어를 개발하는 동안 제한된 시간과 리소스를 사용할 때 원하는 결과를 얻기 위해 지름길을 택할 수 있습니다.
기존 모듈에 추가해야하는 기능을 고려하십시오. 토론 후 팀은이 기능을 추가하기 위해 두 가지 접근 방식을 좁 힙니다. 접근 방식 A는 2 개의 스프린트를 사용하여 승인 된 장기 접근 방식입니다. 접근 방식 B는 단 5 일만에 모듈을 서비스하도록 설계된 복잡한 하드 코딩 된 해킹입니다.
팀이 제한된 시간 내에 기능을 제공해야하는 압력을 받고 있다면 지금은 접근 방식 B를 따르고 미래를 위해 접근 방식 A를 백 로그에 추가하는 데 동의 할 수 있습니다. 이렇게함으로써이 팀은 기술 부채를 스스로 만들었습니다.
간단히 말해서, 소프트웨어 개발의 기술적 부채는 적절한 수정 사항을 적용하거나 '올바른 방식'으로 작업을 수행하는 데 필요한 추가 재 작업 또는 오버 헤드를 의미합니다.
레거시 시스템은 시간이 지남에 따라 막대한 기술적 부채를 획득하는 경향이 있으며 이로 인해 애플리케이션이 실패하기 쉽고 지원 및 유지 관리가 어려울 수 있습니다.
더 읽어보기=> 기술 부서는 무엇입니까
# 3) 애자일 소프트웨어 개발 접근 방식 따르기 :
애자일 소프트웨어 개발 접근 방식은 점진적 개발을지지합니다. 깔끔하고 체계적이며 유지 관리가 쉬운 코드가 없으면 팀이 반복 할 때마다 기존 코드를 확장 할 수 없습니다. 적절한 리팩토링없이 코드가 변경되면 코드 냄새 나 기술적 부채에 기여할 수 있습니다.
이 관계는 아래 다이어그램에 설명되어 있습니다.
추천 읽기 => 최고의 코드 분석 도구
QA가 리팩토링에 대해 알아야하는 이유는 무엇입니까?
지금까지이 튜토리얼에서 논의한 내용은 코딩과 관련된 것으로 보이며 개발자가 걱정해야하는 종류의 것 같습니다.
그렇다면 소프트웨어 테스팅 도움말 커뮤니티에서이 관련없는 개념을 논의하는 이유는 무엇입니까? 이 질문에 대한 답은이 튜토리얼의 나머지 부분을 계속 읽으십시오.
# 1) 단위 테스터 / 개발자 용
코드를 리팩토링하는 동안 새 코드가 삽입됨에 따라 이전 클래스가 업데이트되고 새 클래스가 추가되며 기존 단위 테스트가 이제 실패 할 수 있습니다. 또한 레거시 시스템의 경우 단위 테스트가 전혀 구현되지 않을 수 있습니다. 이 새로운 단위 테스트는 대부분의 경우 처음부터 생성 및 설정해야합니다.
# 2) 테스터 용
기능이 리팩터링 될 때 (새 기능을 추가하지 않는다는 점을 고려할 때), 필요한 변경이 완료된 후에도 최종 사용자를위한 기능의 대부분은 동일하게 유지되어야합니다.
- 테스터로서 코드 리팩토링은 대략 = 심층 테스트 + 회귀 테스트로 해석됩니다. 모든 기능이 이전과 같이 작동하는지 확인하려면 심층 테스트에 모든 기존 사용자 흐름이 포함되어야합니다. 회귀 테스트 모듈을 업그레이드해도 다른 모듈의 기능이 의도 치 않게 중단되지 않도록 전체 애플리케이션 (또는 영향을받는 영역)의
- 사용자 승인 테스트는 중요하며 이러한 테스트는 빌드가 출시 준비 상태로 선언되기 전에 통과해야합니다.
- 또한 부하 테스트와 같은 다른 테스트가 필요합니다. 보안 테스트 등도 필요에 따라 구현해야합니다.
# 3) 자동화 테스트 엔지니어
코드를 리팩토링하면 기능 및 비 기능 자동화 스크립트가 실패 할 수 있습니다.
이는 다음과 같은 이유로 발생할 수 있습니다.
- 페이지 개체가 리팩토링 작업의 일부로 변경되고 Selenium 자동화 스크립트가 페이지 개체에 의존하는 경우 스크립트가 실패하고 업데이트해야합니다.
- 사소한 변경 사항이있는 경우 리팩토링 중에 추가 또는 제거 된 항목을 리디렉션하고 기존 자동화 스크립트가 실패하고 업데이트해야합니다.
기능 자동화 테스트는 기능이 안정된 후에 만 설정하는 것이 좋습니다. 그렇지 않으면 기능이 발전함에 따라 많은 재 작업이 발생합니다.
자동화 테스트 개발자이기 때문에 자동화 테스트 엔지니어는 개발자처럼 생각하고 깔끔하고 유지하기 쉬운 코드를 만드는 것을 목표로해야합니다. IntelliJ IDEA, Eclipse 등과 같은 대부분의 IDE에는 쉽게 참조 할 수 있도록 일반적으로 사용되는 리팩토링 방법이 포함 된 내장 리팩토링 메뉴가 포함되어 있습니다.
아래는 IntelliJ IDEA (커뮤니티 에디션)의 리팩토링 메뉴 스크린 샷입니다.
# 4) 테스트 리드 / QA 리드 용
- 테스트 리드 / QA 리드는 개발자, 제품 분석가 및 이해 관계자를 포함한 나머지 팀과 협력하여 해당 프로젝트에 대한 테스트 계획이 신중하게 수행되도록해야 할 수 있습니다.
- 기존 기능을 이해하는 것이 중요합니다. 기존 기능을 기반으로 비즈니스 사례, 사용자 흐름 및 사용자 승인 테스트를 문서화해야합니다. 리팩터링 된 코드를 테스트 할 때 영향을받는 영역의 회귀 테스트와 함께 이러한 모든 시나리오의 유효성을 검사해야합니다.
- 테스트 접근 방식을 계획하고 테스트 계획 . 여러 테스트 환경이나 새로운 테스트 도구의 요구 사항이 예상되는 경우 테스트 단계가 시작된 후 지연을 방지하기 위해 요청서를 일찍 보내십시오.
- 프로젝트 팀이 아닌 구성원이나 최종 사용자가 테스트에 참여하도록 주저하지 마십시오.
사례 연구
이제 직접 작업하거나 간접적으로 기여할 기회가 있었던 실제 사례 연구에 대해 논의하겠습니다.
사례 연구 # 1
직무: 모듈을 리팩터링하여 하드 코딩 된 값을 변수로 바꾸고 새로운 자동 기술 문서 생성 도구에 대한 설명을 추가합니다.
도전 :큰 도전이 없습니다. 이 모듈은 새로운 것으로 기능 및 사용자 수용 요구 사항, 사용자 흐름 및 테스트 사례를 문서화했습니다. 단위 테스트는 초기 출시 과정에서 설정되었습니다.
접근 방식 테스트 :리팩토링중인 모듈과 상대적으로 알려진 영향을받는 영역에 대한 테스트 케이스가 실행되었습니다. 릴리스 전에 모든 결함이보고되고 해결되었습니다.
사례 연구 # 2
직무 :기존 저장 프로 시저를 리팩터링하여 애플리케이션 확장을 용이하게합니다.
이 시나리오의 저장 프로시 저는 응용 프로그램이 동시 세션이 10 개 미만인 내부 응용 프로그램으로 저장 프로 시저를 사용해야한다는 요구 사항을 염두에두고 몇 년 전에 설계된 이전 저장 프로 시저입니다.
이제이 회사는이 애플리케이션을 SaaS (Software as a Service)로 마케팅하기를 원했습니다. 처음에는 300 개의 동시 세션이 예상됩니다.
팀은 몇 가지 초기 부하 테스트를 수행하고 25 개의 동시 세션 부하로 인해 시스템이 중단된다는 결론을 내 렸습니다. 팀은 코드를 검토하고 애플리케이션이 중단없이 최대 500 개의 동시 세션을 확장하고 지원할 수있는 기존 핵심 저장 프로 시저 하나를 리팩토링 할 것을 권장했습니다.
이 저장 프로 시저로 식별 된 일부 문제는 단일 쿼리 내의 여러 하위 쿼리, 테이블 대신 뷰와의 과도한 조인, 특정 열을 선택하는 대신 select * 사용 등이었습니다. 이러한 코딩 문제로 인해 응용 프로그램은 그보다 더 많은 데이터를 가져 왔습니다. 정말 필요했기 때문에 응용 프로그램이 느려지고 결국 충돌이 발생했습니다.
과제 :
# 1) 프로젝트 관리자 / 제품 분석가
- 요구 사항 수집 –이 저장 프로시 저는 레거시 코드이므로 모듈이 처음 설계 될 때 문서화 된 요구 사항이 없었습니다. 또한 지난 몇 년 동안 수행 된 반복의 경우 모듈에서 추가 또는 제거 된 비즈니스 규칙 및 논리를 나타내는 변경 로그가 없었습니다.
- 프로젝트 일정 – 요구 사항이 명확하게 정의되지 않았고 코드 종속성이 아직 완전히 식별되지 않았기 때문에 임시 일정을 전달하기가 어려웠습니다.
# 2) 개발자 용
- 명확한 요구 사항 및 비즈니스 규칙이 없습니다.
- 기능을 잃지 않고 코드를 정리합니다.
- 알려지지 않은 영향을받는 영역 및 / 또는 코드 종속성.
- 구체적인 개발 시간 추정치를 제공 할 수 없습니다.
- 새 단위 테스트를 만들어야합니다.
# 3) 테스터 용
- 명확한 요구 사항과 비즈니스 규칙이 없으면 테스트 계획에 영향을줍니다.
- 알려지지 않은 영향을받는 영역은 특히 회귀 테스트의 경우 테스트 계획에 영향을줍니다.
- 구체적인 테스트 예상치를 제공 할 수 없습니다.
# 4) 이해 관계자
- 명확하게 문서화 된 요구 사항 및 / 또는 사용자 흐름의 부족 + 촉박 한 기한 = 실패 위험이 높습니다.
위험을 완화하고 문제를 해결하기 위해 팀이 따르는 접근 방식 :
(i) 팀은 요구 사항을 수집하기 위해 협업 방식을 따랐습니다. : 프로젝트 관리자 / 제품 분석가 및 테스터는 내부 최종 사용자와 긴밀히 협력하여 주요 기능 및 사용자 흐름을 이해하고 문서화했습니다.
개발자는 또한 코드를 검토하고 요구 사항 문서에 관련 정보를 추가했습니다. 이것은 스프린트 시작일 전에 이루어졌습니다.
(ii) 구현중인 변경 사항을 테스트하기 위해 대체 테스트 환경이 만들어졌습니다. : 이러한 환경을 Gamma 및 Phi라고하겠습니다. Gamma에는 이전 코드가 있고 Phi는 항상 최신 리팩터링 된 저장 프로 시저를 배포했습니다.
2 개의 테스트 환경을 병렬로 구성하고 접근 전후에 거의 재창조함으로써 팀은이 2 개의 테스트 환경에서 동작을 비교하여보다 심층적이고 탐색적인 테스트를 수행 할 수 있었으며 가능한 버그를 식별 할 수있었습니다.
팀은 스프린트 시작일 이전에 제공된 대체 테스트 환경에 대한 요구 사항을 제공했습니다.
(iii) 초기 테스트에 참여한 최종 사용자 및 이해 당사자 : 명백한 문제가 발견되어 팀이 필요한 수정 사항을 배포하고 테스트하는 데 더 많은 시간을 할애 할 수 있도록 일찍보고되었습니다.
(iv) 종료 기준 정의 및 준수 : 종료 기준은 초기 계획 단계에서 정의되었습니다. 80 % 사용자 흐름 테스트, 해결되지 않은 중요한 버그 없음, 릴리스 전에 이해 관계자의 데모 및 승인을 받았습니다.
(v) 임시 출시 날짜 설정 : 릴리스 날짜를 조정하고 팀이 공통 엔드 포인트를 향해 작업하도록 동기를 부여합니다. 프로젝트의 범위에 따라 팀이 프로젝트를 실행하는 데 충분한 시간을 확보 할 수 있도록 정규 2 주 스프린트 대신 3 주 스프린트를 따르는 것이 좋습니다.
결론
요약하면 코드 리팩토링은 기능을 변경하지 않고 모듈의 디자인을 정리 / 단순화하는 프로세스입니다. 리팩토링 프로세스는 주석 추가, 올바른 들여 쓰기 추가, 정적 변수 제거 등과 같이 간단 할 수 있으며 복잡한 레거시 시스템의 경우 복잡 할 수 있습니다.
특정 모듈 또는 코드 조각은 코드 냄새, 기술 부채 또는 애자일 소프트웨어 개발 접근 방식에 따라 리팩토링해야 할 수 있습니다.
테스터에게 코드 리팩토링은 대략적으로 = 심층 테스트 + 회귀 테스트로 해석됩니다.
모든 기능이 이전과 같이 작동하는지 확인하기 위해 모든 기존 사용자 흐름을 테스트하려면 심층적 인 테스트가 필요합니다. 전체 애플리케이션 (또는 영향을받는 영역)에 대한 회귀 테스트는 모듈 업그레이드로 인해 다른 모듈의 기능이 의도 치 않게 중단되지 않았는지 확인하는 데 필요합니다.
테스트 리드 / QA 리드는 특히 레거시 프로젝트의 경우 개발자, 제품 분석가를 포함한 나머지 팀과 협력해야 할 수 있습니다. 테스트 접근 방식 및 테스트 계획을 계획하는 동안 사전 대응하십시오. 여러 테스트 환경 또는 새로운 테스트 도구의 요구 사항이 예상되는 경우 테스트 단계가 시작된 후 지연을 방지하기 위해 요청서를 일찍 보내십시오.
저자 정보 : 이 유익한 자습서는 Neha B가 작성했습니다. 그녀는 현재 품질 보증 관리자로 일하고 있으며 사내 및 해외 QA 팀을 이끌고 관리하는 일을 전문으로합니다.
코드 또는 모듈 / 애플리케이션의 리팩토링을 포함하는 까다로운 프로젝트에서 작업 했습니까? 그렇다면 동료 테스터가 배울 수 있도록 의견 섹션에서 경험을 자유롭게 공유하십시오.