Java 최적화 - 무거운 코드로 인해 코드가 더욱 아름답고 간결해집니다.

요컨대

프로젝트 작업에는 SQL 최적화, 프로젝트 구조 최적화, 비즈니스 계층 최적화, 코드 구조 최적화 등을 포함한 최적화가 있는 경우가 많습니다. 이러한 최적화는 모두 시스템을 쉽게 유지 관리하고 이해하고 확장할 수 있도록 하기 위한 것입니다. 다음은 귀하와 공유할 수 있는 개인적인 경험 중 일부입니다. 나는 모든 프로그램이 최고의 건축가가 되어야 한다고 생각합니다.

과거에는 비즈니스에 더 많은 시간을 투자하고 기능 개발을 완료하고 자체 테스트를 통과한 다음 동급생을 테스트하면 된다고 느꼈습니다. 제품 승인이 괜찮다면 괜찮을 것입니다. 점차적으로 나는 더 나은 것을 추구하기 시작했고, 더 높은 지점에서 문제를 생각하고, 천천히 베테랑이 되기 시작했다는 것을 발견했습니다. 코드 품질을 향상하는 방법, 다음 팀을 규제하여 특정 인식을 형성하는 방법, 자발적으로 확장성을 고려합니다. 코드를 작성하고 Zhuangxing 등을 구축합니다.

1. 코드 최적화는 어렵다

왜 이말을하는거야?

코드 최적화는 이전 사업을 기반으로 다른 사람이나 자신의 코드를 최적화하고 최적화 아이디어를 내놓는 경우가 많으며, 현재 코드의 가독성, 유지 관리성, 디자인 방향이 그다지 친숙하지 않고, 기존 비즈니스, 코드 또는 아키텍처를 기반으로 재구성되었습니다. 최적화하기 전에 기존 코드 로직은 물론 이전 디자이너나 비즈니스 개발을 이해하고 이를 결합하여 코드를 재구성해야 합니다.

2. 리팩터링 방법

• 소규모 리팩토링은
  주로 클래스, 함수, 변수 등의 코드 수준 리팩토링을 위해 코드 세부 사항을 리팩토링하는 것입니다. 예를 들어, 공통 표준화된 명명(의미를 전달하지 않는 변수의 이름 변경), 지나치게 큰 기능 제거, 중복 코드 제거 등이 있습니다. 일반적으로 이러한 유형의 재구성 및 수정은 상대적으로 집중적이고 상대적으로 단순하며 상대적으로 영향이 적고 시간이 짧습니다. 따라서 난이도가 상대적으로 낮고, 해당 버전으로 일상적인 개발을 완벽하게 수행할 수 있습니다.

• 대규모 리팩토링은
  시스템 구조, 모듈 구조, 코드 구조 및 클래스 관계의 재구성을 포함하여 코드의 최상위 수준을 재구성하는 것입니다. 일반적으로 채택되는 방법으로는 서비스 계층화, 비즈니스 모듈화, 구성 요소화, 코드 추상화 재사용 등이 있습니다. 이러한 유형의 리팩토링에는 원칙 재정의, 패턴 재정의 또는 비즈니스 재정의가 필요할 수도 있습니다. 코드 조정 및 수정이 많이 필요하므로 상대적으로 영향이 크고, 시간이 오래 걸리며, 상대적으로 높은 위험(프로젝트 중단 위험, 코드 버그 위험, 비즈니스 취약성 위험)을 가져옵니다. 이를 위해서는 대규모 프로젝트 재구성 경험이 필요합니다. 그렇지 않으면 실수하기 쉽고 결국 이익이 손실보다 큽니다.

사실, 대부분의 사람들은 리팩토링 작업을 좋아하지 않습니다. 마치 누구도 다른 사람의 "엉덩이를 닦고" 싶어하지 않는 것처럼 그들은 다음과 같은 걱정을 할 수 있습니다.

• 리팩토링 방법을 모르고, 리팩토링에 대한 경험과 방법론이 부족하면 리팩토링 과정에서 실수를 하기 쉽습니다.
• 단기적인 이익을 보기 어려운데, 이익이 장기적인 것이라면 왜 지금 노력해야 할까요? 장기적으로 프로젝트가 이러한 이점을 얻게 되면 더 이상 이 작업에 대한 책임을 지지 않게 될 수도 있습니다.
• 리팩토링은 기존 프로그램을 파괴하고 예상치 못한 버그를 가져오며, 이러한 예상치 못한 버그를 감수하고 싶지는 않습니다.
• 리팩토링을 수행하려면 리팩토링해야 하는 코드를 직접 작성하지 않았을 수도 있다는 점은 말할 것도 없고 추가 작업이 필요합니다.

