사람들이 레거시 코드를 인수할 때 가장 조급해지게 만드는 것은 무엇이라고 생각하시나요? 매우 복잡한 UML? 나는 그렇게 생각하지 않습니다. 내 대답은 2개 이상의 다른 경우가 있거나 2개 이상의 사례로 전환하는 경우입니다. 하지만 코드에서 if else 와 대/소문자 전환을 많이 사용하는 것이 정상인가요? 잘못된! 대부분의 경우 else 및 2개 이상의 분기가 있는 스위치 케이스는 하드 코딩된 형식으로 표시되어서는 안 됩니다.
복잡한 분기는 어디에서 오는가?
우선, 우리가 논의하고 싶은 첫 번째 질문은 레거시 코드에 복잡한 분기가 왜 그렇게 많은지입니다. 이러한 복잡한 분기는 코드의 첫 번째 버전에는 존재하지 않는 경우가 많습니다. 디자이너가 아직 어느 정도 경험이 있다고 가정하면 향후 확장해야 할 영역을 예측하고 추상 인터페이스를 예약해야 합니다.
그러나 코드가 여러 번 반복된 후, 특히 요구 사항 세부 사항을 여러 번 조정한 후에는 복잡한 분기가 나타납니다. 요구 사항에 대한 세부적인 조정은 UML에 반영되지 않고 코드에 직접 반영되는 경우가 많습니다. 예를 들어 메시지는 원래 채팅 메시지와 시스템 메시지라는 두 가지 범주로 나뉘었지만 설계 과정에서 자연스럽게 메시지 범주의 두 가지 하위 범주로 설계되었습니다. 그런데 어느 날 요구 사항이 세부적으로 조정되었습니다. 일부 시스템 메시지는 중요하며 해당 제목은 빨간색으로 표시되어야 합니다. 이때 프로그래머는 종종 다음과 같이 수정합니다.
시스템 메시지 클래스에 중요한 속성을 추가합니다.
제목 색상을 제어하기 위해 해당 렌더링 방법에 중요한 속성에 대한 분기를 추가하세요. 프로그래머가 왜 그렇게 변경할까요? 어쩌면 그것이 추상적이어야 한다는 것을 깨닫지 못했기 때문일 수도 있다. 요구 사항에 "일부 시스템 메시지가 중요하다"고 명시되어 있기 때문에 명령형 프로그래밍 언어에 대해 더 많은 교육을 받은 프로그래머의 경우 가장 먼저 생각할 수 있는 것은 플래그 비트입니다. 플래그 비트는 중요한 메시지와 중요하지 않은 메시지를 구별할 수 있습니다. . 중요한. 그는 이 요구 사항이 다른 방식으로 해석될 수 있을 것이라고는 예상하지 못했습니다. "시스템 메시지는 중요함과 중요하지 않음이라는 두 가지 범주로 나뉩니다." 이런 식으로 해석함으로써 그는 시스템 메시지가 추상화되어야 한다는 것을 알았습니다.
물론 프로그래머가 추상화가 가능하다는 것을 알고 있지만 어떤 이유로 그렇게 하지 않기로 선택할 수도 있습니다. 매우 일반적인 상황은 누군가가 프로그래머에게 프로젝트 진행 속도를 대가로 코드 품질을 희생하도록 강요하는 것입니다. 속성과 분기를 추가하는 것이 추상 리팩토링보다 훨씬 간단합니다. 이 양식 수정을 10개 만드는 것이 더 빠릅니다. 가지 또는 10개의 추상화? 차이점은 분명합니다.
물론 if else가 너무 많으면 일부 똑똑한 사람들이 일어나서 "스위치 케이스로 바꾸는 게 어때? "라고 말할 것입니다. 어떤 경우에는 각 분기가 상호 배타적이라고 가정하면 실제로 코드 가독성이 향상될 수 있습니다. 그러나 스위치 케이스 수가 증가하면 코드도 읽을 수 없게 됩니다.
복잡한 지점의 단점은 무엇입니까?
복잡한 지점의 단점은 무엇입니까? Baidu Hi 웹 버전의 이전 코드 섹션을 예로 들어보겠습니다.
스위치(json.result) {
"알았어":
스위치(json.command) {
사례 "메시지":
케이스 "시스템 메시지":
if (json.content.from == ""
&& json.content.content == "쫓겨남") {
/* 연결 끊기 */
} else if (json.command == "systemmessage"
|| json.content.type == "sysmsg") {
/* 시스템 메시지 렌더링 */
} 또 다른 {
/* 채팅 메시지 렌더링 */
}
부서지다;
}
부서지다;
출처: Baidu 범사용자 경험