이러한 원칙 을 준수 하면 개발 효율 을 배로 높 일 수 있다.

개술
정원 안에 각종 기술 세부 사항 에 관 한 연구 글 이 많은 데 모두 비교적 강 한 구조 연구 이다.그러나 개발 효율 을 어떻게 향상 시 키 는 지 에 관 한 글 을 보지 못 했다.대부분 개발 효율 을 향상 시 키 는 글 은 개발 중의 작은 기술 이 아니 라 자동화 등 보조 도구 유형 에 관 한 것 이다.오늘 은 인 코딩 규범,인 코딩 기법,개발 사상,디자인 모델 등 여러 분야 의 경험 을 통 해 개발 효율 을 어떻게 향상 시 키 는 지 공유 합 니 다.
2.실제 장면
이 전후 단 분리 가 성행 하 는 개발 시대 에 분업 이 비교적 명확 했다.개발 자 는 전단 개발 자 와 백 엔 드 개발 자 를 나 누 었 다.그러나 뿌 듯 한 것 은.net 개발 자 들 은 대부분이 스 택 개발 의 직책 을 맡 았 고 경험 이 있 는 개발 자 들 은 모두 전단 에서 걸 어 왔 다 는 것 이다.말하자면 전단 업무 코드 는 백 엔 드 개발 자 에 게 그것 은 일이 아니다.
4.567914.몇 년 전 전후 단 이 분리 되 지 않 았 을 때 각종 전단 구조 가 유행 하지 않 았 을 때 개발 자의 효율 은 비교적 낮은 편 이 었 다.백 엔 드 는 전단 의 일 을 했 고 심지어 전단 과 백 엔 드 가 섞 여 일 을 했 기 때문에 업무 개발 이 쉽게 어 지 럽 고 서로 의존 해 야 하 며 업 무 를 완전히 병행 하지 못 해서 개발 효율 이 낮은 큰 원인 이 되 었 다.동시에 개 발 된 것 도 체험 이 나쁘다.
4.567914.직책 이 뚜렷 하고 백 엔 드 는 백 엔 드 의 개발 에 전념 하 며 전단 은 전단 의 개발 에 전념 합 니 다.상호 의존 관계 가 약 하고 백 엔 드 는 개발 인터페이스,전단 페이지 와 mock 인터페이스 도 킹 을 먼저 정의 할 수 있 으 며 마지막 으로 연결 테스트 시간 전후 단 을 통과 할 수 있 습 니 다.전후 단 은 개발 을 병행 할 수 있 고 개발 주기 가 배로 단축 된다.그러나 이것 은 치 명 적 인 문 제 를 초래 할 수 있다.대부분 개발 자 들 은 자신의 일부분 만 생각 하고 전체적인 고려 를 하지 않 는 다.이 로 인해 발생 하 는 문 제 는 바로 테스트 시간 을 조정 하 는 대가 가 너무 크 고 문제 가 발생 하면 서로 책임 을 지 는 것 이다.
앞 뒤 끝 에 존재 하 는 문제점 은 재 연 조 테스트 시간 이 모두 새 어 나 올 것 이다.이것 도 왜 연 조 테스트 시간 이 그렇게 오래 걸 리 고 심지어 저녁 에 잔업 을 해서 문 제 를 처리 하 는 이유 이다.요약 하면 다음 과 같다.
개발 과정 에서 신중 하지 못 한 것 은 모두 공 이상 문제 이다

코드 가 규범 에 맞지 않 고 코드 논리 적 인 구성 차원 이 너무 깊 어서 머리 를 잡 고 온몸 을 움 직 여서 여 기 를 수정 하고 저쪽 의 문 제 를 드 러 내 면 적당 한 결합 을 풀 지 못 합 니 다

4.567917.백 엔 드 인터페이스 에서 돌아 오 는 필드 의 의미 가 명확 하지 않 고 뚜렷 하지 않 으 며 심지어 필드 의 의미 와 완전히 어 긋 납 니 다.예 를 들 어 데이터 베이스 에 int 형식의 Type 필드 가 있 는데 전단 에 유형의 중국어 이름 이 필요 합 니 다.백 엔 드 개발 자 는 게 으 름 을 피 우 고 Type 필드 로 중국어 이름 을 되 돌려 줍 니 다.뒤쪽 전단 에 int 유형의 Type 이 필요 합 니 다.어떤 필드 를 추가 하 는 것 이 좋 을 지 모 릅 니 다.수정 을 초래 하고 효율 에 영향 을 주 며 세부 사항 을 구체 적 으로 공유 하 겠 습 니 다

