복사 / 붙여 넣기 / 스파게티 프로그래머를 변환하여 빛을 보는 방법?

이 질문은 영감을받은 이 하나 . 다른 질문은 현지화 된 것으로 간주되지만 근본적인 문제는 업계에서 매우 일반적인 문제라고 생각합니다. 나는 이것을 읽고 내가이 자료를 만들고 있다고 생각하는 개발자가 있다는 것을 알고 있으며, 모든 사람들이 자신의 작업에 관심을 갖고 배우고 싶어하는 방식에 대답 할 수 있지만 다른 프로그래머 SE 게시물 ( 사례 )을 보면, 나는 그것이 보편적으로 사실이 아니라는 것을 알고 있습니다.

따라서 표준 운영 절차를 복사 / 붙여 넣기하고 충분한 함수 호출과 변수 만 추가하면 모든 것을 해결할 수 있다고 믿는 팀원 (또는 대다수)이 있다고 가정 해 봅시다. 이 사람은 TDD, DRY 또는 SOLID에 대해 들어 본 적이 없으며 업무 중 바쁜 시간에 40 시간이 지나도 단 한 번의 방법론 / 실습 / 디자인 북을 읽지 않습니다.

과거에 나는 (그리고 다른 사람들이) OOD를 가르치는 방법을 물었다 . 그러나 지금 나는 그것이 올바른 질문이 아니라고 생각합니다. 진짜 질문은 어떻게 그런 사람 / 팀에게 접근하여 더 나은 일을하는 방법에 대해 궁금해 하는가입니다. 그들이 배우도록 어떻게 고무 시키나요? 그것이 없으면, 책상으로 돌아가서 항상 해왔 던 일을 완전히 기뻐한다면 모든 가르침, 회의, 강의, 토론은 쓸모없는 것 같습니다.

나는 그런 사람들과 함께 일합니다. 그들은 실제로 매우 밝은 개인이지만, "나는 코딩을 마쳤습니다. DXM을 행복하게 만들기 위해 리팩토링하고 여러 클래스로 나누면됩니다." 더 깨끗하고 읽기 쉽고 유지 관리가 가능한 코드를 리팩터링하지 않지만, 그렇지 않으면 꾸짖을 수밖에 없습니다. 나는 그들이 학습 할 수 있다는 것을 알고 있습니다. 동기 부여가 전반적으로 부족한 것 같습니다.

작업을 제공 할 때 일반적으로 버그가 줄어들고 내가 소유 한 작업이 클래스의 5000 줄 괴물이되지는 않았습니다. 다른 사람들은 "당신의 코드는 우리의 것보다 훨씬 깨끗하고 읽을 수 있습니다"와 같은 의견을 제시 할 것입니다. 그러나 동시에 그들이하는 일에 관계없이 40 시간 동안 돈을받는다고 생각하기 때문에 QA에서 3 일 동안 보내지 말아야 할 버그를 찾는 데 실제로 신경 쓰지 않습니다. 첫 번째 장소. 또는 하나의 클래스를 수정하는 데 일주일이 걸리므로 너무 많은 의존성이 있기 때문입니다. 그러나 "아마도 그 클래스는 다르게 쓰여졌어야했을 것"이라고 생각되지 않습니다.

이 상황에서 무엇을 할 수 있습니까? 성공한 사람이 있습니까? 아니면 그러한 사고 방식을 프로젝트의 중요하지 않은 부분으로 격리하고 손상을 최소화하는 것이 가장 좋습니까?

참고 : "동기 부족"이라고 말할 때. 나는 그들이 돌보는 것을 멈추기 때문에 일하거나 좋은 일을하는 동기가 부족하다고 생각하지 않습니다. 우리 팀의 대부분은 실제로 반대입니다. 그들은 분명히 제품에 관심이 있습니다. 우리는 밤과 주말에 일할 사람들이 있습니다. 내가 겪고 자하는 부분은 습관과 기술이 향상되어 실제로 많은 일을 할 필요가 없다는 것입니다. "40 시간"이이 포스트 사운드를 약간 부정적으로 만들었다 고 생각합니다.

"나는 그들이 학습 할 수 있다는 것을 알고 있습니다. 동기 부여가 일반적으로 부족한 것 같습니다."

그들의 일에 열정을 가진 사람들이 있습니다. 그리고 때때로 유능한 사람들이 돈을 위해 일하는 사람들도 있습니다 . 그들은 그들의 것을 알고 있지만 그들의 일을 즐기지 않습니다. 신속하고 못생긴 해킹이 작업을 수행 할 수있을 때 코드를 읽을 수있게하거나 흥미로운 문제를 해결하기 위해 추가 리팩토링을 수행하는 데 추가 시간을 소비하지 않습니다.

이 현상은 모든 직업에 존재합니다. 그것은 단지 어떤 일이 극도로 흥미롭지 않다는 것입니다 (당신은 자신의 일을 좋아하고 그가 어렸을 때 이미 꿈꿔 왔던 회계사를 보았습니까?). 그러나 프로그래밍에는 실제로하는 일을 정말로 좋아하는 많은 사람들이 있습니다 (그렇지 않으면 Programmers.SE는 비어 있습니다.) 이는 다른 열정적 인 개발자와 매일 대화하는 열정적 인 개발자로서 돈을 위해 프로그래밍하는 사람을보고 놀랄 확률이 더 높다는 것을 의미합니다.

우리는 무엇을 할 수 있습니까? 너무 많이하지. 모든 경우에, 당신에게가 아니라 인적 자원이 진정한 동기를 가진 사람들을 선택하는 것 ¹. 그리고 그렇지 않은 사람들을 해고하십시오.

동료에게 동기를 부여 할 수는 있지만 매우 어렵습니다. 당신이 그들에게 읽을 책을 주면, 그들은 몇 주 후에 열지 않은 채로 돌려 보낼 것입니다. 당신이 그들에게 조언을한다면, 그들은 걱정하지 않기 때문에 듣지 않을 것입니다 ².

당신은 할 수 있습니다 :

• 상사에게 회사에 여러 가지 엄격한 규칙 ( 스타일 지침 등) 을 설정하도록 설득하십시오 . 이는 직원들이 더 나은 업무를 수행하도록 동기를 부여하지는 않지만 최소한 요구 사항에 맞지 않는 소스 코드를 커밋 할 수는 없습니다. .

• 요구 사항, 특히 비 기능적 요구 사항에 대해 작업하십시오 . 특정 프로젝트에 5 000 줄 미만 의 IL 코드 가 포함되어야한다는 요구 사항은 어떻습니까 (아니요, 의미없는 LOC 에 대해서는 이야기하고 있지 않습니다 ) ³? 순환 복잡성 또는 클래스 커플 링 에서 특정 결과를 얻어야하는 것은 어떻습니까?

• 코드 검토 를 위해 회사에서 보내는 시간을 늘리십시오 . 검토 대상 지정 : 점검 목록이있는 경우 리팩토링, 가독성, 깨끗하고 유용한 주석 등과 관련된 사항을 추가하십시오. 점검 목록이없는 경우 반드시 확인해야합니다.

• [more] 페어 프로그래밍을 사용하십시오 . 코드 품질을 향상시키고 동기 부여가 적은 동료에게 동기를 부여 할 수 있습니다.

• Fog Creek에서 사용되는 것과 유사한 보상 시스템을 사용하십시오 .

^{¹ 그것이 인터뷰에 관한 것입니다 : 당신을 고용하기 전에, 인적 자원은 당신의 기술 수준뿐만 아니라 동기 부여의 자산이되어야합니다 . 안타깝게도 일부 회사는 인터뷰의 두 번째 부분을 잊어 버리고 프로그래밍을 너무 좋아하지 않는 사람들을 고용합니다. 다행스럽게도 대부분의 경우 해당 회사 의 업무 는 결코 즐겁지 않으며 Joel 테스트는 거의 2를 초과하지 않습니다.}

