신화를 재구성하다

1、은탄 없음
현재 이른바 재구성이라는 일을 하고 있으니, 마침내 재구성을 복습해 보았다.인월신화에서 소프트웨어 개발에는 은탄이 없다고 지적했다.소프트웨어의 복잡성과 변덕스러움은 절대적으로 완벽한 디자인의 가능성을 존재하지 않게 만들었다.고급 프로그래밍 언어는 구리로 만든 총알일지도 모르지만, 여전히 은탄이 될 수는 없다.재구성도 묘약이 아니며, 재구성도 소위'은탄'이 아니다.그러나 재구성은 코드 디자인과 서로 보완하는 특수한 사명을 짊어지고 있다.
2. 왜 개발자가 그들의 프로그램을 재구성하기를 원하지 않는가
왜 아직도 너의 프로그램을 재구성하려 하지 않니?이것은 《 재구성 》 작가의 영혼의 질문이다.

재구성하는 방법을 몰라요.

만약에 이런 이익이 장기적이라면 왜 지금 이런 노력을 해야 합니까?

코드 재구성은 별도의 작업으로 사장이 너에게 돈을 지불하는데 주로 너에게 새로운 기능을 작성하라고 한다.

재구성은 기존의 절차를 파괴할 수 있다.

3. 재구축의 목표와 원칙
재구성의 기본 원칙은 절대 증가하지도 감소하지도 않는 것이어야 한다.
목표

중복 코드 제거

는 소프트웨어가 이해하기 쉽다.

버그 찾기 돕기;

프로그래밍 속도 향상;

원칙.

냄새 제거: 하나의 재구성은 나쁜 냄새(Bad Smell)를 식별하는 것부터 시작해서 나쁜 냄새를 제거하는 것으로 끝난다. 나쁜 냄새를 제거하는 것을 목표로 하지 않는 재구성은 모두 깡패들이다.

처음부터 끝까지 작업: 즉 재구성 정의에서'소프트웨어의 관찰 가능한 행위를 바꾸지 않는 전제에서'는 재구성 과정이 소프트웨어의 외적 기능을 파괴하거나 바꾸지 못한다는 것이다.

지속적 집적: 단일 지점을 재구성할 필요가 없고 재구성 과정은 Feature 개발이 같은 지점에서 지속적으로 집적하여 납품할 수 있다.

수시로 중지: 예를 들어 하나의 방법으로 이름을 바꾸면 100개의 호출점을 수정해야 한다. 50개로 바꿀 때 긴급한 Feature가 있으면 나는 수시로 재구성을 멈추고 Feature 개발로 전환할 수 있으며 이미 만든 재구성을 되돌릴 필요가 없다.

단점 속전: 위의 예입니다. 만약에 제가 긴급 Feature 개발을 완성했다면 언제든지 이전의 재구성을 계속하고 나머지 50개의 호출점의 이름을 바꿀 수 있습니다.

과정 가역: 재구성에 대해 많은 사람들이 묻는다. 재구성이 더 나쁜 것이 아니라 더 나은 것이라고 어떻게 보증합니까?재구성의 위대함은 그가 옳고 그름의 싸움에서 벗어나 어떻게 신속하고 안전하게 변화하는지에 관심을 두는 데 있다. 물론 역재구성도 포함된다.그래서 내 대답은 장담할 수 없지만 1분만에 재구성할 수 있다는 것이다.자세히 보면, 책 속의 모든 재구성 기법은 양방향이다. 예를 들어 'Extract Method' 와 'Inline Method' 이다.

작성자: ThoughtWorks 중국 링크: https://www.zhihu.com/questio...
4, 언제 재구성, 어떻게 재구성
재구성 시점에 대해 저는 재구성은 프로그래머가 자발적으로 프로젝트 매니저에게 제기해야 한다고 생각합니다. 코드가 이미 대량의 문제가 발생했을 때 프로젝트 매니저가 발견하고 대규모의 코드 재구성을 해야 한다고 생각합니다. 은 일반적으로 다음과 같은 몇 가지 시점이 있어 재구성할 수 있다고 지적했습니다.

새로운 기능을 추가할 때 재구성하기;

오류를 수리할 때 재구성하기;

코드를 재심할 때 재구성하기;

재구성에 관해서 나 역시 미니멀리즘의 노선을 걷고 싶다.재구성하는 기법은 대부분 밑바닥이다.

하나의 클래스, 함수, 변수를 구축하거나 삭제한다.

변수, 함수의 접근 권한을 수정하고 함수 파라미터를 수정한다.

클래스 사이에서 변수, 함수를 이동한다.

가끔은 비교적 고급스러운 수법을 사용한다.

추상적인 분류를 구축한다.

계승과'조건 간소화'등 방식으로 한 종류를 간소화한다.

기존 부분에서 일부분을 분해하여 사용할 수 있는 구성 요소 클래스를 새로 만듭니다.

5. 재구성의 절입점
5.1 주석 정보
프로그래밍 수준과 영어 수준이 엇갈리는 현재 중국에서 나는 우리가 사용하는 한어 체계 때문에 이른바 코드 즉 주석의 언사가 바로 불량배라고 생각한다.모든 방법은 반드시 상세한 매개 변수 설명과 방법의 용도가 있어야 하고 필요한 논리는 반드시 명확한 설명과 주석이 있어야 한다.
5.2 세부 사항
5.2.1 반복 코드

같은 클래스의 중복 코드는 현재 클래스의 상세한 주석이 있는 함수에서 추출해야 합니다.