눈 이 부족 하고 후속 적 인 수요 변경 확장 을 고려 하지 않 습 니 다

4.567917.디자인 모델 사상 이 없 으 면 유지 비용 이 커진다다음은 몇 가지 측면 에서 구체 적 으로 분석 하 자이상
1.1 불 신 원칙
개발 자로 서 당신 은 자신 을 방법 호출 자의 제3자 로 할 수 있 습 니 다.방법의 실현 에 관심 을 가 질 필요 가 없습니다.호출 방법 에 만 관심 을 가 져 야 합 니 다.제 가 어떤 결 과 를 얻 어야 하 는 지 에 만 관심 을 가 져 야 합 니 다.그러나 호출 자 제3자 로 서 실현 자의 방법 은 모두 믿 을 수 없 는 상태 라 고 생각해 야 한다.이 원칙 을 계승 하기 만 하면 기본적으로 너 는 공중 이상 과 인연 이 없다.
1.2 ?. （null 조건 연산 자)
먼저 다음 코드 를 살 펴 보 겠 습 니 다.

 [HttpGet]
  public async Task<DataResponse<bool>> GetTest()
  {
    var list = GetList();//  List   
    if (list?.Count <= 0)
    {
      return DataResponse<bool>.AsError("       ");
    }
    //TODO     
    return DataResponse<bool>.AsSuccess(true);
  }

위의 코드 는 많은 사람들 이 이렇게 쓸 수 있 습 니 다.실제로 문제 가 있 는 list 입 니까?Count<=0 은 실제로 list 가 비어 있 을 때 null<=0 으로 판단 되 었 고 false 로 예상 결과 에 부합 되 지 않 습 니 다.정확 한 코드 는 다음 과 같 습 니 다.

 [HttpGet]
  public async Task<DataResponse<bool>> GetTest()
  {
    var list = GetList();//  List   
    if ((list?.Count??0) <= 0)
    {
      return DataResponse<bool>.AsError("       ");
    }
    //TODO     
    return DataResponse<bool>.AsSuccess(true);
  }

여기 인용?연산 자(빈 연산 자)
1.3 ?? （빈 병합 연산 자)
MSDN 의 설명:?연산 자 는 null 통합 연산 자 라 고 하 며 null 값 의 형식 과 참조 형식의 기본 값 을 정의 합 니 다.왼쪽 조작 수가 null 이 아니라면 왼쪽 조작 수 를 되 돌려 줍 니 다.그렇지 않 으 면 왼쪽 동작 수가 null 일 때 오른쪽 동작 으로 돌아 갑 니 다.
1.4 어떻게 공중 이상 을 멀리 합 니까?
원칙 을 계승 하 다.당신 이 사용 하 는 방법 은 모두 임무 변경 방법 을 믿 을 수 없습니다.자신 이 쓴 방법 을 포함 합 니 다.이것 은 민첩 하고 빠 른 개발 에서 더욱 뚜렷 하 다.특히 팀 에서 다른 사람 이 개발 한 마이크로 서비스 api 를 호출 하면 방법의 실현 에 관심 을 가 질 필요 가 없다.방법의 결과 에 만 관심 을 가 져 야 하지만 너무 믿 어 서 는 안 된다.모든 반환 결 과 는 null 의 결과 데이터 인지 아 닌 지 를 판단 하고 많이 결합 해 야 합 니까?하고?연산 자 를 합 리 적 으로 논리 적 으로 처리 하면 프로젝트 가 빈 이상 에서 벗 어 날 수 있 습 니 다.
2.If else 해제
일단 재 미 있 는 인터넷 에 있 는 사진 을 보 겠 습 니 다.
2.1 취 반 원칙
위의 if else 내장 업무 에 대해 여러분 은 자주 만 나 지 않 습 니까?이런 코드 를 보면 매우 골 치 아 프 고 유지 하기 어렵 고 개발 효율 에 영향 을 주 며 bug 도 쉽게 나타 납 니 다.
경험 이 있 는 개발 자 는 반드시 위의 이 코드 를 최적화 시 킬 것 이다.나의 경험 은 반 원칙 을 취 하 는 것 이다.
무엇이 반 원칙 을 취 하 는 것 입 니까?부합 되 지 않 는 조건 을 먼저 return 하고 마지막 에 조건 에 부합 되 는 논 리 를 남 기 는 것 이 바로 반 원칙 이다.한눈 에 보면 한 겹 의 끼 워 넣 기 만 있 을 뿐 여러 겹 의 끼 워 넣 기 는 존재 하지 않 는 다.
우 리 는 내 가 만난 실제 장면 코드 를 살 펴 보 자.소스 코드 는 대체적으로 다음 과 같다.

