모범 사례 채택의 장벽은 무엇입니까? 어떻게 극복 할 수 있습니까? [닫은]

우리는 모두 잘못 작성된 코드를 많이 보았습니다. 왜? 우리가 좋은 습관보다는 나쁜 습관을 채택하게하는 이유는 무엇입니까?

(나에게) 가장 분명한 대답은 "무지"이지만 이것이 유일한 이유는 아니라고 확신합니다. 다른 사람이 있습니까? 나쁜 코드를 작성하려는 유혹을 극복하기 위해 무엇을 할 수 있습니까?

변화에 대한 저항.

이것이 무지, 경영 부진 등의 주요 원인입니다.

이 주제는 Peopleware 2nd Edition의 30 장 입니다. 그리고 그것은 조금 더 일찍 작성된 다른 잘 알려진 컨설턴트에 의해 책에서 인용됩니다 :

그리고 처리하기가 더 어렵고, 성공에 대한 의심이 많거나, 관리하기에 더 위험한 것은 새로운 명령을 도입하는 데 앞장서서는 안된다는 것을 고려해야합니다. 도입 자에게는 옛 명령으로부터 이익을 얻는 모든 사람들이 적으로서 있고, 새로운 명령으로부터 이익을 얻을 수있는 모든 사람들에게 미지근한 수비수가 있습니다.

니콜로 마치 아 벨리 : 왕자 (1513)

DeMarco와 Lister는 사람들에게 변경을 요청하기 전에 명심해야 할 만트라를 계속 설명합니다.

변화에 대한 근본적인 반응은 논리적이 아니라 감정적입니다.

변화의 과정이 현재의 차선책에서 새로운 개선 된 세상으로 직진하고 순조로운 추진을하는 경우는 거의 없습니다. 사소한 변화 가 있더라도 새로운 현상에 도달하기 전에 항상 혼란과 혼란의시기가 있습니다. 새로운 도구, 프로세스 및 사고 방식을 배우는 것은 어렵고 시간이 걸립니다. 이 전환 시간 동안 생산성이 떨어지고 사기가 나 빠지고 사람들은 불만을 품고 좋은 일을하는 오래된 방법으로 돌아갈 수 있다면 원할 수 있습니다. 좋은 문제는 알려진 문제가 새롭고 알려지지 않은 좌절스럽고 창피한 문제보다 낫다고 생각하기 때문에 종종 모든 문제를 겪습니다. 이것은 재치 있고 부드럽게 이루어져야하지만 성공하기 위해 결정적으로 극복해야하는 저항입니다.

인내와 인내로 결국 팀은 카오스에서 다음 단계 인 연습과 통합으로갑니다. 사람들은 새로운 도구 / 프로세스에 완전히 익숙하지는 않지만 이러한 도구를 익히기 시작합니다. 긍정적 인 "Aha"경험이있을 수 있습니다. 그리고 점차적으로 팀은 새로운 상태를 유지합니다.

혼란은 변화 과정에서 불가피한 불가결 한 부분 이라는 것을 아는 것이 정말 중요합니다 . 이 지식과 ​​그 준비가 없으면 혼돈 단계에 닥칠 때 당황 할 수 있으며 새로운 현상으로 착각 할 수 있습니다. 결과적으로 변경 프로세스가 취소되고 팀은 이전의 비참한 상태로 돌아 오지만 아무것도 개선 할 희망은 거의 없습니다 ...

참고로 위에서 설명한 단계는 원래 Satir Change Model ( 버지니아 Satir의 이름을 따서 명명)에 정의되었습니다 .

Péter Török 은 옳지 만 중요하고 낙관적 인 점은 하나도 생략했습니다.

• 사람들 은 자신이 관여 한 변화를 좋아할 수도 있지만, 그들에게 "일어나는"변화는 거의 좋아하지 않습니다.

참여하고 아이디어를 내놓고 이해 관계를 맺게하세요. 그렇게 아프지 않을 것입니다.

참고 : 이것은 기술적으로 성공적인 많은 소프트웨어 프로젝트 가 사용자가 거부 하기 때문에 실패한다는 점에서 프로그래밍과 관련이 있습니다 .

시간은 내가 일하는 큰 것 같습니다.

예 : 더 많은 코드를 작성해야 할 때 단위 테스트를 채택하여 릴리스 가능한 제품을 얻는 데 시간이 더 걸리는 이유는 무엇입니까? 클라이언트 x는 지금 그것을 원합니다! 더 빨리 코딩하십시오!

