베스트 프랙티스 코딩

Coding best practices

코딩 베스트 프랙티스는 소프트웨어 개발 커뮤니티가 소프트웨어 [1]품질을 개선하기 위해 사용하는 비공식 규칙 집합입니다.

많은 컴퓨터 프로그램이 장기간[2] 사용되기 때문에 모든 규칙은 최초 개발 및 그 후의 유지보수와 원저작자 이외의 사람에 의한 개선을 촉진할 필요가 있습니다.

99번째 규칙에 따르면, Tom Cargill은 프로그래밍 프로젝트가 자주 지연되는 이유에 대해 다음과 같이 설명했습니다. "개발 시간의 처음 90%가 코드의 처음 90%를 차지합니다.코드의 나머지 10%는 개발 시간의 나머지 90%를 차지합니다.이러한 선견지명의 부족을 보완할 수 있는 어떤 지침도 고려할 가치가 있다.

프로젝트 또는 프로그램의 크기는 오류율, 프로그래머 생산성 및 [3]필요한 관리량에 큰 영향을 미칩니다.

소프트웨어 품질

주요 기사:소프트웨어 품질

아래 목록과 같이 양호한 소프트웨어와 관련된 많은 특성이 있습니다.이들 중 일부는 상호 모순될 수 있으며(예: 매우 빠른 속도와 광범위한 오류 검사를 수행하는 경우), 고객 및 참가자들마다 우선순위가 다를 수 있습니다.와인버그는 다양한 목표가 필요한 노력과 [4]효율성 모두에 어떻게 극적인 영향을 미칠 수 있는지를 보여주는 예를 제시합니다.게다가 프로그래머는 일반적으로 설정될 수 있는 명시적인 목표를 달성하는 것을 목표로 하고 있으며, 아마도 다른 품질 속성을 희생할 것이라고 그는 지적합니다.

Sommerville은 프로그램의 기능이 아닌 프로그램이 얼마나 [5]잘 수행하는지와 관련된 4가지 일반화된 특성을 확인했습니다.

와인버그는 우수한 프로그램이 [6]충족해야 할 4가지 목표를 확인했습니다.

  • 프로그램이 사양을 충족합니까("가능한 각 입력에 대한 올바른 출력")?
  • 프로그램이 예정대로(및 예산 범위 내에서) 제작되고 있습니까?
  • 변화하는 요구사항에 대처하기 위한 프로그램은 얼마나 적응력이 있습니까?
  • 프로그램이 사용 환경에 충분히 효과적입니까?