3. 재건축이 필요한 이유

프로그램에는 "오늘 당신을 위해 무엇을 할 수 있는지"와 "내일 당신을 위해 무엇을 할 수 있는지"라는 두 가지 가치가 있습니다. 대부분의 경우 우리는 오늘 프로그램에서 원하는 작업에만 집중합니다. 버그 수정이든 기능 추가든, 오늘날 프로그램을 더욱 강력하게 만들고 가치를 높이는 것이 전부입니다. 그런데 왜 내가 여전히 모든 사람이 적시에 코드 리팩토링을 해야 한다고 주장하는가? 그 주된 이유는 다음과 같습니다.

• 소프트웨어 아키텍처가 항상 좋은 디자인을 유지하도록 하세요. 소프트웨어 설계를 개선하고, 소프트웨어 아키텍처가 유리한 방향으로 발전하도록 하며, 항상 외부 세계에 안정적인 서비스를 제공할 수 있도록 하며, 예상치 못한 다양한 문제에 침착하게 직면할 수 있도록 돕습니다.
• 유지 관리 가능성을 높이고 유지 관리 비용을 줄이는 것은 팀과 개인 모두에게 긍정적인 선순환이며 소프트웨어를 더 쉽게 이해할 수 있게 해줍니다. 미래 세대가 전임자가 작성한 코드를 읽든, 나중에 자신의 코드를 검토하든, 전체 논리를 빠르게 이해하고 비즈니스를 명확하게 하며 시스템을 쉽게 유지 관리할 수 있습니다.
• 연구 개발 속도를 높이고 인건비를 절감합니다. 시스템을 처음 론칭할 때 시스템에 기능을 추가하면 완료 속도가 매우 빠르다는 것을 이해하실 수도 있겠지만, 코드 품질에 신경쓰지 않는다면 추가하는데 일주일 이상 걸릴 수도 있습니다. 나중에 시스템에 작은 기능을 추가합니다. 코드 리팩토링은 코드 품질을 보장하는 효과적인 수단이며 좋은 디자인은 소프트웨어 개발 속도를 유지하는 데 필수적입니다. 리팩토링은 시스템 손상을 방지하고 설계 품질을 향상시킬 수 있으므로 소프트웨어를 더 빠르게 개발하는 데 도움이 될 수 있습니다.
  
  

3. 리팩터링 방법

작은 리팩토링

대부분의 작은 리팩토링은 일상적인 개발에서 이루어집니다. 일반적인 참조 표준은 우리의 개발 사양 및 지침입니다. 목적은 코드의 악취를 해결하는 것입니다. 일반적인 악취를 살펴 보겠습니다.

if-else가 너무 많습니다.

스케일 코드:

if(){
    
    
	if(){
    
    
		if(){
    
    
			} else if(){
    
    
			}
	} else if(){
    
    
	}
} else if(){
    
    
}

그렇지 않은 경우 3개의 레이어를 초과하지 않는 것이 좋습니다.

for 루프에는 위와 같은 여러 수준이 있습니다. if else 예

중복된 코드

프로젝트 내에서 나머지 값이 계산되는 여러 위치가 있는데, 함수를 통해 결과를 캡슐화하고 메소드를 균일하게 호출하는 것을 고려하거나 유사한 코드 조각에서 메소드 호출을 균일하게 추출할 수 있습니다.

함수가 너무 깁니다.

좋은 기능은 단일 책임 원칙을 충족하고, 짧고 간결하며, 한 가지 일만 수행해야 합니다. 지나치게 긴 함수 본문과 멀티 태스킹 방법은 코드 읽기 및 재사용에 도움이 되지 않습니다.

명명 규칙

좋은 이름은 "이름에 걸맞고 이름으로 이해할 수 있어야" 하며, 간단하고 모호하지 않아야 합니다.

불합리한 댓글

댓글은 양날의 검입니다. 좋은 댓글은 좋은 지침이 될 수 있지만 나쁜 댓글은 사람들을 오해할 뿐입니다. 댓글에 관해서는 코드 통합 시 댓글을 함께 수정해야 합니다. 그렇지 않으면 댓글과 로직 사이에 불일치가 발생하게 됩니다. 또한 코드에서 의도를 명확하게 표현한 경우 주석은 중복됩니다.