(이것은 분명히 잘 끝나지 않습니다)

이는 또한 관리 및 경제가 열악하여 고객이 올바른 일에 시간을 할애 할만큼 충분한 비용을 청구하지 않는 결과입니다.

반대의 증거가 많음에도 불구하고 사람들은 대개 매우 합리적인 생물입니다. 사람들이 TDD와 같은 모범 사례를 채택하지 않는 이유는 가치가 있다고 생각하지 않기 때문입니다. 그들은 실제로 그 관행이 최선이 아니라고 생각한다. 실제로 저장하는 것보다 비용이 더 많이 듭니다. 아니면이 혜택의 비용 정도로 한계라고 생각 변화가 작은 혜택을보다 중요한 것입니다. 결론은 모범 사례의 문제가 결론의 문제라는 것입니다.

변경 상담원이 되려면 업무에 대한 인식에 결함이 있음을 입증해야합니다. 모범 사례가 실제로 최고라는 것을 보여 주어야합니다 . 이점이 즉각 적이고 중요 하다는 것 . 학습 곡선이 인내하기에 충분히 작으며 적어도 일부 혜택이 즉시 시작됨을 보여 주어야합니다.

이것을 어떻게 보여줍니까? 모범 사례를 스스로 채택함으로써! 자신의 행동보다 다른 사람을 더 잘 설득시키는 것은 없습니다. 경우 당신이 가장 좋은 방법을 따르고, 그것에 대해 보컬입니다, 다른 것을 볼 수 있습니다 당신은 경제적 분석을했고, 그 반대의 결정을 내렸다. 그것은 그들의 결정을 재고하게 할 것입니다. 그들은 이것을 개인적으로 할 것이며 처음에는 절대 인정하지 않을 것입니다. 그러나 당신이 그 모범 사례를 사용하는 것을 보는 모든 사람들은 그들의 입장을 다시 검토 할 것입니다.

그것이 당신이 기대할 수있는 최선입니다. 모범 사례 가 모범 사례 인 경우 나머지는 자동으로 수행됩니다. 오, 빠르지는 않을 것이고 많은 홀드 아웃이있을 것입니다. 전환이 느리고 얼룩이납니다. 그리고 당신은 많은 실망을 경험할 것입니다. 그러나 전환도 불가피하고 불가피 할 것입니다. 세대가 걸릴 수도 있지만 모범 사례 가 이길 것입니다.

그 증거로 누군가가 goto를 사용하는 것을 마지막으로 본 적이 있는지 스스로에게 물어보십시오.

자신이 이상적인 방법을 알고 있다고 생각 하지 않거나 생각한 결과입니다 . 사람들은하지 않는 선택 제대로 쓰기 코드; 더 잘 모르는 경우가 더 많습니다. " 무지 " 와 반대되는 " 순진 " 은 더 나은 단어 일 것입니다.

모범 사례를 준수하는 가장 간단한 방법은 방금 작성한 코드를 작성하고 '더 나은 방법'이 무엇인지 배우고 자하는 더 나은 방법이 있다는 것을 인정하는 것입니다.

두 가지 원인

• 무지.

• 거만.

어떻게 극복 할 수 있습니까?

• 인센티브.

관리자 (즉, 개발자의 기술을 구매 하는 사람들 )가 소프트웨어 제공의 일부로 모범 사례를 요구할 때까지는 아무것도 변할 수 없습니다. 많은 조직이 정신 분열증 환자입니다. 다양한 기술을 개발자에게 교육 한 다음 테스트되지 않은 소프트웨어 또는 테스트 할 수없는 디자인을 요구합니다. 또는 더 나쁘다.

저에게 가장 좋은 방법은 8 명으로 구성된 팀이 작성한 소프트웨어입니다. 우리는 서면 요구 사항, 코드 검토, 단위 테스트, 형식 릴리스 문서가 없었습니다. 최종 사용자 테스트도없고 모든 책에서 우리가해야 할 말은 없습니다. 코드는 서두르고 버그가 많으며 유지 관리가 불가능합니다. 석방 된 지 3 년 만에 폐기되어 너무 나빴습니다. 그래서 무엇이 좋았습니까? 첫 번째 석방 후 2 년 만에 회사 소유주 (자택에 모기지로 개발 자금을 지원 한)는 백 포켓에서 3 천만 ~ 4 천만 달러를 버렸습니다.

