솔직히 카우보이 코딩을 선호합니까? [닫은]

대부분의 프로그래머는 애자일, 워터 폴, RUP 등과 같이 정치적으로 올바른 방법론을 방어합니다. 그들 중 일부는 방법론을 따르지만 전부는 아닙니다. 솔직히, 당신이 방법론을 선택할 수 있다면, 당신은 확실히 주류 "올바른"방법론으로 가거나 카우보이 프로그래밍과 같은 "쉬운"방법론을 선호합니까? 왜?

나는 그것이 의존한다는 것을 안다. 언제 사용하는지 설명하십시오. 카우보이 코딩에 어떤 이점이 있습니까?

Wikipedia의 카우보이 코딩 에 대해 알아보십시오

거의 모든 숙련 된 프로그래머가 3 단계를 거치고 일부는 4 단계를 거친다고 생각합니다.

1. 카우보이 코더 또는 너겟 은 디자인에 대해 거의 알지 못하며 불필요한 형식으로 간주합니다. 비 기술적 이해 관계자를위한 소규모 프로젝트를 수행하는 경우, 이러한 태도는 한동안 잘 해낼 수 있습니다. 그것은 일을 얻는다, 그것은 상사에게 감동을주고, 프로그래머가 자신에 대해 기분을 좋게하고, 그가하고있는 일을 알고 있다는 사실을 확인한다.

2. 건축사 우주 비행사 는 변화하는 환경에 적응하기위한 최초의 공 프로젝트가 실패한 것을 목격했습니다. 모든 것은 다시 작성해야합니다 및 대한 필요성 방지하기 위해 또 다른 미래의 재 작성, 그들은 만들 내부 플랫폼을 아무도 제대로 사용하는 방법을 이해하지 않기 때문에 지원의 4 시간 하루, 지출을 끝낸다.

3. 준 엔지니어 는 실제로 유능 하고 일부 엔지니어링 원칙을 이해 하기 때문에 숙련 된 실제 엔지니어 로 오인하는 경우가 많습니다 . 위험, ROI, UX, 성능, 유지 관리 성 등 기본 엔지니어링 및 비즈니스 개념을 알고 있습니다. 이 사람들은 디자인과 문서를 연속체 로보고 일반적으로 아키텍처 / 디자인 수준을 프로젝트 요구 사항에 맞출 수 있습니다.

   그들은 절대 무오성을 믿는 심지어 시작 등, RUP, 폭포, 민첩 여부를이 시점, 방법론와 사랑에 많은 가을에서 필요 에서 그 실현하지 않고 이러한 방법의 실제 소프트웨어 공학 분야, 그들은 단지 도구입니다 종교가 아니라 불행히도, 그것은 그들이 최종 단계에 도달하는 것을 막습니다.

4. 덕트 테이프 프로그래머 AKA 전문가 또는 고액의 컨설턴트 는 프로젝트 요구 사항을들은 후 5 분 이내에 어떤 아키텍처와 디자인을 사용할지 알고 있습니다. 모든 아키텍처 및 디자인 작업은 여전히 ​​진행 중이지만 직관적 인 수준에 있으며 너무 빨리 진행되어 훈련되지 않은 관찰자가 카우보이 코딩으로 착각 할 것 입니다.

   일반적으로이 사람들은 모두 "충분히 좋은"제품을 만드는 것에 관한 것이므로 그들의 작품은 약간 엔지니어링이 부족하지만 카우보이 코더가 만든 스파게티 코드에서 몇 마일 떨어져 있습니다. 너겟에 대해 들었을 때 너겟은 이들을 식별조차 할 수 없습니다 . 왜냐하면 그들에게 백그라운드에서 일어나는 모든 것이 존재하지 않기 때문입니다.

당신 중 일부는 아마도 내가 그 질문에 대답하지 않은 시점에서 스스로 생각할 것입니다. 질문 자체에 결함이 있기 때문입니다. 카우보이 코딩이 아닌 선택 그것은이다, 기술 수준 , 당신은 당신이 문맹으로 선택할 수있는 것보다 더 코더 카우보이로 선택할 수 없습니다.

카우보이 코더라면 다른 방법을 모릅니다.

