카우보이 부호화

Cowboy coding

카우보이 코딩은 프로그래머가 개발 과정에 대한 자율권을 갖는 소프트웨어 개발입니다.여기에는 프로젝트 일정, 언어, 알고리즘, 도구, 프레임워크 및 코딩 스타일의 제어가 포함됩니다.

카우보이 코더는 단독 개발자가 될 수도 있고 최소한의 프로세스 또는 [1]훈련으로 일하는 개발자 그룹의 일부가 될 수도 있습니다.일반적으로 비즈니스 사용자가 거의 참여하지 않거나 프로젝트의 광범위한 목표, 일정, 범위 및 비주얼('방법'[citation needed]이 아닌 '방법'이 아닌 '무엇') 등 개발 이외의 측면만 관리하는 경영진의 팬에 의해 운영됩니다.

"Cowboy coding"은 일반적으로 사용을 보다 구조화된 소프트웨어 개발 방법론과 비교했을 때 경멸적인 용어로 본다.

단점들

카우보이 코딩에서 정식 소프트웨어 프로젝트 관리 방법론의 결여는 프로젝트의 작은 규모 또는 실험적인 [2]성격을 나타낼 수 있습니다(반드시 그렇지는 않지만).이러한 속성을 가진 소프트웨어 프로젝트는 다음을 나타낼 수 있습니다.

릴리스 구조의 결여

견적 또는 구현 계획이 부족하면 프로젝트가 지연될 수 있습니다.갑작스런 기한이나 소프트웨어 릴리스에 대한 강요로 인해 "빠르고 지저분한" 기술을 사용하게 될 수 있습니다.이 기술은 나중에 [3]더욱 주의를 기울여야 합니다.

미숙한 개발자

카우보이 코딩은 개발자가 테스트, 버전 제어 및/또는 빌드 도구와 같은 기술에 대해 처음에는 익숙하지 않을 수 있는 취미 활동가 또는 학생 수준에서 일반적으로 소프트웨어 프로젝트에 필요한 기본 코딩 이상일 수 있습니다.

이로 인해 학습에 필요한 시간이 과소평가되어 개발 프로세스가 지연될 수 있습니다.경험이 부족하면 승인된 표준을 무시하여 프로젝트 출처를 읽기 어렵게 하거나 언어 구조의 의미론과 [4]출력 결과 사이에 상충을 일으킬 수 있습니다.

불확실한 설계 요건

실적이 있는 개발 사이클을 사용하고 있는 경우에서도, 커스텀 소프트웨어 애플리케이션에서는, 요건에 관한 클라이언트의 문제가 발생할 가능성이 있습니다.카우보이 코딩은 요건을 합리적인 타임라인으로 확장하지 않음으로써 이 문제를 강조할 수 있으며, 프로젝트가 완료되기 전에 사용되지 않거나 사용할 수 없는 컴포넌트가 생성될 수 있습니다.마찬가지로 눈에 잘 띄지 않는 고객(종종 실험적인 프로젝트, 독립적인 게임 개발 참조)이 있는 프로젝트도 설계 요건에 대한 공식적인 분석이 아닌 코드로 시작할 수 있습니다.설계 분석이 부족하면 테크놀로지의 선택이 부정확하거나 불충분할 수 있으며, 개발자는 프로젝트를 완료하기 위해 소프트웨어를 이식 또는 재작성해야 할 수 있습니다.

불완전성

Extreme Programming과 같은 많은 소프트웨어 개발 모델에서는 소프트웨어가 각 반복의 마지막에 릴리스 가능해야 함을 강조하는 증분 접근법을 사용합니다.관리되지 않는 프로젝트에는 단위 테스트나 작업 반복이 거의 없으므로 불완전한 프로젝트를 사용할 수 없습니다.이와 같이 민첩한 방법론은 카우보이 코딩과 비교되어 왔지만, 민첩한 방법론에는 공식적인 프로세스, 절차, 측정, 프로젝트 관리 및 기타 감시가 있으며 카우보이 코딩에는 이러한 [5][6]사항이 없습니다.

이점

  • 개발자는 실험, 학습 및 결과의 자유로운 배포를 장려할 수 있는 자유로운 형식의 작업 환경을 유지합니다.
  • 이를 통해 개발자는 아키텍처 및 계층 경계를 넘어 설계상의 제한과 결함을 해결할 수 있습니다.
  • 아키텍처에 대해 논의하고 사양을 작성하고 코드를 검토하는 데 시간이 걸리기 때문에 (충분한 경우) 한 명의 개발자가 카우보이 코딩을 통해 더 빨리 작동하는 애플리케이션을 만들 수 있습니다.연구나 프로토타이핑과 같은 작업에는 더 복잡한 방법이 제공하는 코드 품질이 필요하지 않을 수 있습니다.
  • 코딩은 개발자의 자유 시간 동안 수행될 수 있기 때문에, 그렇지 않으면 얻을 [7]수 없었던 프로젝트가 실현될 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Scott, Welker. "cowboy coding". searchsoftwarequality. TechTarget. Retrieved March 2, 2022.
  2. ^ Hughes, Bob and Cotterell, Mike (2006).소프트웨어 프로젝트 관리, 페이지 283-289.맥그로 힐 교육, 버크셔 주ISBN 0-07-710989-9
  3. ^ "In Defense of Waterfall: Deconstructing the Agile Manifesto" (PDF). Retrieved February 1, 2016.
  4. ^ "StickyMinds - STAREAST 2000: Confessions of a (Recovering) Coding Cowboy". StickyMinds. Retrieved February 2, 2016.
  5. ^ "Exploring Agile Development". Pragmatic Software Newsletter.
  6. ^ "StickyMinds - Don't Just Break Software. Make Software". StickyMinds. Retrieved February 2, 2016.
  7. ^ K, Alex. "Google의 '20%의 시간'", 공식 구글 블로그, 2006년 5월 18일

외부 링크