우리는 종종 비즈니스를 위해 돈을 버는 소프트웨어를 만들기 위해 여기에 있다는 사실을 잃어 버립니다. "모범 사례"를 사용하여 소프트웨어를 개발할 수있는 기회를 제공하는 비즈니스는 존재하지 않으며, 돈을 벌기 위해 존재합니다.

대부분의 "모범 사례"사례는 수익을 향상시키지 않습니다. 그렇게하고,해야하고, 널리 채택 된 것들. 이것이 "모범 사례"가 실행되지 않는 이유입니다.

허용 가능한 위험

위험을 감수하고 무언가에 도박을 한 적이 있습니까? 시간 위기가 있기 때문에 나중에 리팩토링하려는 의도로 빨리 작동시킬 수 있습니다. 실제로 일부 사람들에게는 좋은 습관으로 간주됩니다.

결국, 당신은 충분한 시간을 태우고 길을 바꿉니다. 거기에있는 '모범 사례'를 모두 생각해보십시오. 당신은 항상 그들 모두를 따라갈 수 있습니까? 서로 모순이 있습니까? 모든 이상 치를 처리하는 데 시간을 낭비하고 싶지 않습니다.

작동하는 잘못된 코드를 작성하고 아무도 다시 보지 않으면 여전히 잘못된 것으로 간주됩니까? ( '불량 코드'가 무엇인지 논쟁하면서 철학적 논쟁을 망치지 마십시오.)

IME는 다른 사람들이 말한 것의 조합입니다. 무지 ( "나는 LINQ를 방해하는 이유는 무엇입니까?" 이해 ( "코드 숨김으로 모든 코드를 작성하는 데 문제가 있습니까?")가 모두 기여합니다.

내가 본 아이러니는 일단 당신이 그 길을 시작하면, 당신은 단지 더 깊이 빠져들게됩니다. 지금 모서리를 자르고 ASPX 파일에서 앱의 모든 코드를 던져도 나중에 나중에 고칠 수는 없습니다. 새로운 것들이 당신에게 계속 던져 질 것입니다. 즉, 빨리해야한다는 것을 의미합니다. 즉, ASPX 파일의 모든 코드를 던져야합니다 (언젠가 고칠 것이라고 맹세합니다) 등. 더 이상 개발을 중단 할 수없고 상황을 먼저 수정해야하므로 나선이 사라집니다.

종종 개발자들은 단순히 더 나은 연습을하거나 더 나은 연습을 사용하는 것의 이점을 보여주지 못했습니다 (다양한 이유로 '최상의 연습'이라는 용어 사용을 중단하기 시작했습니다).

개발자들이 '고의적으로 게으르다'는 이론이 있습니다. 다시 말해 저항이 가장 적은 경로를 선택하는 경향이 있습니다.

TDD 또는 SOLID 원칙을 따르는 더 나은 연습의 이점을 신속하게 보여주고 실제로 더 나은 (하지만 여전히 '게으른') 개발자가 될 수 있다면 저항이 녹는 경향이 있습니다. 떨어져.

그것은 교육의 문제입니다 :)

지식과 기술 + 투자 시간

다른 사람이 이것을 내놓지 않은 것에 놀랐습니다.하지만 내 작업의 많은 부분이 무언가에 어려움을 겪을 때 아무도 (스택 제외)가 아닌 싱글 톤 프로그래머 였기 때문에 나에게 분명합니다. 나는 TDD와 같은 더 나은 기술을 알고 있지만 종종 그것을 사용하기에 충분히 이해하지 못하고 사용을 시작하는 데 도움이되는 좋은 정보를 찾는 데 어려움을 겪고 있습니다. 다시 TDD를 예로 사용하여 코드의 기본 의미를 이해합니다. 코드 출력에 특정 결과를 나타내는 테스트를 빌드하지만 실제로 구현합니까?

요즘 XCode에 단위 테스트가 내장되어 있다는 것 외에는 어디에서 시작할 지에 대한 실마리가 없습니다. 루틴을 실행하여 뷰를 만들면 뷰에 X 버튼이 있다고 주장합니까? 회전 태그를 호출 한 후 UIView가 적절하게 재 배열되었다고 주장하는 것은 어떻습니까?