^{² 그들은 정말 그들이 더 적은 돈을 얻을 경우에도 상관하지 않습니다. 나는 그의 일이 자신의 고객을 위해 웹 사이트를 개발 하는 것이라고 믿는 내 고객 중 한 명 (저는 프리랜서)에 가깝습니다 . 그는 또한 디자이너가 있습니다. 생산성을 2 이상 향상시킬 수있는 방법에 대해 여러 번 말했습니다. 그들이 유능한 사람을 고용 한 경우 수익이 3 이상 증가 할 것입니다. 그러나 돈이 충분하고 생산적인 사람과 비교할 때 품질이나 무지한 고객에게 얼마나 많은 비용을 신경 쓰지 않습니다.}

^{³ 의미하는 바는 Visual Studio의 Code Metrics에서 실제로 볼 수있는 메트릭 인 IL 코드의 줄 수입니다 . 실제 LOC는 중요하지 않습니다 그리고 당신은 그것을 측정 할 필요가 없습니다; 그것은 가장 어리석은 지표 중 하나입니다. IL 코드 줄을 적용한다는 것은 개발자가 읽을 수없는 단일 줄에서 10 줄의 코드를 축소 할뿐만 아니라 실제로 코드를 리팩토링해야한다는 것을 의미합니다.}

"나는 코딩을 마쳤습니다. DXM을 행복하게 만들기 위해 리팩토링하고 여러 클래스로 분할하면됩니다."

그 생각의 선은 모든 팀에 암이 있고 즉시 돌보지 않으면 팀 전체의 동기를 죽일 것입니다. 물론 선임 및 / 또는 공로에 의해 당신은 기술적 인 권한을 가지고 팀에 영향을 미치고 좋은 관행을 이끌어 낼 힘을 준다는 사실을 언급하고 있습니다.

이 모든 것이 좋고 훌륭하지만, 팀이 이러한 프로세스에서 명확하게 팔렸다면 프로세스에 대한 존중 부족과 존중의 부족을 분명히 나타내는 이와 같은 진술에서 당신을 따로 언급하지 않을 것입니다. 그들은 여전히 ​​이러한 모범 사례를 팀이 자신의 장점을 방어 할 팀이 소유 한 프로세스 가 아니라 사용자에 의해 방해 되는 것으로 간주합니다 .

이전 의견에서 다른 팀원들은 실제로 이러한 관행과 표준을 잘 준수하고 올바르게 적용한다고 언급했습니다. 먼저 지원을 강화하는 데 집중하고, 효과가있는 것, 효과가없는 것, 좋아하는 것, 변화하고 싶은 것을 물어보십시오. 당신이 그렇게하고 그들의 의견을 진지하게 받아들이면, 그들은 상급자로부터 그들에게 전달 된 절차 대신에 공동체 결정 인 것처럼 표준에 대해 매우 다르게 느낄 것입니다.

소프트웨어 개발 프로세스 또는 소프트웨어 품질을 개선 한 방법을 팀에 지적하여 모범 사례 및 표준에 대한 지원을 강화합니다.

토론 할 문제에 대해 투표를하고 결과를 문서화하십시오. 이상적으로는 모든 결정이 정당성을 위해 만장일치가되어야하지만, 어려운 장애물을 다루는 경우 불가능할 수 있으며 모든 문제를 막을 수 있습니다. 이 상황에서 과반수 표를 사용하십시오. 대다수가 제안 된 표준 및 관행에 위배되는 경우 이미 방을 잃어 버렸으므로 해당 시점에서 포기하십시오.

그들은 그 표준과 절차를 소유 할 것이며 여러분이 필요하지 않도록 시행 할 것입니다. 기술 책임자로서 당신은 칙령과 선언을 선언 할 필요가 없습니다. 이는 리더가 되기에는 좋지 않은 방법입니다.