if (condition)
{
  if (condition1)
  {
    if(condition2)
    {
      if (condition3)
      {
        if (condition4)
        {
          // do something
        }
        else
        {
          // do something
        }
      }
      else
      {
        // do something
      }
    }
    else
    {
      // do something
    }
  }
  else
  {
    // do something
  }
}
else
{
  // do something
}

취 반 원칙 최적화 후의 코드 는 다음 과 같다.

if (!condition)
 {
   // do someting
   return;
 }
 if (!condition1)
 {
   // do someting
   return;
 }
 if (!condition2)
 {
   // do someting
   return;
 }
 if(!condition3)
 {
   // do someting
   return;
 }
 if(!condition4)
 {
   // do someting
   return;
 }
 // do someting

3.필요 한 디자인 모델
개발 과정 에서 하나의 링크 를 끝까지 쓰 지 말고 특정한 업 무 를 먼저 생각 하고 포 지 셔 닝 을 명확 하 게 해 야 한다.이 업 무 는 어느 부분 에 속 해 야 하 는 지,어떤 업무 에 속 해 야 하 는 지,그 다음 에 어떤 업무 변동 이 발생 할 수 있 는 지,디자인 모델 을 적당 하 게 도입 해 야 한다.그러면 많은 디자인 모델 은 그 당시 에 개발 한 장면 에 적합 하 다.
디자인 모델 의 선택 은 이 모듈 의 역할 과 정의 가 뚜렷 하고 생각 을 많이 하 며 분류 해 야 하기 때문에 자 연 스 럽 게 마음 속 에 적당 한 디자인 모델 에 대한 고려 가 생 겼 다.
4.필요 한 단원 테스트
모든 방법 유닛 테스트 를 할 때 가장 좋 은 것 은 모든 경 로 를 모든 분기 의 유닛 테스트 에 덮어 쓰 는 것 이다.먼저 어 렸 을 때 부터 방법 유닛 테스트,바 텀 방법 유닛 테스트 를 통과 한 다음 에 postman 또는 다른 도 구 를 통 해 대외 API 인터페이스 차원 의 테스트 를 하고 전체 경로 가 겹 치 는 테스트 를 하 는 것 이다.흔히 개발 자 들 은 정상 적 인 업무 절 차 를 테스트 하 는 사고 가 있다.이상 절 차 는 종종 테스트 를 일절 고려 하지 않 는 다.그러나 문 제 는 모두 이상 한 절차 이다.단원 테스트 가 지 켜 야 할 원칙 은 다음 과 같다.

가능 한 한 모든 경로 덮어 쓰기 테스트

4.567917.자신 이 쓴 코드 사 고 를 버 리 고 소 백 이 유닛 테스트 를 한다이상 경 로 를 주목 하 는 단원 테스트4.567917.의존 사상 을 버 리 고 테스트 시간 에 의존 하지 마 세 요.흔히 개발 만 하고 정확 한 확률 에 관 계 없 이 후속 테스트 시간 이 되면 미 친 야근 으로 진 도 를 따라 잡 고 최고의 제품 품질 을 보장 하지 못 합 니 다이러한 원칙 을 준수 하여 개발 효율 을 배로 높 일 수 있 는 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 개발 효율 향상 에 관 한 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!