건축 우주 비행사가 되었다면 물리적으로 심리적 으로도 디자인없이 소프트웨어를 만들 수 없습니다.

준 엔지니어 (또는 전문 엔지니어) 인 경우, 선제 적 설계 노력이 거의 없거나 전혀없는 프로젝트를 완료하는 것은 명백한 위험에 대비하여 신중하게 수행해야하는 의식적인 선택 (일반적으로 불합리한 마감일로 인해)입니다. 이해 관계자가 동의 한 후에 만 ​​(보통 서면으로)

그리고 덕트 테이프 프로그래머라면 양질의 제품을 신속하게 제작할 수 있기 때문에 "카우보이 코드"에 대한 이유는 없습니다 .

방법론이 아니기 때문에 다른 방법론보다 카우보이 코딩을 "선호"하는 사람은 없습니다. 비디오 게임에서 매싱 버튼에 해당하는 소프트웨어 개발입니다. 초보자 수준에서는 괜찮지 만 그 단계를 지나친 사람은 그렇게하지 않을 것입니다. 그들은 비슷하게 보이지만 같은 것은 아닙니다.

예.

또한 양말을 벗고 바닥에 양말을 놓고 책상에 인쇄물과 오래된 스낵 포장지, 더러운 접시가 가득한 싱크대, 침대를 만들지 않는 것이 좋습니다.

나는 적절한 휴가로 계획된 휴가, 영양 적절한 음식을 염두에두고 먹는 식사, 또는 알려진 트레일에 적절한 하이킹을하는 것으로 간주하지 않습니다.

나는 재미를 즐기고, 놀랍고, 새로운 것을 배우고, 실수를 저지르고, 다시 되돌릴 것인지 확신하지 못합니다. 그리고 가끔, 그 태도는 정확히 지면에서 프로젝트를 얻을 필요가 있는지 ...

...하지만 대부분의 경우 무책임합니다. 춤이 끝나면 파이퍼에게 돈을 지불 할 것입니다.

당신은 정확히 맞습니다. 이 "카우보이 프로그래밍"접근 방식은 코드의 첫 번째 수정 버전을 더 빨리 얻을 수 있지만 시간 절약은 다음과 같은 덕분에 손실 될 것입니다.

• 추가 버그
• 어쨌든했던 버그를 찾는 데 필요한 추가 시간
• 6 개월 안에 변경해야 할 때 수행 한 작업을 기억하기 위해 코드를 리버스 엔지니어링해야 함
• 코드 작업이 필요한 추가 개발자 교육에 소요되는 추가 시간
• 무언가를 망가 뜨리는 변경을 할 때 되돌아 볼 개정 로그가 없습니다.
• 이후 프로젝트에서 쉽게 재사용 할 수있는 모듈이 없음
• 그리고 계속해서

그의 대답에서 언급 한 닐 버터 워스 (Neil Butterworth)와 마찬가지로 때로는해야 할 일을해야합니다. 그러나 일반적으로 소스 코드 제어, 패턴, 문서 등에 시간을 들이지 않고 가능한 빨리 코드를 생성하는 것은 매우 나쁜 습관입니다.

동료를 분석하고 맹목적으로 행동하는 대신 습관이 유익한 지 또는 유해한지를 고려하는 데 좋습니다.

이것은 실제로 단단한 구조를 갖추지 않고 계획에 많은 시간을 소비하지 않고도 올바르게 구현할 수 있는지 여부에 대한 질문으로 이어집니다.

나는 여기에 정말로 인기가 없을 수있는 무언가를 버리겠다 : 고객은 일반적으로 카우보이 방식으로 처리되는 것을 원한다 .

즉, 그들은 무언가를 요청하고 누군가가 그것을 뛰어 넘고 실행하고 거기에서 꺼내기를 원합니다. 프로젝트 관리, 회의, 전화 회의 또는 양식이 없습니다. 그냥 해. 나는 고객에게 "이봐, 이건 우리 취향에 비해 너무 빨리 이루어졌다.

팀 방법론 및 구조는 프로젝트의 경기장을 평준화하고 동일한 페이지에서 동일한 수준으로 동일한 방식으로 다양한 수준의 개발자를 확보하도록 설계되었습니다.