쓸모없는 코드

쓸모없는 코드를 사용하는 방법에는 두 가지가 있는데, 하나는 사용 시나리오가 없다는 것입니다.이 유형의 코드가 도구 메소드나 도구 클래스가 아니라 쓸모없는 비즈니스 코드인 경우 제때에 삭제하고 정리해야 합니다. 다른 하나는 주석으로 묶인 코드 블록인데, 주석으로 표시된 코드는 삭제해야 합니다.

너무 큰 클래스

클래스가 너무 많은 일을 하고 너무 많은 기능을 유지하면 가독성이 떨어지고 성능도 저하됩니다. 예를 들어 주문 관련 기능을 A 클래스에 넣고, 상품 재고 관련 기능도 A 클래스에 넣고, 포인트 관련 기능도 A 클래스에 넣고… 하나의 클래스 젠장, 가독성에 대해 이야기합시다. 코드는 단일 책임에 따라 여러 클래스로 나누어야 합니다.

이것은 상대적으로 흔한 코드 "악취"입니다. 물론 실제 개발에는 혼란스러운 코드, 불분명한 논리, 복잡한 클래스 관계와 같은 다른 "악취"가 있습니다. 이러한 다양한 "악취" 냄새가 나면 우리는 시도해야 합니다. 그냥 놔두지 말고 해결해 보세요.

대규모 리팩토링

대규모 리팩토링은 소규모 리팩토링에 비해 고려할 사항이 더 많고, 대규모 리팩토링에서는 상황이 변하기 때문에 좋은 리듬을 설정하고 단계별로 실행하는 것이 필요합니다.

코끼리를 냉장고에 넣는 단계는 일반적으로 1) 냉장고 문 열기(행사 전), 2) 코끼리 밀어 넣기(행사 중), 3) 냉장고 문 닫기(행사 후)의 3단계로 나눌 수 있다. 이벤트). 일상적인 모든 일은 3단계 접근 방식을 통해 해결될 수 있으며, 리팩토링도 예외는 아닙니다.

사전

준비는 리팩토링의 첫 번째 단계로, 이 부분이 상대적으로 복잡하면서도 가장 중요한 부분이므로, 사전 준비가 충분하지 않으면 실행 중이나 리팩토링이 시작된 후에 생성되는 결과가 나올 가능성이 매우 높습니다. 기대와 일치하지 않습니다. 현상.

이 단계는 대략 세 단계로 나눌 수 있습니다.

• 재건축의 내용, 목적, 방향, 목표를 명확히 하십시오
  .이 단계에서 가장 중요한 것은 방향을 명확하게 하는 것이며, 이 방향은 모든 사람의 의구심을 견딜 수 있고 적어도 향후 3~5년의 방향을 만족시킬 수 있습니다. 다른 하나는 이번 재건축의 목표인데 기술적인 한계, 역사적 부담, 기타 이유로 인해 이 목표가 최종 목표가 아닐 수도 있으므로 최종 목표가 무엇인지 명확히 할 필요가 있습니다. 이번 재구성의 목표에서 최종 목표까지 무엇을 해야 하는지 명확히 하는 것이 가장 좋습니다.

• 데이터를 정리하는
  단계에서는 재구성 부분에 관련된 기존 비즈니스와 아키텍처를 분류하고, 재구성된 콘텐츠가 속한 시스템의 어느 서비스 수준, 어느 비즈니스 모듈에 속하는지, 신뢰 당사자와 종속 당사자가 누구인지를 명확히 해야 합니다. 어떤 비즈니스 시나리오가 있는지, 각 장면의 데이터 입력 및 출력은 무엇입니까? 이 단계에는 일반적으로 프로젝트 배포, 비즈니스 아키텍처, 기술 아키텍처, 서비스 업스트림 및 다운스트림 종속성, 강한 종속성과 약한 종속성, 프로젝트의 내부 서비스 계층화 모델, 콘텐츠 및 기능 종속성 모델, 입력 및 출력 데이터 흐름을 포함하는 출력이 있습니다. , 등 디자인 도면 및 문서.

• 사업수립
  사업수립은 일반적으로 회의를 통해 진행되며, 재건축에 관련된 모든 부서나 단체에 재건축 사업에 대한 설명을 하고, 대략적인 일정(대략적인 대략적인 시간)을 알 수 있으며, 각 단체의 주요 책임자를 명확히 규정하고 있다. 또한 리팩토링에 어떤 비즈니스와 시나리오가 포함되는지, 대략적인 리팩토링 방법, 비즈니스에 미치는 영향, 어려움, 병목 현상이 발생할 수 있는 단계 등도 알아야 합니다.