도대체 어떻게 XCode에서 단위 테스트를 작성 합니까? 그것은 배우는 데 시간을 할애해야 할 다른 것입니다.

@Zues와 @Joshua Smith

예, 때로는 시간과 예산이 알고있는 모든 "더 나은 프로그래밍"원칙을 프로그램에 적용 할 수없는 몇 가지 제약 조건에 동의합니다.

시간이 더 있으면 현재 작업을 훨씬 더 강력하게 수행 할 수 있습니다. 그러나 고객이 더 적습니다 (특히 첫 번째 iPhone App을 완성하거나 사용자 지정 비즈니스 인텔리전스 소프트웨어를 처음으로 사용하는 경우).

단위 테스트와 동일합니다. 불행히도 아직 예산을 할당 할 준비가 된 고객을 만나지 못했습니다. 일반적인 대답은“자동 회귀 테스트입니다. 괜찮습니다. 단위 테스트를 알고 있습니까? 그럴 시간이 없습니다! 우리는 시장에 빨리 진출해야합니다!”

내 경험 대부분에서 두 부분 :

• 시각
• 현재 상황에 가장 적합한 방법에 대해 충분한 사람들이 동의하도록 유도

"모범 사례"는 많은 실제 상황에서 매우 주관적입니다. 팀의 절반이 많은 SOLID & TDD를 수행하는 동안 다른 절반이 60 시간 동안 작동하여 실행 시간을 초 단위로 줄이고 여기에서 너무 늦었 던 지점을 지나쳐 필요한 수단을 통해 다음 릴리스에서 시간이 지남에 따라 성능이 저하되는 것을 재 설계하십시오.

팀 전체에 대해 너무 많은 의견 차이가 발생하지 않더라도 준수하기로 결정한 정책에 대한 공식적인 합의, 문서 및 교육을 받기 위해서는 많은 노력이 필요합니다. 비즈니스 관점에서 볼 때 비생산적인 시간의 큰 블록은 신중하게 정당화해야합니다.

때로는 습관 이 끔찍한 코드를 작성하는 데 크게 기여 한다는 것을 알게 될 것입니다 .

숙련 된 프로그래머 일 수 있으며 현재 업계 모범 사례에 대해 모두 알고있을 것입니다. 지옥은, 당신도 될 수 같은 것들에 대한 전문가. 경험에 따르면 그러한 사람들은 종종 끔찍한 코드를 작성하지 않지만 오래된 습관에 빠지기 쉽고 규칙이 안전하고 편리하다고 느끼기 때문에 규칙을 어기 게 될 일을 쉽게 할 수 있다고 말합니다. 그러한 경우, 무지와 오만 그리고 당신이 생각할 수있는 다른 모든 손가락을 가리키는 형용사는 실제로 중요하지 않습니다. 그러한 프로그래머가 자신이하는 일에 특히 나쁜 것은 아니며 (더 자주 경우가 많지만) 끔찍한 혼란을 일으키고 싶을 수도 있습니다.

불행히도, 제가 생각하고 싶은 것보다 더 많이 이런 일이 일어나는 것을 직접 목격 한 것은 불행한 일입니다. 일부 재능있는 사람들은 손가락과 두뇌가 몇 달 동안 자동차에서 작동하기 때문에 헛된 쓰레기를 버렸습니다. 대부분의 경우, 소진, 슬픔 및 스트레스의 증거가 나타나는 곳입니다. 때때로 그것은 실제로 매일의 움직임을 통해 그들을 운반하는 맹목적인 습관입니다. 취약한 사람들에게 불필요하게 라벨을 붙이는 위험을 피하기 위해주의 깊게 관찰하는 법을 배웠습니다.

슬프게도 당신이 더 자주 맞지 않더라도 부정적인 결론으로 ​​뛰어 들기 쉬운 사람들을 위해 생각할 음식.

리팩토링과 관련된 제목의 프로젝트에 대한 비용을 지불하는 사람은 아무도 없습니다. 그것은 '사업'이익에 호소하는 단어가 있어야합니다. 개조, 재 활성화, 총 리메이크, 수명주기 업그레이드 등과 같은 단어가 제 작업장에서 작동합니다. 거의 모든 프로젝트의 주요 부분으로 리팩토링이 있습니다.

슬프게도, 경제 암살자 덕분에 노동은 임금이있을 때만 일어납니다. 업무가 장기적으로 비즈니스 재산을 저장하는 것만으로도 마찬가지입니다.