내가 함께 일한 성공적인 "카우보이"는

• 무언가를 빠르게 구현하는 가장 간단한 방법을 식별하십시오.
• 어느 시점에서 고장 날지 알아
• 깨끗하고 읽기 쉽고 간단한 코드 작성
• 사용자가 사용, 남용 및 침입 방법을 예측
• 적절한 장소에서 크기를 조정하고 추상화하고 건축 우주 비행사에게 가지 마십시오.
• 엣지 케이스 및 예외를 처리하는 위치 및 방법 파악

이와 같은 사람들은 관리 및 구조 오버 헤드가 거의없는 진정한 결과를 만들어 낼 수 있지만 드물다.

편집 : 나중에 참조 할 수 있도록 내 대답은 다른 질문에 대한 것입니다.이 질문에 병합되었습니다. 여기가 제 자리를 벗어 났지만 그건 내 전화가 아니었다.

그녀는 단지 게으르고 거만하고 무지하며 극도로 이기적입니다. 이 행동은 무모합니다.

내 말은, 그녀가 틀에 얽매이지 않거나 구식 인 방법론을 사용하는 것은 아닙니다. 그녀는 의식적으로 아무것도 사용 하지 않습니다 . 표준이 없습니다. 품질 보증이 없습니다. 전혀 없습니다. 그녀는 소프트웨어 품질이 어디에서 오는 것을 기대합니까? 나무?
그녀는 분명히 당신이 인용하지 않은 사람들의 경험을 거부합니다. 주장에 의문을 제기 할 수있는 검증 가능한 관련 주장을 제공하는 것이 유효합니다. 그러나 그들의 경험을 거부함으로써 그들을 불신하려고하는 것은 아닙니다.

그러나 주요 요점은 버전 관리에 얼마나 많은 시간이 소요됩니까?
그녀가 매 5 초마다 투자 할 것을 확신 할 수 없다면 상사에게 가져 가야합니다. 버전 관리는 선택 사항이 아닙니다. 마침표.

버전 관리를 사용하고 나면 그녀가 어떤 버그를 도입했는지 쉽게 추적 할 수 있습니다. 그리고 그녀가 고치도록하세요. 그녀가 엉망인데 왜 청소해야합니까? 그녀가 자신의 접근 방식이 더 좋다고 생각한다면, 그 방법을 최대한 활용하십시오 .
그녀가 실제로 (적절한 시간 내에) 그것을 할 수 있다고 가정하면 여전히 문제가 있습니다. 그녀와의 팀워크는 불가능합니다. 그리고 이것은 당신이 그녀를 설득하고 (아마도 들리지 않을 것임), 그녀를 떠나거나 (회사를 위해) 떠나거나 (신성하게하기 위해) 떠나서 해결해야 할 것입니다.
그러나 그녀의 첫 번째 실패는 훨씬 가능성이 높으며 귀하의 요점을 분명히 증명해야합니다. 그리고 그녀는 많은 경험을 가진 많은 사람들이하는 것처럼 모범 사례를 고수하기 시작할 것입니다.

내가 솔로로 일하든 팀에서 일 하느냐에 전적으로 달려 있습니다.

내가 팀에서 작업하는 경우, 몇 가지 규칙과 합의가 필요합니다 - 팀의 모든 사람이 따라야 몇 가지 노력이 호환되도록 공통의 목표를 향해 일을 일반적으로 합의 된 기준을.

그러나 내가 혼자 일한다면 물론 카우보이가되고 싶습니다. 세계의 모든 위대한 창조물은 하나의 마음, 또는 최대 두 개의 작동하는 카우보이 스타일로 발명되었습니다. 몇가지 말하자면:

• 고전 역학? 카우보이 Isaac Newton, 나중에 Laibrange, Hamilton의 Leibniz에서 추가.
• 비행기? 카우보이 라이트.
• 상대성 이론? 카우보이 앨버트 아인슈타인.
• 컴퓨터의 기본 과학? 카우보이 앨런 튜링.
• 트랜지스터? 카우보이 월터 브라 테인과 존 바르 딘.