팀이 절차를 소유 한 것처럼 느껴지면 특정 절차 및 모범 사례에 레이블을 붙이기 시작한 팀 구성원은 불법으로 생각할 것입니다. 당신의 팀은 다른 사람들의 태도를 바로 잡도록 도울 것입니다.

좋은 질문! 사람들이 자신의 기술을 향상시키고 싶지 않은 이유에 따라 대답이 달라집니다. 가능한 답변은 다음과 같습니다.

• 그들은 새로운 것을 배우기에는 너무 바쁘거나 새로운 시험 방법 (예 : 모든 테스트 작성)이 더 오래 걸리고 시간이 없다고 생각합니다. 그렇다면 분명한 대답은 더 많은 시간을 할애하는 것입니다. 항상 다르게 행동했을 때 무언가를 배우거나 TDD와 같은 것을 시도 하면 처음 몇 시간이 더 걸릴 것 입니다. 프로그래머가 그 시간이 없다면 시도하지 않았다고 비난 할 수 없습니다.
• 그들은 자신의 기술에 대해 다른 인식을 가지고 있습니다. 즉, 그들은 고품질의 코드를 생성하는 매우 훌륭한 프로그래머라고 생각합니다. 신념이 산만해질 수 있기 때문에 심리적 지형이 어렵다. 어쩌면 어떤 종류의 비공식 경쟁이 도움이 될 수 있습니다 (누가 가장 적은 결함 / 기능을 생성합니까? 가장 짧은 코드? 코드 검토에서 가장 적은 WTF / 분?).
• 실제 동기 문제가있을 수 있습니다 (즉, 마감 시간까지 "시간을 내고 홀로 남겨두고 싶어"). 운 좋게도 이것은 너무 일반적이거나 프로그래밍과 관련이 없습니다. 정말 답이 없기 때문입니다.
• 그들은 초보자이며 더 잘 모른다. 이 경우 교육, 코드 검토 또는 팀 구성원이 매달 새로운 기술 서적을 논의해야하는 "도서 클럽"이 도움이 될 수 있습니다.
• 그들은 이전에 은색 총알을 보았고 (심히 실망했습니다) 그들은 판매하려고하는 것이 이론적으로 좋으며 실제로 거의 사용되지 않는 또 다른 새로운 유행어라고 생각합니다. 이 경우 코드 검토 및 페어 프로그래밍 세션에서 장점을 보여주는 것이 효과적 일 수 있습니다. 그렇게 할 때 완전히 아는 것이되지 마십시오.

가장 좋은 해결책은 근본적인 문제에 달려 있습니다. 예를 들어, 공식적인 코딩 지침, 메트릭 및 리뷰는 초보자에게는 효과적이지만 "자신의 기술에 대한 잘못된 인식"을 가진 사람들은 자신을 상대로 어려움을 겪거나 메트릭을 재생할 수 있습니다. 그들은 그들의 일을 완수하는 데 비생산적인 관료적 장애물로 작용한다.

진짜 질문은 어떻게 그런 사람 / 팀에게 접근하여 더 나은 일을하는 방법에 대해 궁금해 하는가입니다. 그들이 배우도록 어떻게 고무 시키나요? 그것이 없으면, 책상으로 돌아가서 항상 해왔 던 일을 완전히 기뻐한다면 모든 가르침, 회의, 강의, 토론은 쓸모없는 것 같습니다.

그게 다야! 이것은 실제 질문입니다.

약간의 배후를주기 위해, 우리는 단순히 많은 공식적인 훈련 을 할 시간이 없지만 때로는 그렇게해도 여전히 빛이 보이지 않습니다. 나는 또한 공식적인 훈련이 과정 자체가되는 회사의 일부 였지만 나는 종종 그들이 어떻게 생각하는지 가르치는 증인입니다 .

