대형 소프트웨어 재 구성 에 대한 생각

원문 연결: http://www.debuggingnow.com/blog/2009/12/some-thoughts-on-large-scaled-software-refactoring.html
     현재 이 프로젝트 를 하 는 것 도 1 년 반 이 다 되 어 갑 니 다. 돌 이 켜 보면 전년 도 에는 재 구성 을 하고 있 었 고 그 다음 해 에는 새로운 제품 을 만 들 고 있 었 습 니 다.재 구성 할 때 배 운 것들 을 조금 정리 해 보 자.
재 구성 은 서로 다른 목표 일 수 있다. 어떤 사람들 은 코드 를 더욱 합 리 적 이 고 아름 답 게 재 구성 하기 위해 서 이다.다른 사람들 은 특정한 기능 을 실현 하기 위해 서 일 수도 있다.재 구성 도 정도 가 다르다. 어떤 것 은 함수, 클래스 단계 에서 만 수정 을 할 수 있 고 어떤 것 은 전체적인 구조, 모듈 에 대해 변동 을 해 야 한다.또한 재 구성 에 대한 투입 도 크게 다르다. 어떤 것 은 나 쁜 코드 나 디자인 을 만 났 을 때 만 수정 하고 어떤 것 은 한 팀 을 구성 하 는 데 많은 시간 을 들 여 재 구성 을 한다.
기본 개념 에 대한 정확 한 정 의 는 모든 토론 의 기초 이다. 여기 서 토론 하 는 재 구성 은 '특정한 기능 을 실현 하기 위해 전문 적 으로 진행 하 는 대규모 코드 변경' 이다.
구조 설계, 얼마나 멀리 볼 수 있 습 니까?
간단하게 말하자면 우리 가 해 야 할 일 은 하나의 소프트웨어 의 UI 코드 와 핵심 기능 을 철저히 분리 한 다음 에 핵심 부분 을 하나의 단독 제품 으로 만 드 는 것 이다.물론 이런 표현 층 과 업무 층 이 분리 되 어야 한 다 는 이 치 는 누구나 다 알 고 있 습 니 다. 당초 의 구조 에 도 이런 개념 이 들 어 갔 지만 엄격 한 요구 가 없 었 기 때문에 핵심 부분 을 따로 꺼 내지 않 았 습 니 다. 최근 10 년 동안 의 개발 을 통 해 코드 중의 핵 심 층 이 UI 에 대한 의존 이 상당히 심각 하고 정태 적 이 며 소스 코드 컴 파일 에 대한 의존 도 있 습 니 다.동적, 운행 시 의존 도 있다.이 럴 때 핵심 기능 을 추출 하 는 것 은 상당히 어렵 고 시간 이 걸 리 는 것 임 에 틀림없다.현재 인터넷 의 일부 오픈 소스 CAD 소프트웨어 를 보면 처음부터 명확 한 코어 - UI 구분 이 있 고 핵심 모드 나 UI 모드 에서 실행 할 수 있 는 경우 가 많다.예 를 들 어 FreeCAD.만약 에 그 당시 의 구조 사가 이 단 계 를 생각 할 수 있다 면 처음부터 명확 하 게 구분 할 수 있다. 분명 한 것 은 1. 후기 에 그렇게 많은 인력 과 물력 을 쓸 필요 가 없다 는 것 이다.2. 그 품질, 디자인 이 많이 좋아 질 것 입 니 다.
물론 이것 도 반드시 원 견 이 부족 한 것 은 아니다. 일단 상업 이익 과 결합 해서 고려 하면 많은 좋 은 디자인 은 포기 할 수 밖 에 없다.예 를 들 어, 당신 의 제품 은 윈도 사용 자 를 대상 으로 하 는 것 이 고, 프로젝트 팀 은 모두 윈도 프로그래머 입 니 다. - 더 빨리 제품 을 출시 하기 위해 서 는 크로스 플랫폼 을 고려 하지 않 겠 죠? - 그런데 10 년 후에 맏형 들 이 맥 에 진출 하기 로 결 정 했 습 니 다 ~ ~ 그 러 니까 이것 도 최선 을 다 하고 차 일 드 를 들 으 세 요.
작업 모드
반드시 단독 branch 를 열 어야 한다.이렇게 하면 너 는 문 을 닫 고 하고 싶 은 대로 할 수 있어 서 다른 팀 에 영향 을 주지 않 을 것 이다.여기 서 하고 싶 은 대로 하 는 것 은:

Build Errors 허용

       아주 큰 code base 이기 때문에 당신 의 어 딘 가 수정 은 다른 곳 에서 컴 파일 오 류 를 초래 하거나 script 으로 수정 한 범위 가 매우 넓 을 수 있 습 니 다. 이 컴퓨터 에서 완전한 build 를 하 는 데 반나절 이 걸 릴 수 있 습 니 다. (맞 습 니 다. 즉, 사용 IncrediBuild 체크 인 후에 서버 에 build 를 도와 달라 고 하 세 요. 당신 은 계속 일 할 수 있 습 니 다. build error 가 몇 개 있 습 니 다. 괜 찮 습 니 다!

Regression 은 정상

매번 체크인 하기 전에 자동화 테스트 같은 거 안 뛰 어도 돼 요.
물론 이런 자 유 는 많은 경우 에 제창 되 지 않 지만 여기 서 는 효율 을 크게 높 였 다.
또한 재 구축 의 변 동량 이 매우 크기 때문에 main 또는 trunk branck 와 자주 sync 를 하고 1 차 변동 을 받 아들 일 수 있 는 범위 내 에서 제어 해 야 한다.
어떻게 품질 을 보증 합 니까?
자동화 테스트 를 뛰 지 않 고 check - in 을 할 수 있다 면 품질 을 어떻게 보장 할 것 인가?
우선, 당신 은 반드시 자동화 테스트 가 있어 야 합 니 다. - 코드 를 바탕 으로 하 는 유닛 테스트 도 좋 고, script 을 바탕 으로 하 는 기능 테스트 도 좋 습 니 다. 자동화 되 고, 도달 율 이 충분 하 다 면 ok 입 니 다. - 재 구성, 특히 대규모 재 구성 을 할 때 자동화 테스트 가 없 으 면 그야말로 죽음 을 자초 합 니 다.
우 리 는 자신의 branch 에서 일 하기 때문에 main / trunk 로 돌아 갈 때 regression 이 없 으 면 됩 니 다. 중간 에 어떤 상태 인지 우 리 는 요구 가 높 지 않 습 니 다.일반적인 방법 은:

매주 smoketest 와 관련 된 acceptance test 를 뛰 어 다 니 며 중대 한 문 제 를 방지한다.

매번 main / trunk sync 와 함께 하기 전에 우 리 는 약 4 일 정도 의 시간 을 들 여 'automation triage' 를 합 니 다. - 모든 자동화 테스트 의 케이스 를 한 번 뛰 고 report 를 받 은 후에 하나씩 분석 하거나 분석 합 니 다. 많은 failure 가 똑 같 기 때 문 입 니 다.

이런 방법 은 효율 을 크게 향상 시 켰 다. - 모든 케이스 를 다 뛰 려 면 몇 십 대의 서버 가 3 일 동안 함께 뛰 어야 한 다 는 것 을 알 아야 한다.
코드 관리 방법
재 구성 은 많은 파일 의 이동 과 분리 와 관련 되 므 로 두 가지 부분 에 주의해 야 합 니 다.

파일 의 역사 정 보 를 끊 을 수 없습니다

      한 파일 이 어떻게 바 뀌 었 는 지 는 매우 중요 한 정보 입 니 다. - 누가 언제 이 파일 을 고 쳤 는 지, 어떻게 고 쳤 는 지 편리 하 게 알 수 있 습 니 다.이동 하거나 파일 을 분리 하 는 것 은 소홀 함 으로 역 사 를 잃 기 쉬 운 작업 이다.이 정 보 를 유지 하기 위해 서 는 SCM 도 구 를 정확하게 사용 해 야 합 니 다. 예 를 들 어 perforce 에 서 는 간단 한 add 가 아 닌 intergrate 를 사용 해 야 합 니 다.

파일 의 대응 관 계 를 흐 트 러 뜨 려 서 는 안 된다

       브 랜 치 에서 main 까지 의 integration 과 관련 되 어 있 습 니 다. 브 랜 치 에서 파일 을 이동 하고 수정 을 했 습 니 다. main 에서 도 누군가가 수정 을 했 습 니 다. intergration 을 할 때 다른 사람 이 main 에서 수정 한 것 을 잃 어 버 리 기 쉽 습 니 다. 대응 관계 가 구축 되 지 않 았 기 때문에 merge 를 할 수 없습니다.나 는 서로 다른 SCM 도구 가 모두 해결 방안 을 제 공 했 을 것 이 라 고 생각한다. 예 를 들 어 perforce 는 branch spec 에서 대응 관 계 를 설명 할 수 있다.
재 구성 방법
근무 기간 에 읽 은 적 이 있 습 니 다 《 재 구성 - 기 존 코드 의 디자인 개선 》. 위 에서 좋 은 디자인 개선 방법 과 절 차 를 많이 말 했 지만 거의 사용 되 지 않 았 습 니 다.디자인 에 관 해서 우 리 는 어떤 상황 을 어떻게 수정 하 는 지 에 대해 이미 연 구 를 하고 방안 을 세 웠 기 때문에 그 절차 들 은 약간 수 다스 러 워 서 적용 되 지 않 는 다.Visual Assist 재 구성 모듈 을 제공 하여 일반 규모 의 코드 에 사용 하 는 것 은 괜 찮 지만 solution 이 많은 코드 에 대해 서 는 어 쩔 수 없습니다.게다가 이것 은 소스 코드 의 재 구성 과 관련 된 것 일 뿐 우 리 는 공사 / DLL 의 재 구성 도 있다.
우리 가 채택 한 방법 은 서로 다른 상황 에 맞추어 perl 스 크 립 트 를 써 서 일부 임 무 를 자동화 하 는 것 이다.간단 한 예 를 들 어 제 가 방법 이름 을 수정 하면 스 크 립 트 는 모든 코드 를 검색 하고 수정 해 야 할 파일 을 자동 으로 체크 아웃 하 며 새 이름 을 바 꿉 니 다.perforce 호출, VS 호출, 코드, 프로젝트 파일 수정 등 을 자동화 하기 위해 perl 스 크 립 트 를 많이 썼 던 기억 이 납 니 다.
세부 사항

interface 의 사용 은 우리 의 재 구성 작업 은 인터페이스 에 대해 사용 하지 않 는 것 이 없다 고 할 수 있 습 니 다. 바로 대량의 인 터 페 이 스 를 사용 해서 이미 결 합 된 코드 의 UI - 핵심 분 리 를 가능 하 게 합 니 다.예 를 들 어 특정한 핵심 층 의 작업 이 끝 난 후에 UI 의 리 셋 코드 를 호출 하고 이 리 셋 작업 을 밖으로 옮 기 는 것 은 상당히 어 려 운 일이 다. 이때 인 터 페 이 스 를 사용 하 는 것 이 좋 은 방법 이다. 

pInterface->UpdateUI();

물론 인 터 페 이 스 를 사용 하 는 다른 방식 도 있 지만 결국은 분리 실현 을 위 한 것 이다.

vsprops 를 사용 합 니 다. 저 희 는 Visual Studio 를 사용 합 니 다. 수백 개의 항목 은 각자 의 설정 이 있 습 니 다. 사실은 많은 설정 이 차이 가 많 지 않 습 니 다. 일치 하 는 설정 을 vsprops 파일 에 넣 어서 모든 vcproj 파일 을 참조 할 수 있 습 니 다.일치 성과 간결 도 를 어느 정도 높 일 수 있다.MSDN 에는 상세 한 것 소개 하 다. 이 있다. 

가상 함수 와 rebuild.가상 함 수 를 추가 하고 삭제 합 니 다. 특히 기본 클래스 의 가상 함 수 는 기 존의 가상 표를 파괴 할 수 있 습 니 다. 따라서 rebuild 가 인용 할 수 있 는 모든 코드 를 제외 하고 이상 한 함수 호출 이 발생 할 수 있 습 니 다. 구체 적 으로 이 편 을 볼 수 있 습 니 다. 허 함수 에 관 한 그 사소한 일

이런 대형 소프트웨어 의 재 구성 을 하면 서 저 에 게 많은 것 을 배 웠 습 니 다.

일부 대형 소프트웨어 시스템 에 직면 하여 두려워 하지 않 고 자신 감 이 있 을 것 이다.

자동화 하 는 습관 을 기 르 고 대량의 수공 작업 을 하면 지루 하고 시간 이 많이 걸 리 며 실수 하기 쉽 고 성취 감 이 없 지만 목 표를 바 꾸 세 요. 프로그램 을 써 서 일 을 자동화 하 세 요. 위 에 있 는 문제 들 이 모두 없어 지지 않 습 니까?