팀은 점진적으로 개선하고 입증 된 레시피를 기반으로 새로운 시스템을 상당히 신속하게 구성하는 데 능숙하지만 (제대로 진행되고 있다면) 팀이 만든 실제 발명품에 대해 듣지는 않습니다. 팀워크와 필요한 방법에는 장점이 있지만 카우보이 코딩도 마찬가지입니다.

문제에 따라 다릅니다. 우수한 선임 개발자는 문서 페이지와 다양한 패턴과 패러다임을 넘기지 않고 매우 안정적이고 모든 모범 사례를 사용하는 매우 작고 단순하며 강력한 코드를 작성합니다. 그러나 그는 언제 그런 일을 할 여유가 있는지 알게 될 것입니다.

그가 새로운 문제를 겪고 처음부터 수개월이 걸리는 응용 프로그램을 설계하기 시작하면 충격을받을 것입니다. 그러나 플러그인, 간단한 도구 인 경우 2 시간 안에 작성할 수 있습니다.이 기능은 일부 변환을 수행하고 재사용을 목적으로하지 않는 기능이며 실제로 디자인과 패턴은 시간 낭비에만 좋습니다.

또한 디자인의 많은 부분이 이미 선임 개발자 헤드 내부의 백그라운드 스레드에서 처리 된 것 같습니다.

선임 개발자가 계획 단계없이 복잡한 시스템이나 새로운 응용 프로그램의 클래스를 처음부터 시작하기 시작할 때 걱정해야합니다.

상황에 따라 다릅니다. 예를 들어, 일부 비참한 거래 사건 이후, 몇몇 전자 증권 거래소는 모든 거래에 자동 거래 플래그가 추가되었다고 주장했습니다. 그리고 이것은 일주일 안에 모든 거래 소프트웨어를위한 것이 었습니다. 플래그가 없으면 거래를 할 수 없었습니다. 그런 상황에서 모든 모범 사례는 이사회에서 진행합니다. "우리가 말했듯이"해키, 해키, 해키 "만 가면됩니다. 이러한 상황에서 코드를 빠르고 정확하게 작성하는 것이 중요합니다. 특히 사용 가능한 테스트 시스템이 없었습니다.

내 경험에 비추어 볼 때 소스 제어를 사용하는 Cow Boy 코딩은 대규모 소프트웨어 시스템을 개발하는 가장 버그가없는 가장 좋은 방법입니다.

나는 논평가 중 하나가 그 결과에 관한 모든 것을 가지고 있다고 생각합니다.

사람이 양질의 제품을 생산할 수 있고 유지 보수가 가능 하고 신뢰할 수있는 제품을 생산할 수 있다면 공식적인 방법론이나 프로세스를 따르는 것이 중요합니까? 프로세스는 품질의 바닥을 보장하는 데 좋지만 누군가가 이미 그 바닥에서 작업하는 경우 프로세스는 방정식에 아무것도 추가하지 않습니다. 요즘 너무 많은 개발자 인 imo 는 프로그래밍 의 요점 은 좋은 제품 을 생산 하는 것이 아니라 프로세스를 고수하는 것이라고 생각하는 것 같습니다 .

이런 종류의 사람을 해커라고하며 일반적으로 우리 중 더 전문적인 사람에게는 무료 용어가 아닙니다.

알다시피 디자인, 구성 및 제어에 절약되는 시간은 디버깅에서 손실됩니다. 그리고 실제로 어떤 릴리스의 코드가 실제로 제공되었는지 확인했습니다. 당신이 전혀 찾을 수 없다면!