제가 그들에게 제기하는 질문은 그들을 가르치는 방법이 아니라 어떻게 배우게 하는가입니다. 그 차이는 미묘하지만 모든 차이를 만들어 낼 것입니다.

내가 옳은지 모르겠습니다. 그러나 종종 나는 영화 의 매트릭스 대화 영화를 믿습니다 - "그것은 우리를 이끄는 질문입니다!" 가장 중요한 것은 그들이 생각하게하고 이유를 물어 보는 것입니다! 그리고 물론, 대학 과정에서 좋은 점수를 받았기 때문에 일부 디자인 패턴에 대해 이미 모든 것을 알고 있다고 생각하는 대부분의 사람들 은 가장 어렵습니다.

어떻게 그런 질문을합니까? 나의 일반적인 접근 방식은 "수영하는 법을 배우고 싶다면 연못에 던져라" 입니다. 나는 사람들이 동의하지 않을 수 있음에 동의합니다. 나는 그들에 동의하지 않기로 기꺼이 동의 할 것입니다. 당신이 연못에 던져 때-그들은 실제로 자동으로 수영을 배우지 않습니다; 그러나 그것은 생존 본능을 발산하여 생각하게합니다. 일단 발생하면 자연스럽게 HOW와 WHY를 생각하게됩니다.

내가 사람들에게주는 실제적인 예는 그들이 그들에게 하나의 목표를 세우고 그들 자신의 전투와 싸울 수있게하려는 것보다 상당히 복잡한 프로젝트에 넣는 것입니다. 코드를 풀기 시작하고 코드를 추적하기가 어려워지기 시작하면 좋은 질문을하기 시작합니다.

이것은 약간 극단 주의자라고 들릴 수 있으며, 이는 자원 낭비를 유발할 수 있습니다 . 그리고 나는 이것을하지 말라고 충고 할 다른 많은 사람들이 있다고 확신합니다. 그러나 이것은 나를 위해 일했습니다!

어떤 유료 패키지 및 HR 태그를 지정하더라도 기본 동기 부여 문제는 해결되지 않습니다 . 유일한 길은 그들이 도전 받는다는 것입니다. 이 기본 인간 정신을 촉발하면 다른 모든 것이 작동합니다. 당신이 할 수 없다면 느슨한 느슨한 게임입니다.

추신 : 우연히 나는 여기에 답변을 게시했습니다 https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034- 그리고 나는 모든 bashing을 얻었습니다. 주로 대부분의 사람들은 어떻게 든 비즈니스가 자원을 낭비 할 여유가 없다고 생각합니다! 나는이 대답이 여기에서 비슷한 치료를받을 수 있다고 확신합니다. 그러나 진실은 사람들이 일을하도록하고 좋은 일을하도록 믿게하는 것이 코스의 강의 계획서를 작성하는 방법에 대한 인간 심리학의 주제입니다.

어쨌든, 여기서 설명하는 임무는 큰 변화를하려는 내적 열정을 불 태우는 것입니다. 그리고 시스템이 클수록 더 어려워집니다. 난 여전히 싫은 직업 정신으로 지내고 현 상태에 도전하는 젊은 동료들과 함께 시작하십시오 .

지적했듯이 동기 부여. 그들이 모르고 그들을 돌보지 않는 실수를하지 마십시오. 그들은 무엇을해야하는지 분명히 알고 있습니다. 그들은 단지 상관하지 않습니다 . 그렇다면 실제 질문은 ... 경영진이 동기 부여를하지 못하게하는 원인은 무엇입니까? 팀의 최신 멤버입니까? 아마도 그들은 이전에이 모든 과정을 겪어 왔으며, 이는 경영진의 문제로만 이어졌습니다. 따라서 그들은 더 많은 일을하는 것이 고용주에 의해 응답 될 것이라고 생각하지 않기 때문에 직업을 유지하는 데 필요한 가장 적은 양의 일을 계속합니다.

