요약 : 나는 종종 조상 코드가 있다고 들었습니다. 즉, 일부 프로젝트는 오랫동안 유지되어 왔으며 많은 사람들의 손에 따라 비즈니스 논리가 점점 더 쌓여서 유지 관리가 점점 더 어려워집니다. .
몇 달 전에 동료들은 노드가 지원하는 마스터 / 슬레이브 구조를 가진 분산 작업 스케줄링 시스템을 남겨두고 방금 떠났습니다.
- 운영 및 배포의 관점 에서 현재 상황은 여러 릴리스 버전이며 버전이 의존하는 노드가 다르며 배포에는 일부 종속 파일의 수동 복사본이 필요합니다.
- 코드 구조의 관점에서 유지해야하는 메인 버전은 js 구문으로 작성되며 종종 많은 양의 비즈니스 로직이 하나의 파일에 쌓입니다.
Slaver를 예로 들어 현재 문제를 분석하고 제가 고려한 최적화 솔루션을 분석해 보겠습니다.
먼저 Slaver 섹션에 어떤 모듈과 함수가 포함되어 있는지 살펴 보겠습니다.
1. 마스터와의 메시지 요청 및 응답을 포함합니다.
2. 하위 작업을위한 상태 머신을 포함합니다.
3. 다른 작업의 처리 세부 정보를 포함합니다.
구문 및 성능 관점에서 :
- 대부분은 객체 유형과 가변 길이 매개 변수를 매개 변수로 사용합니다.
- 동일한 파일에는 많은 수의 엔티티 정의 및 구성, 많은 암시 적 유형 변환 및 긴 요소 참조를 포함하여 엔티티 객체를 정의하는 대신 Object의 과도한 사용이 포함됩니다.
- 동기화 형태의 많은 io 작업, 너무 많은 파일 작업;
- 오류 인쇄 만 어디에나 흩어져 있으며 중앙 집중식 오류 정의가 없습니다.
- 변수 이름 지정에 대한 규칙이 없으며 지역과 전역을 구분하는 것이 불가능하며 이름이 반복적으로 사용되어 이해하기 어렵습니다.
- 변수 정의가 산재 및 분산되어 있으며 전역 범위의 함수 호출이 산재되어 여러 곳에 분산되어 있습니다.
- 중첩 된 다중 레벨 try ... catch 문
- 연속 사이클의 작업 설계로 인해 서버 리소스 낭비가 발생합니다.
- 함수의 여러 위치에서 절대 경로가 사용되어 마이그레이션 및 이식성이 떨어집니다.
최적화 계획에 대한 고려 사항 :
- js => Ts, typescript 문법을 사용하여 코드 구조를 재구성하십시오. (이 계획의 이전 동료는 업그레이드 조정 범위가 약간 크기 때문에 버전을 개발했습니다. 사실 라인 이후에 더 많은 기능 문제가 있으며 버전이 일시적으로 보류 됨)
- js => java, java를 사용하여 관련 로직을 재개발합니다 (비즈니스 코드 로직, 워크로드 증가).
- js 언어를 변경하지 않고 원래 코드를 리팩터링하고 분할하십시오.
js와 비교할 때 typescript / java는 더 강력한 유형과 객체 지향 소프트웨어 디자인을 사용하기 더 쉬운 구문 디자인을 가지고 있습니다.
하지만 백엔드 코드를 개발하기 위해 js를 사용하는 것은 나쁜 선택일까요? 전혀 더 많은 설계와 사양 준수가 필요합니다.
화제를 제외하고 기존 시스템이 잘 돌아가고 있다면이를 기반으로 대규모 2 차 개발을 할 필요가없고, 투자 비용 측면에서는 이런 종류의 프로젝트를 리팩토링 할 필요가 없다고 생각합니다.
리팩토링과 디커플링은 소프트웨어 개발에서 가장 긴 주제입니다.
계속하려면 ...
참조 문서:
