청정 코드 및 모범 코딩 관행을 달성하기 위한 가이드

반응형

좋은 코드란 무엇이고 코딩 표준은 무엇인가요?

간단히 말해서,

• 깔끔하고 이해하기 쉬우며 들여쓰기, 주석 달기, 우수한 설명서 등과 같은 모범 코딩 관행을 따르는 코드입니다.
• 메모리 누수가 없는 비교적 적은 행으로 작성되어 코드 가독성과 재사용성을 강조합니다.
• 누구의 기대수명이 더 많은지, 그것은 그것을 수정하는 것이 더 적은 노력을 필요로 하는 방식으로 설계되었다는 것을 의미한다.
• 이는 인지 부하를 감소시킨다(즉, 이해하기가 쉽다).
• 그것은 간결하고 요점입니다.
• 그것은 쓰기 재미있고 유지하기도 쉽다.

깨끗한 코드로 간주될 수 있습니다. 이를 위해 우리는 일종의 규칙을 적용하고 프로젝트 전반에 걸쳐 일정한 지침을 따르는데, 이를 코딩 표준이라고 합니다.

다시 말해, 이것들은 고품질 코드를 생산하기 위해 코딩하는 동안 지켜야 할 원칙과 디자인 패턴, 그리고 규약이다.

 

• 소프트웨어를 개발하면서 코딩 표준을 활용할 수 있는 장점이 많다.
• 작성된 소스 코드의 가독성을 향상시킵니다.
• 전체 소스 코드는 동일한 형식과 코딩 스타일을 따릅니다.
• 유지보수가 거의 필요하지 않습니다.
• 개발자들의 생산성은 이것의 결과로 상승합니다.
• 성공적인 프로젝트와 최악의 경우 도착 시 비활성화된 프로젝트 간의 차이를 결정합니다.
• 왜 특정 블록의 코드를 작성했는지 상기시켜주죠
• 파일을 쉽게 디버깅하고 검색할 수 있습니다.

모범 사례 목록

주석 및 문서

• 파일에는 파일 수준 문서 - 작성자, 설명, 이름, 수정자, 날짜가 파일 맨 위에 포함되어야 합니다.
• 이전 사용자의 코드를 삭제하지 마십시오. 댓글 달아주시고 댓글 달아주세요. (코드 수정이 이루어진 경우) 이전 코드를 사용하여 이력을 유지할 수 있습니다.
• 항상 방법이 만들어진 이유를 선언하세요.
• 각 줄에 코멘트를 달지 말고 3~4줄 코멘트하세요.

 

코드 서식

• 코드 서식은 가독성을 향상시키고 의미를 전달합니다.
• 우리는 수직 및 수평 포맷을 적용하여 코드를 포맷해야 한다.
• 수직 서식
• 에세이처럼 코드는 점프를 거의 하지 않고 위에서 아래로 읽을 수 있어야 한다.
• 다른 개념(예: 클래스)이 포함된 파일을 구분해 보십시오.
• 간격은 다른 개념(예: 기능 후 기능, 가져오기 후 클래스)을 구별하는 데 사용해야 한다. )
• 유사한 개념을 분리하기 위해 간격을 사용해서는 안 됩니다.
• 관련된 개념들은 함께 묶어야 합니다.
• 들여쓰기는 프로젝트 전체에서 일관성이 있어야 합니다. 선택한 다음 그대로 사용합니다.
• 수평 서식
• 코드 줄은 스크롤하지 않고 읽을 수 있어야 하며, 너무 긴 문장은 피해야 합니다.
• 기술적으로 필요하지 않더라도 들여쓰기를 사용하십시오.
• 긴 선을 여러 개의 짧은 선으로 나누세요.
• 변수, 함수에는 명확하지만 읽을 수 없는 긴 이름을 사용합니다.
• 예
• 잘못된 코드:

projectMemberInfo =이(가) PROJECT_MEMber.find({ 사용자: req.user)를 대기하도록 합니다._id, createdBy: req.user.currentTeam, 역할: { $in: [managerRole]._id ] }이(가) 활성입니다. { $ne: false }, isDeleted: { $ne: false } }, { 프로젝트: 1, 상태: 1, 시간당 비율: 1, 역할: 1, createdBy: 1 };

• 정상 코드:

let _query = {user: req.user._id, createdBy: req.user.currentTeam, 역할: { $in: [managerRole]._id ] }, isActive: false , isDeleted: false }

 

let _projection = { project: 1, _id: 0, project: 1, 상태: 1, 시간당 비율: 1, 역할: 1, createdBy: 1 }

projectMemberInfo = Waiting PROJECT_MEMber.find(_query, _projection);

명명 규칙

• 이름은 의미가 있어야 합니다.
• 잘 이름 붙여진 "things"는 독자가 당신의 코드를 자세히 살펴보지 않고도 이해할 수 있게 해준다.
• 프로젝트 전체에서 동일한 케이스를 사용합니다.
• 다음 중 하나를 사용할 수 있습니다.
• 뱀자리
• 카메라케이스
• 파스칼케이스
• 케밥상자
• 부울 변수는 "is"로 시작해야 합니다. 예: isValidUser, isOpen, isClosed
• 상수는 항상 Capital, CONNECTION_LIMIT, POOL_SIZE, BATCH_SIZE입니다.
• 클래스의 첫 번째 글자는 Caps(예: Account, Storage, RequestBody, Response)로 시작해야 합니다.
• 함수는 일반적으로 동사로 시작합니다(예: sendData(), getData(), fetchUser()).