서로 형제인 자류의 중복 코드는 공용 방법을 그들의 초류에 밀어넣는 것도 고려할 수 있고 템플릿 방법 모델도 고려할 수 있다.

상관없는 두 가지 클래스에 대해 중복 코드를 새로운 클래스에 추출하여 기존 클래스에서 대상을 만들고 호출하는 것을 고려할 수 있다.

5.2.2 과장 함수
대상을 대상으로 프로그래밍하는 것에 익숙하지 않은 사람은 대상을 대상으로 하는 것이 무궁무진한 의뢰이고 아무런 계산도 없다고 생각할 수 있다. 실제로 작은 함수는 코드에 대한 해석 능력, 코드 논리의 공유 능력과 봉인된 선택 능력을 가져온다.에서 소함수는 이해하기 쉬운 것은 좋은 이름에 있다고 썼는데 중국어 환경에서 주석을 조금 더 넣어야 한다.큰 함수일수록 이해하기 어려울수록 지나치게 긴 함수를 어떻게 분해합니까?

        ，      ，                     。         ？  
    ：
（1）             
（2）                       ；
（3）                        。

5.2.3 과대 클래스
만약에 하나의 클래스가 너무 많은 일을 한다면 반복 코드가 잇따를 것이다. 명명적으로 보면 특정한 클래스에 여러 변수가 같은 접두사나 접두사를 가지고 있다면 이런 내용을 하나의 클래스에서 추출할 수 있다는 것을 의미할 가능성이 높다.그럼 어떻게 한 종류를 추출합니까?
같은 등급의 유류를 추출하다

1.           ；
2.      ，         ；（                ）
3.           ； （                 ）
4.        ；
5.         ，private.... final

하위 클래스를 추출하다

1.            ；
2.                   ；
3.            ，      。

이런 방법은jar 패키지의 클래스를 확장하거나 다시 쓸 때 자주 사용된다.
5.2.4 너무 긴 매개변수 열
너무 긴 매개 변수 열은 호출할 때 매개 변수 열을 이해하기 어려울 것이다. 만약 더 많은 데이터를 필요로 한다면 더 많은 매개 변수를 늘려야 한다. 그러면 프로그램이 더욱 이해하기 어려울 것이다.그렇다면 너무 긴 매개 변수열은 어떻게 재구성해야 합니까?여러분의 마음속에 이미 속셈이 있다고 믿습니다.
매개 변수 개체 가져오기
함수로 매개 변수를 대체하다
5.2.4 발산식 변화와 산탄식 변화
발산식 변화
만약 한 종류가 하나의 수요 때문에 변화를 얻고 많은 방법을 바꾸어야 한다면 이 종류는 반드시 분리해야 한다.
산탄식 변화
만약 하나의 수요의 변화가 매우 많은 종류를 바꾸어야 한다면 이런 종류는 반드시 합병되어야 한다.
5.2.5 애틋한 줄거리와 데이터의 진흙탕
애틋한 줄거리.
대상 기술의 전체 요점은'데이터를 데이터에 대한 조작 행위와 함께 포장하는 기술'이라는 데 있다.그러나 우리는 자주 이런 문제에 직면하게 된다. 한 함수에서 다른 대상의 절반 이상의 함수를 미친 듯이 호출하고 사용하는 데이터는 현재 클래스에 있다. 그러면 함수 이사 조작을 고려해야 한다. 만약에 이런 조작이 여러 클래스와 관련이 있다면 우리는 전략 모델이나 방문자 모델을 고려할 수 있다.
데이터 진흙 덩어리
만약 한 클래스에 너무 많은 데이터가 있다면, 클래스를 나누는 것을 고려해야 한다.
5.2.6 Switch Statements
일단 스위치가 나오면 대신 멀티태스킹을 고려해야 한다.Switch를 함수로 추출하는 것을 고려합니다.
5.2.7 이중화 클래스
만약 한 클래스의 대상이 다른 (단지 한 클래스가 인용하는) 클래스에 불과하다면 내부 클래스를 사용해서 불필요한 클래스를 없애는 것을 고려해야 한다.
6. 재구성 기법
7. 안전 재구성
재구성 도구
자바 프로그램의 재구성에 대해 우리는 거의 완벽한 재구성 도구를 가지고 있다.우리는 컴파일러를 빌려 우리가 재구성할 내용과 관련된 작용역, 유형과 프로그램의 의미를 분석할 수 있다.
예를 들어 변수를 삭제하려고 하는데 IDE에서 영향을 미칠 내용을 알려줍니다.안전하게 삭제할 수 있습니까?
'극간 재구성'에 대해 우리가 보장해야 할 것은 모든 간단한 절차가 안전하고 우리의 재구성 과정이 절차의 논리 구조를 바꾸지 않았다는 것이다. 그러면 우리는 우리의 복잡한 재구성이 안전하다고 생각할 수 있다.
안전 재구축의 보장
1. 당신의 인코딩 공력을 믿으세요.2. 컴파일러가 당신이 빠뜨린 오류를 포착할 수 있다고 믿습니다.3. 코드를 믿고 재심한다.4. 테스트 인원과 테스트 도구를 믿는다.
결어
만약에 소프트웨어를 시작할 때 좋은 디자인을 하고 적당한 시기에 재구성할 수 있다면 소프트웨어 개발 효율이 수량적으로 향상될 수도 있고 은탄을 발견할 수도 있다.