진행 중

이 단계를 실행하는 데 관련된 작업과 작업은 상대적으로 힘들고 상대적으로 많은 시간이 필요합니다.

• 아키텍처 설계 및 검토
  아키텍처 설계 검토에는 주로 표준 비즈니스 아키텍처, 기술 아키텍처 및 데이터 아키텍처의 설계 및 검토가 포함됩니다. 검토를 통해 아키텍처 및 비즈니스 문제를 발견합니다. 이 검토는 일반적으로 팀 내 검토입니다. 검토 결과 아키텍처 설계를 결정할 수 없는 것으로 확인되면 팀이 솔루션 아키텍처에 대해 합의할 때까지 조정이 필요합니다. 그래야만 다음 단계로 진행할 수 있으며, 심사 결과 역시 심사 통과 후 참가자들에게 이메일로 통보됩니다.

이 단계의 결과물: 재구성된 서비스 배포, 시스템 아키텍처, 비즈니스 아키텍처, 표준 데이터 흐름, 서비스 계층 모델, 기능 모듈 UML 다이어그램 등

• 상세한 구현 설계 계획 및 검토
  이 구현 설계 계획은 구현에서 가장 중요한 계획으로 후속 R&D 코딩, 자체 테스트 및 공동 디버깅, 신뢰 당사자 도킹, QA 테스트, 오프라인 릴리스 및 구현 계획과 관련됩니다. 온라인 출시 및 구현 계획, 특정 작업량, 난이도, 작업 병목 현상 등 이 세부 구현 계획은 AB 그레이스케일 프로그램 및 AB 검증 프로그램을 포함하여 전체 연구 개발, 오프라인 테스트, 온라인 프로세스 및 그레이스케일 장면 세부 사항을 심층적으로 다루어야 합니다.

솔루션 설계에서 가장 중요한 부분은 AB 검증 프로그램과 AB 검증 스위치로, 이는 우리의 재구성이 완료되었는지 평가하고 테스트하는 표준 기반입니다. 일반적인 AB 검증 절차는 대략 다음과 같습니다.

데이터 입구에서 동일한 데이터를 사용하여 새 프로세스와 이전 프로세스 모두에 대한 처리 요청을 시작합니다. 처리가 완료되면 처리 결과가 각각 로그에 인쇄됩니다. 마지막으로 오프라인 프로그램을 사용하여 새로운 프로세스와 기존 프로세스의 결과가 일치하는지 비교합니다. 따라야 할 원칙은 동일한 입력 매개변수를 사용하면 응답 결과도 일관되어야 한다는 것입니다.

AB 프로그램에는 두 개의 스위치가 포함됩니다. 그레이스케일 스위치 (켜져 있는 경우에만 코드 실행을 위해 요청이 새 프로세스로 전송됩니다) 실행 스위치 (새 프로세스에 쓰기 작업이 포함된 경우 스위치를 사용하여 새 프로세스에 쓸지, 이전 프로세스에 쓸지 제어해야 함) 전달하기 전에 그레이스케일 스위치 및 실행 스위치(일반적으로 구성 센터에서 구성되며 언제든지 조정 가능)를 스레드 컨텍스트에 작성하여 구성 센터 스위치를 수정할 때 일관되지 않은 결과를 방지해야 합니다.

• 코드 작성, 테스트 및 오프라인 구현
  세부 설계 계획에 따라 코딩, 단위 테스트, 공동 디버깅, 기능 테스트, 비즈니스 테스트, QA 테스트를 수행하는 단계입니다. 합격 후 온라인 프로세스 및 온라인 스위치 구현 프로세스를 오프라인으로 시뮬레이션하고, AB 프로그램을 확인하고, 기대치를 충족하는지, 새 프로세스의 코드 적용 범위가 온라인 요구 사항을 충족하는지 확인합니다. 오프라인 데이터 샘플이 상대적으로 적고 모든 시나리오를 포괄할 수 없는 경우 모든 시나리오가 기대치를 충족할 수 있도록 모든 시나리오를 포괄하는 트래픽을 구성해야 합니다. 오프라인 커버리지가 기대치에 도달하고 AB 검증 프로그램에서 이상이 발견되지 않으면 온라인 작업을 수행할 수 있습니다.