나는 이런 종류의 사람이 너무 자신에 싸여 있다는 것을 알고, 다른 사람들이 겪어야하는 '제한'을 다루기에는 너무 좋다고 생각하고 그들을 귀찮게하지 않는다. 팀은 그들을 정리해야합니다. 또한 버그 수정 프로세스에도 관여하지 않습니다 ( 'l33t 코더의 기술과 재능 아래에서 유지 관리 개발자의 작업).

따라서 다른 곳에서는 일반적인 접근 방법 일 수 있지만 제 위치에서 (그리고 나는이 접근 방식에 경향이있는 선임 코더입니다) 우리는 그것을 겪지 않습니다. 우리가 수많은 프로세스와 절차를 요구하는 것은 아니지만 최소한의 조직, 소스 코드 제어를 요구합니다 (솔직히 말해서 피의 동쪽과 쓸모없는 것입니다!)

켄트 벡 (Kent Beck) 등은 오래된 프로세스가 많이 사용 된 방식이 나쁘다는 것을 알고있는 전문가들이므로 코딩을보다 기술 지향적으로 유지하면서 코딩을 구성 할 수있는 새로운 방법론을 만든 다음 다른 사람들에게 책을 출판하여 알려주었습니다 ( 인터넷 이전에 다른 방법은 무엇입니까?)

다른 사람이 해킹 할 수 없기 때문에 열악한 연습을 받아들이지 마십시오. 팀장이나 관리자가이 '락스타'를 열심히 타야하지만, 그렇지 않은 경우에도 그렇다고해서 여전히 올바른 일을 할 수는 없습니다. 그녀가 조여지면 (그리고 그녀는 할 것입니다!) 그녀의 거친 행동을 받아들이지 말고 청소하십시오. 코딩 생산성을 저하시키지 않으면 서 모범 사례 (및 그 내용을 알고 있음)를 고수하면 미래에 유리할 것입니다.

여기 에세이 진정한 통찰력있는 작가의가. 문제를 해결하지는 않지만 문제의 원인과 전문가를 다루는 몇 가지 팁에 대한 통찰력을 제공합니다.

유일한 중요한 사실은 팀의 장기적인 제품 결과입니다.

한 명의 위대한 프로그래머 (또는 그 이상)를 포함하는 팀이 평균 속도로 코딩하는 평균 프로그래머 수가 훨씬 많은 팀보다 더 나은 결과를 얻을 것이라는 주장이 있습니다.

카우보이가 정규 프로그래머가하지 않은 물건을 생산하고 (소멸 기한 또는 사양에 대해) 카우보이 팀이 카우보이의 혼란을 정리하는 데 몇 주 / 몇 달을 소비 해야하는 경우에도 여전히 더 나은 결과를 빨리.

카우보이와 팀이 수개월 / 수년이 지난 후에도 엉망을 정리 (문서화, 디버그, 통합, 유지) 할 수 없다면, 카우보이가 발전시킨 것이 장기적으로 유리한 점은 아닙니다.

팀을 결정하고 팀 명단을 최적화하십시오.

최종 결과가 좋은 한 모든 프로그래머가 같은 방식으로 작동하거나 작동하지는 않습니다.

Frankly에 대한 내 대답에서 통찰력을 찾을 수 있습니다. 카우보이 코딩을 선호합니까? 문제는 "카우보이 코딩"은 사람들마다 다른 것을 의미하며, 훈련되지 않은 눈에, 즉 어떤 버전을보고 있는지는 분명하지 않습니다.

누군가가 문제를보고 즉시 빠르고 정확하게 코드를 작성하기 시작할 때, 그것은 수천 번 전에 그것을보고 이미 문제를 해결하는 가장 좋은 방법을 알고있는 마스터 엔지니어의 표시 일 수 있습니다.

또는 아마추어 계급의 표시 일 수 있습니다.

한 가지만 말씀 드리겠습니다. 버전 관리 사용 또는 테스트 작성이 너무 "학술적"이기 때문에 거부하는 것은 "고급 적"이거나 원격으로 전문적인 접근 방식이 아닙니다 . Microsoft 나 Google과 같은 주요 소프트웨어 상점에서는 이런 종류의 일이 결코 일어나지 않을 것이며, 대부분의 신생 기업이나 합리적으로 성숙한 기업 팀에서도 볼 수 없을 것입니다.

위험이 너무 큽니다. PC가 밤새 죽으면 어떻게됩니까? 작별 3 년의 생산성. 좋아, 그래서 당신은 백업을합니다; 그러면 큰 변화를 겪고 완전히 틀렸다는 것을 깨닫고 되돌려 야 할 때 어떻게됩니까? 요구 사항 이 잘못 되었기 때문에 가장 숙련되고 재능있는 개발자에게도 해당됩니다 . 어떤 종류의 버전 제어를 실행하지 않으면 진흙에서 바퀴를 돌리는 것입니다. 나는 한 번 거기에 있었고 결코 다시 는 가지 않을 것입니다.

변명의 여지가 없습니다. 리포지토리를 설정하는 데 10 분, 커밋을 수행하는 데 10 초가 걸립니다. 전체 개발 시간의 1 %를 구성 할 수 있습니다. 급한 경우 테스트는 하루에 20-30 분으로 쉽게 중단 할 수 있으며 여전히 유용합니다.

나는 애자일 (자본 A 참고) 방법론을 좋아하지 않지만 때로는 소매를 감아 서 코드를 작성해야 할 때가있다. 나는 "분석 마비"를 가진 사람들과 팀을 보았고 생산성은 실제로 눈에 띄는 것으로 나타났습니다. 그러나 개정 관리 및 테스트와 같은 우리 무역 의 기본 도구를 해고하는 것은 실제로 나를위한 클린 처입니다. 이 사람은 고위직에 속하지 않습니다 .

예,하지만하지 말아야 할 시점을 인식해야합니다.

작은 것이면 아마 괜찮을지 모르지만 복잡하고 위험하고 제약이있는 무언가가 있다면 적절한 디자인이 여분의 시간이 가치가있을 때 인식 할 수 있어야합니다.

또한 Aaronaught의 답변을 통해 반드시 생각해야한다고 생각합니다. 카우보이는 사람들마다 다른 것을 의미합니다.

"전통적인"방법론을 생각할 때, "관리는 개발자를 이해하는 방법을 알지 못하므로 개발자 세계에 들어 와서 진행 상황을 알기에 충분히 이해하는 대신 개발자가 자신의 세계로 들어 오게합니다"라고 생각합니다.

기본적으로 "Agile"을 생각할 때 "여러 사람이 함께 일하는 비 효율성을 최소화하기 위해해야 ​​할 일을합니다"라고 생각합니다. 그래서 내가 "와 같은 것이 없음 캠프에 단단히 해요 애자일 방법론 , 가치와 원칙 단지 세트".

다시 말해, 매우 큰 프로젝트에서해야 할 일이 있고, 작은 프로젝트에서해야 할 일이 있으며, 두 가지 모두에서하는 일이 있다는 것입니다.

예를 들어, 내가 작업하고있는 프로젝트에 대한 가장 간단한 백 로그를 가지지 않을 것입니다. 단지 할 일 목록 일뿐입니다. 우리 중 두 명이 있다면 아마도 그 목록을 공유 할 것이지만 매우 간단한 형식 (아마도 코드 저장소에 저장된 메모 일 것입니다). 3 또는 4가 있으면 일종의 작업 항목 시스템을 찾고 있습니다.

매우 간단한 기능의 프로토 타입 제작시에만 가능합니다.

그런 다음 올바른 방법을 고려하고 코드를 버리고 심각해집니다.

나는 실제 프로젝트 (Samura Night Programming에서 Samurai Tailor 일련의 스케치 후 Samurai Programming이라고 불렀을 때)에서 한 번 해냈으며 놀랍게도 잘 작동했습니다. 물론 처음부터 쓰레기는 쓰레기 였기 때문에 악화시킬 위험은 거의 없었습니다.

그러나, 나는 마음에 "정말"이고 힙합 스타일의 개발 스타일을 싫어합니다.

다른 한편으로, 프로세스가 많이 포함 된 modus operandi도 제 취향에 맞지 않습니다. 나는 행동하기 전에 계획하고 싶습니다.

전체적으로 적절한 공식 프로세스의 양은 프로젝트의 규모 (프로젝트의 크기, 프로젝트 기간, 개발자 수, 요구 사항 등)에 따라 크게 좌우된다고 생각합니다. 예를 들어, 게임의 경우, 실패와 관련하여 훨씬 적은 단점이 있기 때문에 엄격하고 체계적인 개발 관행의 비용과 부담이 실제로는 아닙니다. 정당화.

그것은 프로젝트의 크기에 달려 있습니다. 한편, 당신이 필요 괜찮은 결과를 얻을 수 있는 디자인을. 다른 한편으로, 프로젝트를 작게 작성하거나 다이어그램을 작성하지 않고 전체 디자인을 개념화 할 수있을 정도로 작다면 (아마도 대부분) 프로젝트의 추가 작업 없이도 잘 작동 할 수 있습니다. 당신이하는 모든 것을 문서화합니다.

거의 모든 사람들은 자신이하고있는 일과 진행 상황에 대한 명확한 아이디어없이 뛰어 들어가는 것이 재난의 요리법이라는 것을 깨달을 수있는 충분한 공포 이야기를 들었습니다. 훨씬 드물게 지적 된 것은 그 반대가 똑같이 비참 할 수 있다는 것입니다. 예를 들어, 대부분의 사람들은 일상적으로 프로그래밍 과정에서 작은 도구를 작성합니다. 완전한 사양, 테스트, 문서 작성은 종종 가치가 없습니다. 제품화가 가치가없는 한계가 있습니다. 사람들은 종종 바퀴를 재발 명하는 것을 싫어하지만 어떤 경우에는 피하는 것보다 재발 명하기가 더 쉽습니다.

이런 경우에, 무엇을 종종 것은 입니다 보람이 쉽게 같은 작업을 할 라이브러리를 productizing된다. 이를 통해 프론트 엔드 코드가 너무 사소 해져 원하는 것을 수행하기위한 코드 작성 (또는 수정)이 원하는 프로그램을 완성하는 방법을 분류하는 것보다 쉬워집니다. 예를 들어, gnu는 50 가지 이상의 서로 다른 플래그로 들여 쓰기를 고려합니다. 그중 다수는 다양한 미묘한 방식으로 상호 작용하므로 합리적인 선택은 1) 전혀 사용하지 않거나 2) 제공하는 것을 좋아하기로 결정합니다. 원래 원하는 것을 얻으려고 노력하는 대신.