함수 및 방법

 

• 각 기능의 상단에 한 두 문장으로 설명하세요.
• 기능을 호출하는 것은 읽을 수 있어야 합니다.
• 논쟁의 개수와 순서가 명확해야 합니다.
• 기능 본문을 읽을 수 있어야 합니다.
• 기능 본체의 길이가 중요하므로 이상적인 기능은 70-80 라인을 초과하지 않아야 한다. 만약 초과한다면 비슷한 개념에 따라 함수 본체를 분할해보세요.
• 함수에는 3개 이상의 루프가 중첩되어 있으면 안 되며, 체크한 경우.
• 함수는 정확히 한 가지 일을 해야 합니다.
• 함수를 순수하게 유지하십시오. (같은 입력 함수는 호출할 때마다 동일한 출력을 생성해야 합니다.)
• 매개 변수의 수를 줄이도록 시도합니다. 만약 불가능하다면 컨테이너에 묶으세요. (프로젝트 작업 중 경험상 매개 변수의 순서와 순서를 항상 기억하는 데 시간을 낭비하고 싶지 않습니다.) (개인 대 개인 의견이지만)

제어 구조 및 오류

• 제어문의 깊은 중첩 방지(루프 및 검사하는 경우 )
• 오류 활용
• 오류를 발견했을 때 반환하는 것보다 오류를 던지는 것이 좋습니다.
• 경비병을 사용하면 빨리 실패한다.
• 예

 

코드 분리 및 리팩토링

 

• 값은 하드 코딩하면 안 됩니다. 대신 ENUM을 사용하십시오.
• 일반적으로 몇 개의 큰 클래스보다 작은 클래스를 선호해야 합니다.
• 모든 계급과 방법은 한 가지 책임이 있어야 한다.
• 클래스는 높은 응집력을 가져야 합니다(클래스가 클래스 속성을 사용하는 정도). )
• 코드 리팩토링 — 예상 동작 변경 없이 코드 구조 변경.
• 일반적으로 일부 측면이 더 효율적으로 작동하거나 더 적은 자원을 사용하거나 더 견고하게 작동하도록 시스템을 수정하는 것을 의미한다.

 

메모리 누수

• 메모리 누수는 더 이상 사용되지 않거나 작업에서 필요하지 않지만 어떤 이유로든 시스템에 반환되지 않는 메모리 부분입니다.
• 전역 변수는 사용하지 않도록 합니다.
• LifeCycle 방법을 사용합니다.
• 제한 시간 및 간격을 지웁니다.
• 불필요한 폐쇄를 만들지 마십시오.
• DOM에서 제거된 요소의 이벤트 수신기를 제거합니다.

프로그래밍 원리

더 나은 코드 구조를 위해 다음 코딩 원칙을 사용합니다.

• KISS ( 단순하게 해, 멍청아)
• 그건 필요 없을 거야
• DREATH ( 반복하지 마십시오.)
• SOLID(단일 책임, 열기/닫기, Liskov의 대체, 인터페이스 분리, 의존성 반전)
• 관심사 분리.
• 데메테르의 법칙.

 

그리고 싱글톤 패턴과 같은 디자인 원리. 전면 패턴, 관찰자 패턴, 장식자 패턴, 공장 패턴, 작성자 패턴.

왜요?

향후 테스트, 디버그 및 관리가 간단한 깔끔한 모듈식 설계를 개발하는 데 도움이 될 것입니다.

DO의

• 기존 애플리케이션의 소스 코드 분석에 집중합니다.
• 다음 단계로 넘어가기 전에 문서가 완성되었는지 확인하십시오.
• 여러분의 기준을 만들지 말고, 대신, 정의된 기준을 따르세요.

 

• 변경된 후에는 테스트를 따라야 합니다.
• 당신의 코멘트가 헷갈리지 않도록 하세요. 외관이 볼품없는 분리대와 분리대는 피해야 한다.
• 파일 이름 및 디렉터리 구조와 일관성을 유지해야 합니다.
• 코드 검토는 생산 전에 완료되어야 합니다.
• 오픈 소스 코드를 읽습니다.
• 신기술에 대한 작업을 실제로 시작하기 전에 모범 코딩 관행에 대해 읽어 보십시오.
• 언어별 서식 및 모범 사례 지침을 따르십시오.
• Pylama의 경우 Linters, JavaScript의 경우 eslint 사용
• 코드 품질 확인을 위한 테스트 사례를 작성합니다.

DON'T

• 전역 변수를 너무 많이 생성하지 마십시오.
• 하드 코딩된 값은 사용하지 마십시오.
• 할당된 메모리가 해제되지 않는 경우. 이러한 경우 LIFE CYCLE 방법을 사용했습니다.
• 댓글이 많이 달렸어요.
• 가독성이 낮습니다.
• 마법의 숫자는 쓰지 마세요.

위에서 언급한 내용과 포인트는 개발자 경험에서 비롯되었습니다. 제가 개인적으로 매일 하는 모든 일에 따르며, 그것이 개발자로서 여러분과 다른 사람들의 차이를 만들어 낼 것이라고 믿습니다. 위의 사항들은 사람마다 의견이 다를 수 있지만요. 당신의 생각을 댓글로 꼭 알려주세요.