나중에

이 단계는 오프라인 시뮬레이션의 구현 프로세스에 따라 온라인으로 구현되어야 하며, 이는 온라인, 대규모, 수리, 오프라인 기존 로직 및 검토의 여러 단계로 구분됩니다. 가장 중요하고 에너지를 소비하는 것은 체적 공정입니다.

• 그레이 스케일 전환 과정은
  관찰을 위한 새로운 과정으로 점진적으로 확장되며, 1%, 5%, 10%, 20%, 40%, 80%, 100%의 진행에 따라 볼륨을 늘릴 수 있으므로 새로운 프로세스는 점차적으로 코드 로직을 다룰 수 있습니다. 이 단계에서는 실제로 쓰기 작업을 수행하기 위해 스위치를 켜지 않습니다. 새로운 프로세스의 로직 적용 범위가 요구 사항에 도달하고 AB 검증 결과가 기대에 부합하면 쓰기 작업 스위치를 점진적으로 켜서 실제 비즈니스를 실행할 수 있습니다.

• 비즈니스 실행 전환 프로세스가
  새로운 그레이스케일 프로세스의 기대치를 충족한 후 비즈니스 실행 쓰기 작업 전환 프로세스를 점차적으로 활성화할 수 있으며 일정 비율에 따라 볼륨을 점차적으로 늘릴 수 있습니다. 새 논리는 쓰기 작업을 수행하고 이전 논리 쓰기 작업은 닫힙니다. 이 단계에서는 온라인 오류, 지표 이상, 사용자 피드백 및 기타 문제를 관찰하여 새로운 프로세스에 문제가 없는지 확인해야 합니다.

대규모 작업이 완료되고 특정 버전이 안정화되면 기존 로직 및 AB 검증 프로그램을 오프라인으로 전환할 수 있으며 재구성 작업이 완료됩니다. 가능하다면 재건축 검토회의를 열어 각 참가자가 재건축에 필요한 기준을 충족했는지 확인하고, 재건축 과정에서 직면한 문제점과 해결 방안은 무엇인지 검토하고, 후속 문제를 피하기 위해 강수 방법론을 사용할 수 있습니다. 일하다.

요약하다

코딩 기술

• 코드를 작성할 때 특정 구현에 의존하기보다는 인터페이스/추상화에 의존하는 단일 원칙과 같은 몇 가지 기본 원칙을 따르십시오.
• 코딩 표준을 엄격히 준수하고 특수 주석에는 TODO, FIXME, XXX를 사용합니다.
• 단위 테스트, 기능 테스트, 인터페이스 테스트, 통합 테스트는 코드 작성에 필수적인 도구입니다.
• 우리는 코드의 작성자이고 미래 세대는 코드의 독자입니다. 코드를 작성할 때 항상 검토하고, 선배들이 후손들이 즐길 수 있도록 나무를 심은 일을 해야 하며, 선배들이 후손들과 함께 묻을 구멍을 파는 일을 해서는 안 됩니다.
• 깨진 유리창 효과를 처음으로 피한 사람이라면 이제 코드가 이미 나쁘고 더 이상 변경할 필요가 없다고 생각하지 말고 계속해서 코드를 쌓아가면 됩니다. 그렇게 되면 언젠가는 다른 사람의 코드에 혐오감을 느끼고 "조만간 갚아야 할 것"이 될 것입니다.

리팩토링 기술

• 위에서 아래로, 외부에서 내부로 모델링하고 분석하며, 다양한 관계를 명확히 하는 것이 재구성의 최우선 과제입니다.
• 클래스를 개선하고, 기능을 재사용하고, 핵심 기능에 집중하여 모듈 책임을 명확하게 합니다.
• 인터페이스에 대한 의존성이 추상화에 대한 의존성보다 좋고, 추상화에 대한 의존성이 구현에 대한 의존성보다 낫습니다. 클래스 관계가 결합될 수 있으면 상속할 필요가 없습니다.
• 클래스, 인터페이스 및 추상 인터페이스를 디자인할 때 범위 한정자, 다시 작성할 수 있는 한정자, 다시 작성할 수 없는 한정자, 일반 한정자가 정확한지 여부를 고려하세요.
• 대규모 리팩토링을 위한 다양한 설계와 계획을 세우고, 오프라인에서 다양한 시나리오를 시뮬레이션하며, 온라인으로 전환하려면 AB 검증 절차가 필요하며, 신규와 기존 간 전환은 언제든지 가능합니다.