Hoare는 소프트웨어 품질과 관련된 다음과 [7]같은 17가지 목표를 확인했습니다.

  • 명확한 목적의 정의
  • 사용의 심플함.
  • 견고성(오용하기 어렵고 오류에 민감함)
  • 조기 가용성(필요에 따라 제시간에 제공)
  • 신뢰성.
  • 경험에 비추어 볼 때 확장성.
  • 간결.
  • 효율성(실시 목적에 따라 충분히 빠름.
  • 개발 최소 비용.
  • 모든 관련 표준에 대한 준수.
  • 명확하고 정확하며 정확한 사용자 문서

전제 조건

코딩을 시작하기 전에 필요한 전제 조건이 모두 완료되었는지(또는 코딩을 위한 견고한 기반을 제공할 수 있을 만큼 충분히 진행되었는지) 확인하는 것이 중요합니다.다양한 전제조건이 충족되지 않으면 소프트웨어는 완성되어도 만족스럽지 못할 수 있습니다.

Meek & Heath: "개발 단계에 이르기 전에 일어나는 일은 종종 프로젝트의 [8]성공에 매우 중요합니다."

아래에 기재되어 있는 전제조건은 다음과 같습니다.

  • 개발은 어떻게 구성되어 있는가?(라이프 사이클)
  • 소프트웨어는 무엇을 하는 것입니까? (요건)
  • 소프트웨어 시스템(아키텍처)의 전체적인 구조
  • 개별 컴포넌트의 상세 설계(설계)
  • 프로그래밍 언어 선택

한 사람만 참여하는 소규모 단순 프로젝트의 경우 아키텍처와 설계를 결합하여 매우 단순한 라이프 사이클을 채택하는 것이 가능할 수 있습니다.

라이프 사이클

주요 기사:소프트웨어 개발 방법론

소프트웨어 개발 방법론은 소프트웨어 제품의 수명 주기를 구조화, 계획 및 제어하는 데 사용되는 프레임워크입니다.일반적인 방법론에는 폭포수, 프로토타이핑, 반복 및 증분 개발, 나선형 개발, 신속한 소프트웨어 개발, 신속한 애플리케이션 개발, 익스트림 프로그래밍 등이 있습니다.

워터폴 모델은 순차적 개발 접근 방식이며, 특히 프로젝트 시작 시 요건을 완전히 정의할 수 있다고 가정합니다.그러나 McConnell은 프로젝트 [9]진행 중 요건이 평균 약 25% 변경된다는 세 가지 연구를 인용했습니다.위에서 언급한 다른 방법론들은 대개 단계적, 증분적 또는 반복적 접근방식으로 그러한 요구사항 변경의 영향을 줄이려고 시도한다.개발 환경에 따라 다른 방법론이 적합할 수 있습니다.

요구 사항들

주요 기사: 요건 엔지니어링

McConnell씨는 다음과 같이 말하고 있습니다.「구축에 들어가기 전에, 우선은, 시스템이 [10]해결할 문제를 명확하게 기술하는 것입니다.」

Meek과 Heath는 명확하고 완전하며 정확하며 모호하지 않은 서면 사양이 [11]목표임을 강조합니다.이 목표를 달성하지 못할 수 있으며, 타겟은 이전 섹션에서 설명한 바와 같이 변경될 수 있습니다.

Sommerville은 보다 상세한 사용자 요건과 보다 상세한 시스템 [12]요건을 구분합니다.또한 기능적 요건(예: 기록 갱신)과 비기능적 요건(예: 응답 시간이 1초 미만이어야 함)을 구분한다.

아키텍처

주요 기사:소프트웨어 아키텍처

Hoare씨는 다음과 같이 지적합니다.소프트웨어 설계에는 두 가지 방법이 있습니다.한 가지 방법은 분명히 결함이 없을 정도로 심플하게 만드는 것이고, 다른 방법은 명백한 결함이 없을 정도로 복잡하게 만드는 것입니다.첫 번째 방법은 훨씬 [13]더 어렵다.

소프트웨어 아키텍처는 무엇을 해야 하는지, 어떤 프로그램 컴포넌트를 해야 하는지 결정하는 것과 관련이 있습니다(어떤 작업을 수행하는 방법은 아래 상세 설계 단계에 따라 결정됩니다).소프트웨어 시스템에 여러 프로그램이 포함되어 있는 경우 이러한 다양한 프로그램 간의 인터페이스를 효과적으로 정의하기 때문에 특히 중요합니다.상세한 것에 대하여는, 유저 인터페이스도 어느 정도 고려할 필요가 있습니다.

이 [14]단계에서는 기능하지 않는 시스템 요건(응답 시간, 신뢰성, 유지보수성 등)을 검토할 필요가 있습니다.

또한 소프트웨어 아키텍처는 다양한 이해관계자(스폰서, 최종 사용자 등)에게 자신의 요건이 충족되는지 확인할 수 있는 기회를 제공하기 때문에 관심을 가지고 있습니다.

설계.

주요 기사:소프트웨어 설계

설계의 주된 목적은 건축 설계에서 얼버무린 세부 사항을 채우는 것입니다.그 의도는 사용할 특정 알고리즘의 세부사항을 포함하여 실제 코딩에 대한 좋은 지침을 제공할 수 있을 정도로 설계가 상세해야 한다는 것이다.예를 들어, 아키텍처 수준에서는 일부 데이터를 정렬해야 하지만 설계 수준에서는 사용할 정렬 알고리즘을 결정해야 한다는 것을 알 수 있습니다.또, 오브젝트 지향의 어프로치를 사용하고 있는 경우는, 오브젝트의 상세(아트리뷰트 및 메서드)를 결정할 필요가 있습니다.

프로그래밍 언어 선택

메이어는 다음과 같이 말한다. "완벽한 프로그래밍 언어는 없다.가장 좋은 언어는 단 한 개도 없다; 단지 특정 목적에 잘 적합하거나 아마도 적합하지 않은 언어만 있을 뿐이다.솔루션에 [15]가장 적합한 언어를 선택하기 위해서는 문제와 관련된 프로그래밍 요건을 이해하는 것이 필요합니다.

Meek & Heath: "언어 선택 기술의 본질은 문제에서 시작하여 그 요건이 무엇인지, 그리고 그것들을 모두 만족시키는 것은 아마 불가능할 것이기 때문에 상대적인 중요성을 결정하는 것입니다.다음으로 사용 가능한 언어를 요건 목록과 비교하여 측정해야 하며, 가장 적합한 언어(또는 가장 만족스럽지 않은 언어)[16]를 선택해야 합니다.

문제의 다양한 측면에 다른 프로그래밍 언어가 적합할 수 있습니다.언어 또는 그 컴파일러가 허락하는 경우, 같은 프로그램 내에서 다른 언어로 작성된 루틴을 혼재시킬 수 있습니다.

어떤 프로그래밍 언어를 사용할지 선택할 수 없는 경우에도 McConnell은 다음과 같은 조언을 제공합니다.모든 프로그래밍 언어에는 장점과 단점이 있습니다.사용하고 [17]있는 언어의 구체적인 장점과 단점을 인식해 주세요.

부호화 기준

주요 기사:부호화 규칙

McConnell이 지적했듯이 이 섹션은 코딩의 필수 조건이기도 합니다. "프로그래밍을 시작하기 전에 프로그래밍 규칙을 확립하십시오.나중에 [17]코드를 일치시키기 위해 변경하는 것은 거의 불가능합니다."

코딩 규약의 말미에 기재되어 있듯이 프로그래밍 언어마다 다른 규약이 있기 때문에 언어마다 동일한 규약을 적용하는 것은 역효과를 낳을 수 있습니다.프로그래밍 언어에 대해 하나의 특정 코딩 규칙이 없다는 점에 유의하십시오.모든 조직에는 소프트웨어 프로젝트 유형별로 맞춤형 코딩 표준이 있습니다.따라서 프로그래머는 소프트웨어 프로젝트를 시작하기 전에 특정 코딩 가이드라인을 선택하거나 작성하는 것이 필수적입니다.일부 코딩 규칙은 특정 프로그래밍 언어로 작성된 모든 소프트웨어 프로젝트에 적용되지 않을 수 있습니다.

코딩 규약은 프로젝트에 여러 명의 프로그래머가 관여하는 경우 특히 중요합니다(수천 명의 프로그래머가 참여하는 프로젝트도 있었습니다).모든 코드가 동일한 규칙을 따른다면 프로그래머가 다른 사람이 작성한 코드를 읽는 것이 훨씬 쉽습니다.

불량 코딩 규칙의 일부 예로서 Roedy Green은 유지관리 [18]불가능한 코드를 생성하는 방법에 대한 장문의(tongu-in-cheek) 기사를 제공합니다.

코멘트

시간 제한이나 코드에 대한 즉각적인 결과를 원하는 열성적인 프로그래머 때문에 코드에 대한 코멘트는 뒷전으로 밀리는 경우가 많습니다.팀워크를 하는 프로그래머는 코멘트를 남기는 것이 좋다는 것을 알게 되었습니다.이는 코딩이 보통 사이클을 따르거나 특정 모듈에서 여러 명이 작업할 수 있기 때문입니다.그러나 일부 코멘트는 동일한 모듈에서 작업하는 개발자 간의 지식 이전 비용을 줄일 수 있습니다.

컴퓨팅 초기에는 다음과 같은 간단한 설명을 남기는 코멘트 작성 방법이 있었습니다.

  1. 모듈 이름
  2. 모듈의 목적
  3. 모듈 설명
  4. 원저작자
  5. 변경 사항
  6. 코드를 수정한 이유와 함께 코드를 수정한 작성자.

"모듈 설명"은 가능한 한 간결해야 하지만 명확성과 포괄성을 희생하지 않아야 합니다.

그러나 마지막 두 항목은 개정 관리 시스템의 등장으로 인해 대부분 폐지되었다.수정사항 및 수정사항의 작성자는 코멘트를 사용하는 것이 아니라 이러한 툴을 사용하여 확실하게 추적할 수 있습니다.

또, 복잡한 논리를 사용하고 있는 경우는, 그 부분 근처에 「블록」이라고 하는 코멘트를 남겨, 다른 프로그래머가 정확하게 무슨 일이 일어나고 있는지를 이해할 수 있도록 하는 것이 좋습니다.

유닛 테스트는 코드가 어떻게 사용되는지 보여주는 또 다른 방법이 될 수 있습니다.

명명 규칙

다음 항목도 참조하십시오.헝가리 표기법

적절한 명명 규칙을 사용하는 것이 좋은 관행으로 간주됩니다.때때로 프로그래머들은 X1, Y1 등을 변수로 사용하고 그것들을 의미 있는 것으로 대체하는 것을 잊어버리는 경향이 있어 혼란을 일으킨다.

보통 설명적인 이름을 사용하는 것이 좋은 관행으로 간주됩니다.

예: 트럭의 매개 변수로 무게를 줄이기 위한 변수는 TrkWeight 또는 TrackWeightKograms로 명명할 수 있으며, TrackWeightKograms가 즉시 인식되기 때문에 선호됩니다.변수의 Camel Case 이름 지정을 참조하십시오.

코드를 단순하게 유지

프로그래머가 작성하는 코드는 간단해야 합니다.간단한 것을 실현하기 위한 복잡한 로직은, 장래에 다른 프로그래머에 의해서 수정될 가능성이 있기 때문에 최소한으로 억제할 필요가 있습니다.한 프로그래머가 구현한 논리는 다른 프로그래머에게 완전히 이해되지 않을 수 있습니다.따라서 항상 코드를 가능한 [19]한 단순하게 유지하십시오.

예를 들어, C 코드의 등가 행은 다음과 같습니다.

한다면 (몇시간. < > 24 & & 회의록 < > 60 & & 초수 < > 60) {     돌아가다 진실의; } 또 다른 {     돌아가다 거짓의; }

그리고.

한다면 (몇시간. < > 24 & & 회의록 < > 60 & & 초수 < > 60)     돌아가다 진실의; 또 다른     돌아가다 거짓의;

그리고.

전환하다 (몇시간. < > 24 & & 회의록 < > 60 & & 초수 < > 60){     사례. 진실의:         돌아가다 진실의;     브레이크.;     사례. 거짓의:         돌아가다 거짓의;     브레이크.;     체납:         돌아가다 거짓의; }

그리고.

돌아가다 몇시간. < > 24 & & 회의록 < > 60 & & 초수 < > 60;

더 일반적으로[dubious – discuss] 사용되는 첫 번째 접근 방식은 네 번째 접근 방식보다 상당히 큽니다.특히 화면 세로공간(줄)이 52자에 비해 5배, 97자(편집툴은 실제 타이핑의 차이를 줄일 수 있음)를 소비한다.그러나 그것은 "더 단순하다"는 논쟁의 여지가 있다.첫 번째는 명시적인 if/그렇지 않으면 명시적인 리턴 값이 각각에 분명히 연결되어 있기 때문에 초보 프로그래머도 이를 이해하는 데 어려움이 없을 것입니다.두 번째는 단순히 버팀대를 폐기하고 개념상 복잡성의 거의 변화 없이 "수직" 크기를 반으로 줄인다.대부분의 언어에서 "return" 문장은 앞줄에 추가될 수 있으며, "vertical" 크기는 4번째 형식보다 한 줄만 더 많습니다.

네 번째 양식은 크기를 최소화하지만 복잡성이 증가할 수 있습니다.이는 "참"과 "거짓" 값을 암시적으로 남겨두고 "조건"과 "반환값"의 개념을 혼합합니다.대부분의 프로그래머에게 명백하지만, 초보자는 조건을 평가하는 결과가 실제로 값(부울형 또는 어떤 언어로든 동등한 유형의 값)이기 때문에 조작되거나 반환될 수 있다는 것을 즉시 이해하지 못할 수 있습니다.보다 현실적인 예에서는 4번째 폼에 오퍼레이터의 우선순위로 인해 문제가 발생할 수 있으며, 일부 언어에서는 이전 폼이 오류를 보고하는 예기치 않은 유형을 반환할 수도 있습니다.따라서 "단순성"은 단순히 길이의 문제가 아니라 논리적이고 개념적인 구조의 문제입니다. 코드를 짧게 할수록 코드가 덜 복잡해지거나 더 복잡해질 수 있습니다.

장기간에 걸친 대규모 프로그램의 경우 장황한 대안을 사용하는 것은 [dubious – discuss]부풀어오르는 원인이 될 수 있습니다.

콤팩트하게 하면, 코더가 페이지 마다 더 많은 코드를 표시할 수 있기 때문에, 스크롤 제스처나 키 입력을 줄일 수 있습니다.작성 및 유지 보수 과정에서 코드가 표시되는 횟수를 고려하면 코드 수명 동안 프로그래머 키 입력이 크게 절감될 수 있습니다.이것은 학생 첫번째 프로그램을 짜는 법을 배우기 중요한지만,하고 유지하는 대형 프로그램 코드들이 얼마나 많은 선의 감소를 생산하는 코드를 화면에 맞지를 위해, 경미한 코드 단순화, 그리고 또한 손가락, 손목과 통신이 눈의 긴장,을 완화시키다 productivity[의심스러운 –을 논의하]을 키울 수 있다. 허용하지 않아 보일지라도.의학적 문제들 가운데에프로덕션 코더와 정보 [20]작업자가 부담합니다.

테서 코딩은 처리해야 할 기호가 적기 때문에 컴파일 속도를 매우 약간 높입니다.또한, 세 번째 접근방식은 유사한 코드 행을 보다 쉽게 비교할 수 있도록 할 수 있으며, 특히 이러한 구조가 동시에 한 화면에 나타날 수 있는 경우에는 더욱 그렇습니다.

마지막으로, 모니터의 레이아웃과 설정에 따라서는, 매우 간결한 레이아웃이 최신의 와이드 스크린 컴퓨터 디스플레이를 보다 효과적으로 활용할 수 있습니다.과거에는 스크린이 40자 또는 80자로 제한되었습니다(원고, 인쇄된 책, 심지어 두루마리까지 수천 년 동안 꽤 짧은 줄을 사용해 왔습니다(예: 구텐베르크 성경 참조).최신 화면에서는 200자 이상의 문자를 쉽게 표시할 수 있어 매우 긴 줄을 사용할 수 있습니다.대부분의 최신 코딩 스타일 및 표준에서는 전체 폭을 차지하지 않습니다.따라서 화면과 같은 크기의 창을 사용하면 사용 가능한 공간이 많이 낭비됩니다.한편, 복수의 창을 사용하는 경우나, 사이드 페인에 다양한 정보가 있는 IDE나 그 외의 툴을 사용하는 경우, 사용 가능한 코드 폭은 이전의 시스템에서 익숙한 범위 내에 있습니다.

또한 인간 시각 시스템은 라인 길이에 크게 영향을 받습니다. 라인이 매우 길면 읽기 속도는 약간 증가하지만 이해도는 감소합니다. 텍스트 열: 얼마나 긴가? 그리고 시선 추적 오류를 추가합니다.일부 연구에 따르면 온라인에서는 Human Factors International 인쇄물보다 긴 줄이 더 낫다고 합니다. 그러나 이것은 여전히 약 10인치 정도밖에 되지 않으며 주로 산문을 읽는 원시 속도입니다.

휴대성

프로그램 코드는 절대 파일 경로, 파일 이름, 사용자 이름, 호스트 이름, IP 주소, URL, UDP/TCP 포트와 같은 환경 매개변수를 나타내는 "하드 코드"(리터럴) 값을 포함할 수 없습니다.그렇지 않으면 애플리케이션이 예상과 다른 설계를 가진 호스트에서 실행되지 않습니다.신중한 프로그래머는 이러한 변수를 매개 변수화하여 적절한 애플리케이션 외부의 호스팅 환경(예를 들어 속성 파일, 애플리케이션 서버 또는 데이터베이스)에 맞게 구성할 수 있습니다.SPOD(Single Point of Definition)[21]의 모토를 비교합니다.

확장으로 XML 파일 등의 리소스에도 리터럴 값이 아닌 변수를 포함해야 합니다.그렇지 않으면 XML 파일을 편집하지 않으면 응용 프로그램을 다른 환경으로 이식할 수 없습니다.예를 들어 J2EE 어플리케이션이 어플리케이션서버에서 실행되고 있는 경우 이러한 환경 파라미터를 JVM의 범위에서 정의할 수 있으며 어플리케이션은 그 값을 취득해야 합니다.

확장성

소프트웨어 프로젝트에서는 항상 새로운 기능이 더 큰 프로젝트에 추가되기 때문에 확장성이 있는 설계 코드를 설계 목표로 합니다.따라서 소프트웨어 코드 베이스에 새로운 기능을 추가하는 기능은 소프트웨어를 작성할 때 매우 귀중한 방법이 됩니다.

재사용 가능성

재사용은 소프트웨어 개발에서 매우 중요한 설계 목표입니다.재사용하는 컴포넌트 또는 모듈이 이미 테스트된 경우 개발 비용을 절감하고 개발 시간을 단축할 수 있습니다.소프트웨어 프로젝트는 이전 버전의 프로젝트를 포함하는 기존 기준선에서 시작하는 경우가 많습니다. 프로젝트에 따라 기존 소프트웨어 모듈 및 컴포넌트의 대부분이 재사용되므로 개발 및 테스트 시간이 단축되므로 소프트웨어 프로젝트를 예정대로 제공할 가능성이 높아집니다.

시공 가이드라인의 개요

위의 모든 것에 대한 개요:

  1. 코드 블록이 수행해야 할 작업을 파악합니다.
  2. 명명 규칙은 전체적으로 균일하게 유지합니다.
  3. 변수의 용도를 간단히 설명합니다(댓글 참조).
  4. 에러가 발생했을 때에 수정해 주세요.
  5. 코드를 심플하게 유지
  6. 확장성과 재사용을 염두에 두고 코드를 설계합니다.

코드 개발

코드 빌드

빌드 코드의 베스트 프랙티스는 매일 빌드 및 테스트, 또는 보다 나은 지속적인 통합 또는 지속적인 전달을 포함합니다.

테스트

주요 기사:소프트웨어 테스트

테스트는 계획할 필요가 있는 소프트웨어 개발의 필수적인 부분입니다.테스트를 사전에 실시하는 것도 중요합니다.즉, 테스트 케이스는 코딩 시작 전에 계획되고 테스트 케이스는 애플리케이션 설계 및 코딩 중에 개발됩니다.

코드 디버깅 및 오류 수정

프로그래머는 완전한 코드를 작성한 후 디버깅과 오류 확인을 시작하는 경향이 있습니다.이 접근방식은 소규모 프로젝트에서는 시간을 절약할 수 있지만, 규모가 크고 복잡한 프로젝트에서는 주의가 필요한 변수와 기능이 너무 많은 경향이 있습니다.따라서 프로그램 전체가 아닌 모든 모듈을 디버깅하는 것이 좋습니다.이렇게 하면 장기적으로 시간을 절약할 수 있기 때문에 결국 무엇이 문제인지 알아내는 데 많은 시간을 낭비하지 않습니다.개별 모듈의 유닛 테스트 및/또는 웹 서비스 및 웹 응용 프로그램의 기능 테스트를 실시하면 도움이 됩니다.

도입

주요 기사:소프트웨어 도입 및 도입 환경

배포는 사용자를 위한 응용 프로그램 릴리스의 마지막 단계입니다.베스트 프랙티스는 다음과 같습니다.[22][23]

  1. 설치 구조를 단순하게 유지합니다.파일 및 디렉토리는 최소한으로 유지해야 합니다.사용하지 않을 물건은 설치하지 마십시오.
  2. 필요한 것만 보관:소프트웨어 구성 관리 액티비티에서는 이것이 실시되고 있는 것을 확인할 필요가 있습니다.사용되지 않는 리소스(오래되거나 실패한 버전의 파일, 소스 코드, 인터페이스 등)는 새로운 빌드를 유지하려면 다른 곳에 보관해야 합니다.
  3. 모든 정보를 최신 상태로 유지:소프트웨어 구성 관리 액티비티에서는 이것이 실시되고 있는 것을 확인할 필요가 있습니다.델타 기반 배포의 경우 델타를 배포하기 전에 이미 배포된 리소스의 버전이 최신인지 확인하십시오.확실하지 않은 경우 처음부터 배포를 수행합니다(먼저 모든 항목을 삭제한 후 다시 배포).
  4. 다단계 전략 채택:프로젝트의 규모에 따라 더 많은 도입이 [24]필요할 수 있습니다.
  5. 롤백 전략을 수립합니다.이전(현용) 버전으로 롤백하는 방법이 있어야 합니다.
  6. 반복 가능한 프로세스를 위해 자동화에 의존:인위적인 실수가 발생할 여지가 너무 많습니다. 도입을 수동으로 진행해서는 안 됩니다.각 운영 체제에 고유한 도구를 사용하거나 크로스 플랫폼 [25][26]배포에 스크립트 언어를 사용하십시오.
  7. 실제 도입 환경 재현: 모든 것(라우터, 방화벽, 웹 서버, 웹 브라우저, 파일 시스템 등)을 고려합니다.
  8. 도입 절차 및 스크립트를 즉시 변경하지 마십시오.또, 이러한 변경을 문서화해 주세요.새로운 반복을 기다렸다가 변경 내용을 적절히 기록합니다.
  9. 도입 커스터마이즈:API, 마이크로 서비스 등 새로운 소프트웨어 제품에서는 도입을 [27][28][29]성공시키기 위해 특별한 고려사항이 필요합니다.
  10. 다른 개발 단계에서 발생하는 위험 감소:테스트나 구성 관리 등의 다른 액티비티가 잘못되어 있으면 도입은 실패합니다.[30][31]
  11. 각 이해관계자가 가지는 영향(조직적, 사회적, 정부적 고려사항)[32][33][34]을 고려합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ McConnell, Steve (2004). Code Complete (Second ed.). Microsoft Press. ISBN 0-7356-1967-0.
  2. ^ Sommerville, Ian (2004). Software Engineering (Seventh ed.). Pearson. p. 38. ISBN 0-321-21026-3.
  3. ^ McConnell, Steve (2004). Code Complete (Second ed.). Microsoft Press. pp. 649–659. ISBN 0-7356-1967-0.
  4. ^ Weinberg, Gerald (1998). The Psychology of Computer Programming (Silver anniversary ed.). Dorset House Publishing, New York. pp. 128–132. ISBN 978-0-932633-42-2.
  5. ^ Sommerville, Ian (2004). Software Engineering (Seventh ed.). Pearson. pp. 12–13. ISBN 0-321-21026-3.
  6. ^ Weinberg, Gerald (1998). The Psychology of Computer Programming (Silver anniversary ed.). Dorset House Publishing, New York. pp. 15–25. ISBN 978-0-932633-42-2.
  7. ^ Hoare, C.A.R. (1972). "The Quality of Software". Software: Practice and Experience. Wiley. 2 (2): 103–105. doi:10.1002/spe.4380020202.
  8. ^ Meek, Brian; Heath, Patricia (1980), Guide to Good Programming Practice, Ellis Horwood, Wiley, p. 14
  9. ^ McConnell, Steve (2004). Code Complete (Second ed.). Microsoft Press. p. 40. ISBN 0-7356-1967-0.
  10. ^ McConnell, Steve (2004). Code Complete (Second ed.). Microsoft Press. p. 36. ISBN 0-7356-1967-0.
  11. ^ Meek, Brian; Heath, Patricia (1980), Guide to Good Programming Practice, Ellis Horwood, Wiley, p. 15
  12. ^ Sommerville, Ian (2004). Software Engineering (Seventh ed.). Pearson. pp. 118–123. ISBN 0-321-21026-3.
  13. ^ Hoare, C.A.R (1981). "The Emperor's Old Clothes" (PDF). Communications of the ACM. ACM. 24 (2): 75–83. doi:10.1145/358549.358561. S2CID 97895. Retrieved 25 Nov 2019.
  14. ^ Sommerville, Ian (2004). Software Engineering (Seventh ed.). Pearson. pp. 242–243. ISBN 0-321-21026-3.
  15. ^ Mayer, Herbert (1989). Advanced C programming on the IBM PC. Windcrest Books. p. xii (preface). ISBN 0830693637.
  16. ^ Meek, Brian; Heath, Patricia (1980), Guide to Good Programming Practice, Ellis Horwood, Wiley, p. 37
  17. ^ a b McConnell, Steve (2004). Code Complete (Second ed.). Microsoft Press. p. 70. ISBN 0-7356-1967-0.
  18. ^ Roedy Green. "unmaintainable code : Java Glossary". Retrieved 2013-11-26.
  19. ^ Multiple (wiki). "Best practices". Docforge. Retrieved 2012-11-13.
  20. ^ "Repetitive Strain Injury". Retrieved 30 October 2016.
  21. ^ 예를 들어 다음과 같습니다.
  22. ^ "7 Application Deployment Best Practices - DZone DevOps". dzone.com.
  23. ^ "The seven deadly sins of software deployment [LWN.net]". lwn.net.
  24. ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
  25. ^ Cruz, Victor (April 3, 2013). "Why 30% of App Deployments Fail". Wired – via www.wired.com.
  26. ^ "The rules of software deployment". Archived from the original on 2010-05-13.
  27. ^ "Tools You Need to Speed Up Deployment to Match Demand". February 3, 2017.
  28. ^ Ankerholz, Amber (September 14, 2016). "DevOps and the Art of Secure Application Deployment".
  29. ^ "Organizing Software Deployments to Match Failure Conditions". Amazon Web Services. May 5, 2014.
  30. ^ "Best Practices for Risk-Free Deployment". TheServerSide.com.
  31. ^ Ambler, Scott. "Effective Software Deployment". Dr. Dobb's.
  32. ^ "Enterprise application deployment: The humanity of software implementation". Archived from the original on 2016-08-21.
  33. ^ "Hacking bureaucracy: improving hiring and software deployment 18F: Digital service delivery". 18f.gsa.gov.
  34. ^ "A Bad Software Deployment Is Worse Than Doing Nothing". Intact Technology. June 1, 2016.
  35. ^ Davis, Alan Mark. (1995). 201 principles of software development. New York: McGraw-Hill. ISBN 0-07-015840-1. OCLC 31814837.
  36. ^ Johnson, Pontus; Ekstedt, Mathias; Jacobson, Ivar (2012). "Where's the Theory for Software Engineering?". IEEE Software. 29 (5): 96. doi:10.1109/MS.2012.127. ISSN 0740-7459. S2CID 38239662.
  37. ^ Krug, Steve (2014). Don't make me think, revisited : a common sense approach to Web usability. Bayle, Elisabeth,, Straiger, Aren,, Matcho, Mark (Third ed.). [San Francisco, California]. ISBN 978-0-321-96551-6. OCLC 859556499.
일반

외부 링크