캠프에는 결과를 선호하는 사람들과 원칙을 선호하는 사람들이 있습니다. 나는 후자에 빠진다.

나는 평범한하지만 틀림없이 양심적 프로그래머입니다 - 코딩 내 주요 관심사 를 넘어 일을 받고, 나는 그들의 일을 끝내야 내 코드를 사용하여 누구든지 돕고 있다는 것입니다. 나는 항상 그것을 달성했다고 말할 수는 없지만 그것이 내가 목표로하는 것입니다.

물론, 팀에 핫로드 가 있을 수 있습니다.하지만 몇 주가 걸리고 작업을 디버깅하거나 추가하라는 메시지가 표시되면 어떻게됩니까? 궁극적으로 카우보이 프로그래머는 팀 플레이어가 아닙니다. 그들은 훌륭한 코드를 만들지 만 팀이 그들에게 의존한다면 위험합니다.

나는 그녀의 스타일에 대한 당신의 불쾌감 때문에 약간의 오해를 불러 일으킨다는 느낌이 들었습니다. 당신 은 카우보이 접근 방식이 디버깅 비용을 지불 한다고 말합니다 -이것이 이미 일어나고 있습니까, 아니면 어떻게 실행 될지에 대한 가정입니까?

공정한 공개-나는 선임 개발자이며, 종종 디자인과 경험을위한 공식적인 프로세스를 포기합니다. 문제 영역에서 경험이 많은 사람에게 공식적인 프로세스를 갖지 않는 것이 일반적입니다. 수십 시간 동안 문제를 해결 한 경우 유사한 솔루션을 다시 공식화하기 위해 공식적인 프로세스가 필요하지 않습니다.