그 팀이 다음 개선 (개인 및 코드의) 팀의 핵심 속성, 문제는 그 지원됩니다되어 있는지 확인하는 작업을 할 수있는 경우 - 관리 및 리더십 문제가 있음을 날 것으로 보인다 귀하의 관리 - 때문에 시간이 걸리는 일을하고 싶을 것입니다 (새로운 기술 부채를 줄여야하고 기존 기술 부채를 상환 할 것이므로 순이익을 얻게됩니다).

따라서 팀이 개선하기를 원한다고 주장하면 이것이 좋은 것입니다 (팀 전체가 코드의 품질을 향상시키기 위해 노력한다는 것)에 동의 한 다음 프로그램을 시작하여 일이 너무 쉽게 들립니다 ... 나는 그것을 인식하지 못한다!

나는 이것에 교육과 작업 관행의 두 부분이 있다고 생각합니다.

• 교육 일주일에 한 번 점심을 시작할 수 있습니다. 모두가 함께 식사를하고 Q & A를 통해 20 ~ 30 분 동안 프레젠테이션을합니다. 원하는 기본 사항부터 시작합니다. SOLID는 처음 2 ~ 4 주를 점유 할 수 있습니다. 시간이 지남에 따라 팀이 교대로 발언 할 수있게되며 누가 서로 간의 대화를 결정할지 결정할 수 있습니다. 스피커가 작업 내에서 준비 시간을 허용합니다. 지역 사용자 그룹의 참여를 장려하는 것 이상 (가능한 경우 적어도 부분적으로 사회적 일을함으로써)
• 실무 관행 ... 글쎄 지금은 무엇을하고 어떤 툴을 가지고 있는지에 달려 있지만, 코딩 표준에 동의하고 피어 코드 검토 (단단한가)를 소개하고 단위 테스트 (먼저 테스트 할 필요는 없음)를 원할 수 있습니다 지속적인 통합 서버를 실행하고 더 많은 자동 테스트 (단위 테스트 외에도)를 살펴 봅니다. 그러나 이것들은 실질적으로 동의 / 계약 (빌드 / CI 서버가 아님)과 함께 도입되어야하며 팀으로서 품질을 향상시켜야합니다. 항상 개선 할 수있는 것들이 있습니다 (카이젠)

또한 Kanban (변경 / 개선의 동인으로 볼 수 있음)을 살펴볼 가치가 있습니다.

마지막 한 가지 생각-저는 직업 프로그래머입니다. 팀이 동일 하지만 일주일에 40 시간 이상 일하는 것이 실제로 좋은 것은 아니므로 목표는 작업을 수행하는 팀을 만드는 것입니다 정상 근무 주 내에서 효과적이고 잘 작동하며이 문제와 관련하여 실무 개선을위한 논거는 더 가능성이 높다는 것 입니다.결정된; 빌드 서버가 있으면 솔루션을 깔끔하게 빌드 할 수 있다는 확신을 갖게됩니다. 빌드시 배포 패키지가 생성되면 배포가 크게 단순화됩니다. SOLID 코드는 정의상보다 쉽게 ​​수정할 수 있습니다. 그리고 전반적으로 기술 부채가 적을수록 갚아야 할 금액이 줄어 듭니다.

~ 30 년 전 우연히 프로그래밍에 빠졌습니다. 다른 사람들의 코드를 유지 / 지원하도록 할당되어 기본 소프트웨어 엔지니어링 원칙을 배우도록 동기를 부여 받았습니다. 이 과제에서 코드 리더가 코드를 경험하는 방법, 즉 코드 리더와 공감하는 방법을 배웠습니다. 나는 잘못 작성된 코드의 고통을 다른 사람들에게 전하고 싶지 않았습니다!

다른 사람들의 코드를 유지 / 지원하기 위해 새로운 프로그래머를 할당하는 이러한 관행은 마법의 총알이 아니며 견고한 코드를 생성하는 방법을 배우지 않는 동기를 부여하는 것 같습니다.