공식적인 프로세스는 코드 디자인을 다루고 있습니다-공식적인 프로세스가 없기 때문에 왜 더 많은 버그가 도입되어야하는지 모르겠습니다. 귀하의 계정에서 읽은 유일한 큰 문제는 개정 관리가 사용되지 않는다는 것입니다. 이는 이기적 일뿐 만 아니라 개발자를 위해 무모한 것입니다. 그녀는 실제로 커밋하지 않습니까, 아니면 좋아하는 패턴으로 커밋하지 않습니까?

디자인에 대한 공식적인 접근 방식이없는 것은 필자의 책에서 '카우보이 코딩'이 아닙니다 (리비전 제어를 사용하지는 않음). '충분한'솔루션을 마련하는 데 필요한 시간을 줄이려면 경험을 정확히 사용해야합니다. 앞으로 발생할 수있는 시나리오를위한 설계가 아니라 현재의 문제를 해결하고 코드를 쉽게 변경할 수 있도록해야합니다. 경험이 있으면 매우 빠르게 수행하는 방법을 알 수 있습니다.

아뇨.

항상 요구 사항 분석을 수행하고 아키텍처에 대해 생각하고 세부 사항을 디자인 한 다음 코딩합니다. 개인 프로젝트를 위해 집에서 혼자 일하는 경우에도 마찬가지입니다.

카우보이 스타일로 작업하고 있다면 팀의 개발자를 즉시 ​​해고 할 것입니다. 우리는 엔지니어이며 고객과 사용자에게 책임이 있습니다.

카우보이 코딩이 선임 접근법이라고 생각하지 않습니다.

다른 사람들이 말했듯이 버전 관리를 버리는 데 실제로 위험이 있습니다. 문서와 분석을 생략하면 사용자가 원하지 않는 것을 전달할 위험이 있습니다. 내 의견이지만, 카우보이 코드 만 있으면 "코더에서 개발자로"갈 수 없다고 생각합니다.

그러나 Neil Butterworth가 언급 한 것과 같은 예외가 있습니다. 그리고 이런 상황에서, 숙련 된 선임 개발자가 카우보이 코딩을해야하는 사람이 되길 바랍니다.

카우보이 프로그래밍은 큰 진흙 공을 만드는 확실한 방법입니다 . 들리는 것처럼 불쾌한 것은 전달하는 경향이 있습니다 ...

나는 새로운 프로그래머가 프로젝트 / 스코프의 측면을 취할 때 카우보이 코딩 일을하는 경향이 있다고 생각합니다. 사용하기에 적합한 패턴에 대한 지식이 부족하고 "길을 뚫고 지나갔 기 때문에"이 경로를 몇 번 확실히지나 갔다는 것을 알고 있습니다.

저와 당신이 불평하는 사람의 차이점은 내가 보통 더 빨리 할 수 ​​있고 더 잘 유지할 수 있다는 것을 깨닫고 곧 더 많은 것을 배우고 내 기술을 향상시키는 데 박차를가한다는 것입니다. 제목). 이러한 해킹 된 솔루션 중 일부를 디버깅하기 위해 되돌아 가면 보통 그것이 고통스럽고 "올바른 방법"을 수행하는 방법을 배우고 자하는 데 더 도움이됩니다. 나는 당신이 묘사하고있는이 사람은 기본적으로 유아의 자기 반성 수준에 갇혀 있으며 자신의 자아가 실제로 소프트웨어 개발자로서 기술을 향상시키는 데 방해가된다고 생각합니다.

나는 당신의 게시물이 재미 있다고 생각합니다. 나는 종종 당신의 주제와 의견을 공유했으며, 그녀의 느낌은 지나치게 공식화 된 방법이 방해가된다는 것입니다. 다른 사람이 지적했듯이, 그녀가 천재이고 혼란 스럽거나 혼란스럽게하지 않고 동시에 많은 정신 메모를 추적 할 수 있다면 복잡한 코드의 모 놀리 식 덩어리를 유지하고 완전히 모호한 변경으로 놀라운 일을 할 수 있습니다 . 그것을 할 수있는 사람들의 두뇌에 오는 어떤 정신적 행복이 있습니다. 그것은 당신의 마음 속에 작은 우주의 신이되는 것과 같습니다.

그러나 현명한 고용주는 그 누구도 그 코드에 대해 가치있는 일을 할 수없는 어려운 방법을 배웠습니다. 프로그래머가 계속 움직일 경우, 유일한 옵션은 다시 작성하는 것임을 알아내는 데 많은 돈을 낭비하게됩니다. 외부 기능 수준에서의 반복 개발).

개인적으로, 나는 팀에서 그런 사람을 갖는 것을 좋아하지 않을 것입니다.

다른 한편으로, 당신 자신의 사람이되어서 당신의 질문에 대한 답이 무엇인지 스스로 결정하십시오. 왜냐하면 확실하게 유일한 것은 소프트웨어를 만들 때 아무도 알아낼 수 없기 때문 입니다. 그것은 흥미로운 분야로 만드는 것들 중 하나입니다 ...