저는 4 명으로 구성된 소규모 아웃소싱 회사에서 iOS 개발자로 일하고 있습니다. 우리는 나와 다른 두 개발자가 회사에 합류하기 몇 년 전에 시작된 프로젝트를 진행하고 있습니다. 그 전에는 대부분 한 사람이 프로젝트를 수행했습니다.

프로젝트 작업을 시작했을 때 완전히 엉망이었습니다. 많은 코드 반복이있었습니다. 나는 약간의 변형으로 20 개의 다른 파일에 동일한 500 개의 코드를 처리하는 것을 보았습니다. 또한 모든 UI 작성 코드는 로직과 함께 뷰 컨트롤러에서 혼합되었습니다.

나는 여기저기서 리팩토링하고, 불필요한 코드 조각을 제거하고, 프로젝트의 파일 구조를 개선하는 등 최선을 다했습니다. 이전 개발자가 실제로 이러한 모든 것을 신경 쓰지 않았거나 경험이없는 것처럼 느껴졌습니다. 몇 달 동안 꽤 큰 기능을 위해 혼자 일했을 때가있었습니다. 이 기능의 특성으로 인해 전체 앱에서 많은 코드를 터치해야했기 때문에 개선을 시도했습니다.

다른 개발자가 프로젝트에 참여했을 때 다른 코딩 스타일 (때로는 완전히 다른 스타일)을 사용하고 속성 접근 자와 같은 최신 언어 기능을 사용하지 않는 경우가 많았습니다 (Objective-C에서 비교적 새로운 기능 임). 때로는 프레임 워크의 유사한 기능을 사용하는 대신 자체 자전거를 만들거나 다른 프로그래밍 언어 또는 코드 기반에서 배운 패턴에서 개념을 전달하기도합니다. 종종 영어가 잘못되어 메소드 나 변수의 이름을 제대로 지정할 수없는 경우가 있습니다 (Objective-C는 이름이 긴 언어입니다).

때로는 IDE가 아닌 경우 들여 쓰기 나 서식이없는 모든 코드를 작성한다고 생각합니다.

기본적으로, 나는 그들이 작성한 코드가 싫어. 형식이 잘못 구성되고 때로는 프로젝트의 나머지 부분과 근본적으로 다릅니다. 나는 그들이 내 예술 작품에 스파게티를 추가 할 때 매우 화가 나고 직장에서의 기분과 생산성에 영향을 미칩니다.

그들은 배우거나 신경 쓰지 않아도되는 것처럼 점점 더 느끼고 있습니다. 그들은 단지 필요한 것을하고 집으로 돌아갑니다. 나는 기회가 생겼을 때 그들에게 몇 가지 팁을 주려고 노력했다 (예 : PR에 의견을 주거나 GitHub에 대한 커밋). 한 번은 기존 코드 대부분의 코딩 스타일과 형식을 따르도록 친절하게 요청했습니다 (슬프게도 공식 코딩 스타일 문서는 없습니다). 그러나 그것은 작동하지 않았습니다 ...

'나쁜 회사 문화', '불편한 졸업생'등에 중점을 두지 않고이 상황을 어떻게 해결하고 실제로 상황을 개선하기 시작할 수 있습니까?

전파하는 것을 가르치고 실천하십시오.

이 물건이 중요하다는 것을 알고 있습니다. 제대로 수행되지 않으면 단점을 알 수 있습니다.

이제 도전은 다른 사람들을 설득하는 것입니다. 이것은 단일 대화, 회의, 복도 대화, 팁 또는 풀 요청 내에서는 수행되지 않습니다.

이것은 필요합니다 :

• 경영진은 이러한 항목이 중요하다는 사실을 대중에게 인정
• 사람들이 모여서 스타일에 동의하고 컴퓨터가 폴리싱을 수행 할 수 있도록 린터
• 완전히 구매하고 다른 사람을 기꺼이 가르치려는 개발자
• 이러한 접근법을 가르치기위한 회의, 데모, 점심 식사 및 학습 등
• 리뷰 중에 언급 한 품질 항목을 측정 한 사용자
• 문서화 및 게시 된 표준
• 리뷰어가 많은 풀 요청
• 코드 품질이 높아질 때까지 풀 요청이 병합되지 않음
• 빈번한 코드 페어링
• 복잡한 PR에 대한 그룹 코드 검토

한마디로 그것은 필요합니다

지도

좋은 소식은 이러한 모든 활동이 일반적으로 모범 사례로 인식되므로이를 홍보하거나 경영진으로부터 구매할 때 성공할 수있는 기회가 있어야하며 올바른 일을 옹호 할 수 있어야합니다. 그러나 경영진은 아직 사지 않을 수도 있지만 이는 또 다른 주제와 질문입니다.

나는 과거에 SoftwareEngineering.SE에 대해이 주제에 대해 많은 글을 썼으며 비슷한 상황에 처해있었습니다. 따라서 몇 가지 힌트를 드리고 질문을 읽을 때 언급 한 몇 가지 문제를 강조하겠습니다.

그러나 먼저 중요한 측면, 즉 회사에서의 귀하의 역할에 대해 이야기하겠습니다.

너의 역할

상사로부터 명시 적으로 명령을 내려서 사물을 향상시키고 다른 개발자가 귀하의 명령 을 들어야하는 계층 구조의 장소도 있습니다 . 또는 당신은 당신의 옵션은 ... 음 ...되고, 같은 역할과 동일한 권한을 가진 동료들 사이에서있을 수 있습니다 생각 .

두 경우 모두 중요한 것은 계층 구조의 위치가 적으며 그 이상입니다.

• 다른 개발자가 당신을 생각하는 것. 그들이 당신을 바보 같은 것들을 요구하는 성가신 사람으로 취급한다면, 당신은 멀지 않을 것입니다. 기술 리더와 프로젝트 관리자가 팀에 전혀 영향을 미치지 않는 경우를 많이 보았습니다. 팀은 이러한 "리더"가 의사 결정을 내리는 데 필요한 기술적 배경이 없다는 것을 알았 기 때문입니다. 다른 한편으로, 나는 그 개발자들이 숙련되고 경험이 있다는 것을 알았 기 때문에 실제로 동료의 말을 듣는 여러 개발자를 보았습니다.

• 팀은 얼마나 견고하고 동기는 무엇입니까? 모든 개발자가 월간 KLOC를 지불하는 회사를 상상해보십시오. 스타일에 대해 말한 내용이 동료에게 중요합니까? 적은 돈을 받고 싶어하는 사람들은 드물기 때문에 아마 아닐 것입니다. 일반적으로 이것이 팀이 아니라 동일한 프로젝트에서 일하는 사람 그룹 인 경우 아무것도 개선 할 수 없습니다.

이에 따라 변경을 시도 할 가치가 있는지 여부를 결정할 수 있습니다. 목소리가없고 팀 응집력이 없다면 다른 직업을 찾으십시오. 재능 있고 존경받는 개발자로 알려져 있고 강한 팀 느낌이 있다면 상사 나 다른 팀의 적대감에 직면하더라도 비교적 쉬운 일을 개선 할 수 있습니다.

모든 경우에 팀에 압력을 가하지 않아야합니다. 작업 과 함께 하지, 그들 에 대해 그들. 그들에게 명령을 내리지 말고 목표를 향해 인도하십시오.

이제 힌트입니다.

스타일

한 번은 기존 코드 대부분의 코딩 스타일과 형식을 따르도록 친절하게 요청했습니다 (슬프게도 공식 코딩 스타일 문서는 없습니다). 그러나 그것은 작동하지 않았습니다 ...

물론 이것이 수행되어야하는 방법이 아니기 때문에 그렇지 않았습니다.

• 스타일은 지루하다 .

• 다음 스타일은 지루 합니다.

• 코딩 스타일 문서를 작성하는 것은 지루합니다. ( 어려워서 10 년 이상 언어를 다루지 않는 한 시도조차하지 마십시오).

• 독서 스타일 문서는 지루하다 .

• 스타일 실수에 대한 코드를 검토하는 것은 지루 합니다.

• 특히 내 스타일이 다른 스타일보다 객관적인 이점이없는 경우, 내 스타일이 당신보다 낫다는 것은 흥미 롭습니다 . 진지하게 모든 건전한 사람은 if (x)글 을 쓰는 올바른 방법이 내가 쓴 방식 if(x)인지 아닌지 알고 있습니다 if ( x )!

따라서:

• 스타일 검토를하지 마십시오. 스타일 체커의 일입니다. 이 귀여운 응용 프로그램은 두뇌에 비해 몇 가지 이점이 있습니다. 몇 시간 또는 며칠이 아닌 밀리 초 단위로 전체 프로젝트를 확인하며 실수를하지 않으며 스타일 오류를 놓치지 않습니다.

• 자신 만의 스타일 표준을 작성하지 마십시오. 어쨌든 잘못하면 동료가 잘못된 선택을했다는 사실을 알게됩니다.

• 개발자가 2 000 스타일 오류를 수정하도록 강요하지 마십시오.

• 커밋시 스타일을 자동으로 적용합니다. 스타일 실수가있는 코드는 버전 관리에 적합하지 않습니다.

• 프로젝트 초기부터 수행하십시오. 기존 프로젝트에서 스타일 컨트롤을 설정하는 것은 불가능합니다.

이에 대한 자세한 내용 은 SE.SE에 대한이 다른 답변 의 첫 번째 섹션을 읽으십시오 .

또한:

• 너무 엄격하지 마십시오. 예를 들어, jslint호환 코드를 작성하는 것은 매우 성가신 일이므로 절대적으로 필요할 때 (또는 팀원 모두가 행복하게 사용하는 경우) 독점적으로 수행해야합니다. 정적 검사 도구도 마찬가지입니다. 예를 들어, 최대 수준의 .NET의 코드 분석은 매우 억압적이고 우울할 수 있지만 이점은 거의 없습니다. 반면에 적당한 수준으로 설정된 동일한 도구는 매우 유용합니다.

코드 리뷰

코드 검토 중에 스타일에 신경 쓸 필요가 없으므로 소스 코드 향상 (고정)과 같은보다 흥미로운 것들에 초점을 맞출 수 있습니다.

사람마다 코드 검토에 다르게 반응합니다. 일부는 기회라고 생각합니다. 다른 사람들은 그것을 싫어합니다. 어떤 사람들은 자신이 옳다고해도 자신이 말하는 모든 것을 듣고, 메모하고, 토론하지 않습니다. 다른 사람들은 모든 시점에서 논쟁을 시도합니다. 그녀의 성격에 따라 모든 개발자를 처리하는 방법을 찾는 것은 당신에게 달려 있습니다. 일반적으로 다음에 도움이됩니다.

• 특히 개발자가 주니어이고 정말 나쁜 코드를 작성할 때 개인 코드 검토를 수행하십시오.

• 개인적인 것이 없다는 것을 보여주십시오 : 당신은 그 사람의 기술이 아닌 코드를 검토하고 있습니다.

• 코드 검토의 실제 목표를 보여줍니다. 목표는 개발자가 얼마나 나쁜지를 보여주는 것이 아닙니다. 목표는 개선의 기회를 제공하는 것입니다.

• 절대 논쟁하지 마십시오. 당신은 설득하기 위해 여기에 있지만 당신의 전문 지식을 제공하지 않습니다.

• 리뷰어가 리뷰에서 무언가를 배울 수있는 유일한 사람이라고 가정하지 마십시오. 코드를 읽고 이해하지 못하는 부분에 대한 설명을 요청하여 배우기도합니다.

코드 검토가 완료되면 사람이 실제로 코드를 개선하는지 확인하십시오. 개발자가 실제 회의가 끝나면 코드 검토가 끝났다고 생각한 경우가 몇 가지있었습니다. 새로운 코드에만 적용한 내용을 적용하려고 시도하면서 새 기능으로 돌아갑니다. 코드 검토를위한 적절한 추적 도구를 사용하면 도움이됩니다.

회사에서 귀하의 특정 역할 및 다른 분야에 비해 귀하의 전문 지식과는 별도로 코드도 검토해야합니다. 다른 사람의 코드를 검토하는 유일한 사람이되어서는 안됩니다.

최근 기술 리더로 일한 프로젝트에서 동료를 비롯해 내 코드를 포함하여 서로의 코드를 검토하는 것이 그들의 역할이라고 설명하기가 어려웠습니다. 기술 리더의 코드를 검토하려는 인턴에 대한 두려움은 코드의 첫 번째 문제를 발견하자마자 사라집니다. 우리 중 누가 완벽한 코드를 작성합니까?

훈련

코드 검토는 프로그래밍 및 소프트웨어 디자인의 일부 측면을 가르치고 배울 수있는 좋은 기회이지만 다른 프로그램에는 교육이 필요합니다.

동료를 훈련시킬 수 있다면 그렇게하십시오. 경영진이 교육 아이디어에 적대적이라면 비공식적으로하십시오. 나는 그러한 훈련 세션을 비공식 회의의 형태로 또는 때로는 간단한 토론으로, 때로는 경영진에 의해 중단되어 나중에 추구했습니다.

직접 교육을 제외하고 McConnel의 Code Complete 와 같은 책을 충분히 알고 동료들에게 그 책에 대해 이야기하십시오. 오픈 소스 프로젝트의 소스 코드를 읽고 고품질 코드의 특정 예를 제시하도록 제안하십시오. 그리고 분명히 고품질 코드를 직접 작성하십시오.

사람이 아닌 상황에 집중

'나쁜 회사 문화', '무익한 졸업생'등에 초점을 맞추지 않고이 상황을 어떻게 해결할 수 있습니까?

그 졸업생들은 경험을 쌓고, 물건을 배우고, 더 능숙 해지는 목표를 가지고 있습니다. 해마다 크 래피 코드를 작성하고 프로그래밍에 대해 전혀 모른다면 아마도 팀이나 회사에서 이러한 기회를주지 않았기 때문일 것입니다.

당신의 팀이 경험이 부족한 졸업생에 초점을 맞추고 있다면, 이것은 도움이되지 않습니다. 대신, 그들과 함께 할 수있는 일에 집중하십시오. 코드 검토 및 교육은 상황을 개선하는 기술 중 두 가지입니다.

나쁜 회사 문화는 다른 짐승입니다. 때로는 변경 될 수 있습니다. 때로는 불가능합니다. 모든 경우에, 귀하 는 이 회사의 일부이므로 회사 문화의 일부임을 기억하십시오. 변경할 수없고 조만간 나쁘게 발견되면 떠나야합니다.

측정 항목을 올바르게 설정

지금 코드를 정확히 어떻게 측정합니까? 개발자 당 하루 커밋 수를 측정합니까? 아니면 프로그래머 당 월 KLOC? 아니면 코드 범위일까요? 아니면 발견되고 수정 된 버그의 수? 아니면 회귀 테스트에 의해 잡힐 수있는 잠재적 버그의 수는? 또는 Continuous Deployment 서버에서 수행 한 되돌리기 횟수는?

팀원들이 측정 한 요소에 따라 작업을 조정하고 있기 때문에 측정하는 사항. 예를 들어, 몇 년 전에 일해야했던 한 회사에서 측정 된 유일한 것은 사무실에서 보낸 시간이었습니다. 말할 필요도없이 더 나은 코드를 제공하거나 더 똑똑하게 일하거나 전혀 일하지 않는 것이 좋습니다.

긍정적이고 부정적인 강화를 파악하고 시간이 지남에 따라 측정 된 요소를 조정하는 것은 본질적으로 팀원에게있어 레버리지입니다. 올바르게 수행하면 간단한 계층 구조로는 달성 할 수없는 결과를 얻을 수 있습니다.

당신을 괴롭히는 것들을 측정 가능하게 만듭니다. 그것들을 측정하고 결과를 공개하십시오. 그런 다음 다른 팀원과 협력하여 결과를 개선하십시오.

예를 들어 팀 구성원이 클래스, 클래스 구성원 및 변수 이름에서 너무 많은 철자 실수를한다고 가정 해 봅시다. 이것은 성가신 일입니다. 어떻게 측정 할 수 있습니까? 파서를 사용하면 코드에서 모든 단어를 추출하고 맞춤법 검사기를 사용하여 실수와 오타가 포함 된 단어의 비율 (예 : 16.7 %)을 결정할 수 있습니다.

다음 단계는 목표 비율에 대해 팀과 동의하는 것입니다. 다음 스프린트의 경우 15 %, 다음 스프린트의 경우 10 %, 6 주 동안 5 %, 2 개월 동안 0 % 일 수 있습니다. 이러한 메트릭은 모든 커밋마다 자동으로 다시 계산되어 사무실의 큰 화면에 표시됩니다.

• 목표 비율을 달성하지 못하면 팀에서 철자 실수를 수정하는 데 더 많은 시간을 할애 할 수 있습니다. 또는 팀이 개발자 당 비율을 계산하는 것이 더 좋다고 생각하고이 정보를 큰 화면에 표시 할 수도 있습니다. 또는 귀하의 팀이 목표가 너무 낙관적이라는 사실을 발견하고 검토해야합니다.

• 목표 비율을 달성하면 다음 단계는 실수와 오타가 시간이 지나도 증가하지 않도록하는 것입니다. 이를 위해 철자 실수를 검사하고 하나 이상의 실수가 발견되면 빌드에 실패하는 추가 작업을 빌드에 작성할 수 있습니다. 이 문제를 해결 했으므로 새로운 관련 통계를 표시하기 위해 큰 화면을 재사용 할 수 있습니다.

결론

귀하의 질문에 언급 된 모든 측면은 내 답변에 포함 된 기술을 통해 해결할 수 있다고 생각합니다.

• 다른 개발자가 프로젝트에 참여했을 때 다른 코딩 스타일을 사용하는 것으로 나타났습니다 (때로는 완전히 다른 스타일).

  커밋시 자동으로 스타일 을 적용해야했습니다 .

• 속성 접근 자와 같은 최신 언어 기능을 사용하지 않는 경우가 많습니다 (Objective-C에서 비교적 새로운 기능 임).

  언어에 대한 지식을 전달하기 위해 코드 검토 및 교육 이 모두 제공 됩니다.

• 때로는 프레임 워크의 유사한 기능을 사용하는 대신 자체 자전거를 발명하기도했습니다

  코드 검토 및 교육 은 모두 프레임 워크에 대한 지식을 전달하기위한 것입니다.

• 또는 다른 프로그래밍 언어 또는 그들이 배운 패턴에서 코드 기반으로 개념을 전달합니다.

  이것은 훌륭한 것입니다. 그들에게서 배울 수있는 기회 인 것 같습니다.

• 종종 영어가 잘못되어 메소드 나 변수의 이름을 제대로 지정할 수없는 경우가 있습니다

  코드 검토 는 적절한 이름 지정에 중점을 두어야합니다. 일부 IDE에는 맞춤법 검사기가 있습니다.

• 때로는 IDE가 아닌 경우 들여 쓰기 나 서식이없는 모든 코드를 작성한다고 생각합니다.

  물론 그렇습니다. 스타일 은 지루하며 자동화되어야합니다.

• 기본적으로, 나는 그들이 작성한 코드가 싫어.

  코드 검토 부분을 기억하십시오.“목표는 개발자가 얼마나 나쁜지를 보여주는 것이 아닙니다. 목표는 개선의 기회를 제공하는 것입니다.”

• 형식이 잘못 구성되고 때로는 프로젝트의 나머지 부분과 근본적으로 다릅니다.

  자동 스타일 검사.

• 그들이 내 예술 작품에 스파게티를 넣을 때 매우 기분이 좋아

  무엇을 기다립니다?! 예술 작품?! 뭔지 맞춰봐? 어떤 사람 (6 개월 안에 당신을 포함하여)은 당신의 코드가 예술 작품이 아닌 것을 발견 할 것입니다. 한편, 당신의 작품을 예술 작품으로 간주하고 그들의 작품을 쓰레기로 간주하는 것은 누구에게도 도움이되지 않는다는 것을 이해하십시오. 당신을 포함 해서요

• 그들은 배우거나 신경 쓰지 않아도되는 것처럼 점점 더 느끼고 있습니다. 그들은 단지 필요한 것을하고 집으로 돌아갑니다.

  물론 그들은 그들에게 필요한 것을 할 것입니다. 주의 사항 : 상황이 아닌 사람 과 바로 통계를 얻을 . 상황에 따라 그들이하는 일에 최선을 다해야한다면 그렇게 할 것입니다. 상황에 따라 가능한 한 많은 KLOC를 한 달에 생산해야한다면 더 이상 아무것도하지 않을 것입니다.

코딩 표준을 구현하고 표준, 디자인 패턴, 코드 스 니펫 라이브러리 등을 지침으로 사용할 수 있습니다.

코딩 표준은 공백이나 탭을 사용할지, 시도하고 사용할 디자인 패턴, 명명 규칙 등을 결정하는 것까지 다양 할 수 있습니다. 이는 모든 사람이 다르게 코딩하더라도 먼 길을 갈 것입니다.

가능하면 코딩 표준 및 코드 검토를 구현하여 매번 체크인 할 때마다 검토를 시작하십시오. 소규모 팀의 경우 코드에 2 배 또는 3 배의 추가 비용을 지출하면 전체 개발 시간을 20 배 또는 30 배 절약 할 수 있다는 것을 이해하지 못하는 사람들에게는 어려운 판매가 될 것입니다. 그러나 이것이 바로 구매 가치가있는 또 다른 개념입니다 에.

나는 한 번에 모든 것을 구현하려고 시도하지 않고 들여 쓰기뿐만 아니라 코드에서 만난 것들에 대해 생각하도록 표준을 만들려고 최선을 다할 것입니다. 그들의 삶을 더 쉽고 어렵게 만들었습니다.

일주일에 하루에 한 사람 씩 옳고 그름이 무엇인지 검토하기 위해 모임을 갖는 것도 고려하십시오. 또한 각 사람이 다른 사람이 그 주에 가장 도움이 된 일을 말할 기회를 줄 수도 있습니다. . XP / Agile 서적에서 이와 같은 더 많은 아이디어를 얻을 수 있습니다. 작은 팀이기 때문에 이것은 어려운 판매 일 수 있습니다.

언어 문제를 언급했습니다. 현지 근로자 (현장 계약자 또는 정규직 직원)가 큰 문제가되지는 않지만 원격으로 일하는 해외 계약자 인 경우-개인적인 경험으로는 결코 그렇지 않다고 말할 수 있습니다. 문제가 해결 될 것으로 판단 될 때까지 회사를 떠나거나 회사를 떠날 것을 고려하십시오. 업무에 책임이있는 상황에 처하지 말고 팀의 개발 관행을 고치려고 노력하는 데 시간을 낭비하지 마십시오. 코드 작업을 수행하는 데 100 %의 시간을 소비하는 작업으로 발전 할 가능성이 높습니다. 그런데 많은 해외 ​​계약자들은 훌륭한 프로그래머입니다. 저는 계약 회사가 당신이 묘사 한 재능의 유형을 당신에게 보냈을 때를 언급하고 있습니다.

당신이 묘사하는 증상은 팀 응집력 이 부족하다는 것을 강력하게 암시합니다 .

이러한 상황에서 코딩 표준, 교육, 절차 또는 도구는 실질적으로 품질을 향상시킬 수있는 은색 총알이 아닙니다. 먼저 팀 정신, 개방적이고 건설적인 의사 소통 및 제품의 소유권을 개발해야합니다.

증상 :

• "그들은 단지 필요한 것을하고 집으로 돌아갑니다": 그들이 강요된 소리. 그들이 도착했을 때 더 열성적이지 않았습니까?
• "우리"/ "나"/ "나"에 대한 "그들": 상호 신뢰 부족?
• "나는 몇 가지 팁을 주었다 : 나는 Git에 PR을 언급했다": 비판의 어조는 건설적인 의도에도 불구하고 공격적이거나 오만한 것으로 잘못 해석되기도한다. 왜 얼굴을 보며 이야기하지 않습니까?

당신은 작은 팀입니다 :이 장점을 사용하십시오! 시작할 몇 가지 아이디어 :

• 중요한 결정을 공동으로 내립니다. 의견 불일치에 대해 토론하십시오. "토론"은 하나의 관점을 강요하는 것이 아니라, 공통의 근거를 듣고 찾으려고 노력하는 것입니다.
• 코드의 중요한 부분을 리팩토링 했으므로 소유권이 매우 높습니다. 그들이 사도록하세요. 그들에게 한마디시켜주세요.
• 또한 코드 형식과 같은 매우 민감하지만 주관적인 주제의 경우 각 체크인시 느낌없이 표준에 따라 형식을 다시 지정할 자동화 된 예쁜 프린터의 의무를 아웃소싱하십시오.

오늘의 인용문 :

빨리 가고 싶다면 혼자 가십시오. 멀리 가고 싶다면 같이가

귀하의 질문은 "회사 변경 또는 회사 변경"으로 답변 할 수 있습니다. 모르는 사람들에게 이것은 회사에서보고 싶은 변화를 가져 오거나 당신이 일하고있는 회사를 바꾸려고 (즉, 다른 장소를 떠나고 일하기 위해) 투쟁하고 싸우는 것을 의미합니다.

두 번째 부분이 가장 간단합니다. 당신은 당신이 일하는 것과 같은 가치를 공유하는 회사를 떠나게됩니다. 첫 번째는 ... 사람 때문에 그렇게 간단하지 않습니다.

당신이해야 할 일은 사람들을 변화시키는 것입니다. 그것들이 깨져서 고쳐야한다고 생각하는 것은 효과가 없습니다. 사람들은 감정적 인 존재입니다. 이것은 개인적인 전쟁에서 쉽게 퇴보 할 수 있습니다. 그래서...

우선, 상황이 왜 그런지 알아 내야합니다. 모두에게 이야기하십시오. 찾아. 지금보고있는 것은 수년에 걸쳐 내려진 결정의 결과입니다 (또는 적절한시기에 중요한 결정을하지 않을 수도 있습니다). 판단하지 말고 결론을 내리지 마십시오.

경험이 부족한 개발자 때문입니까? 경영진이 경험이 많고 값 비싼 개발자 대신 저렴한 졸업생을 고용하여 비용을 줄이려고했기 때문입니까? 사람들이 게으르고 악의가 있거나 깨진 시스템으로 패배 한 사람들에 관한 것입니까? 작업을 수행하기 위해 "무엇을해야합니까?"라는 마감 시한이 있습니까? 기타

이 소프트웨어 개발 분야의 문제점은 사람들이 직업을 배우는 것입니다. 그들이 혹독한 환경에서 일하면 나쁜 습관을 들이게 될 것입니다. 그리고 습관은 고착하고 흔들리는 경향이 있습니다. 그러면 그들이 아는 전부이기 때문에 더 잘 알지 못합니다. 모든 개발자가 더 나아지거나 개선하기 위해 시간을 투자하기 위해하는 일에 열정을 갖는 것은 아닙니다. 다른 여러 가지 이유로이 사업에 참여한 사람들도 있습니다. 사람들이 왜 그런지 알아보십시오.

그런 다음 관리가 있습니다. 경영진이 상황을 알지 못하거나 신경 쓰지 않습니까? 찾아. 상황을 개선하려면 경영진의 지원이 절대적으로 필요합니다. 테스트를 작성하고, 코드 검토를 수행하고, 팀과 화이트 보드에서 논의하여 좋은 솔루션, 페어 프로그램 등을 결정해야하므로 갑자기 빌드하는 데 3 개월이 걸리던 것이 4 개월이 걸리기 시작하면 경영진이 시차를 알아 차릴 수 있도록하십시오. 3 개월에서 4 개월로 바뀌는 것은 관찰하고 측정하기가 쉽습니다. 견고한 코드 기반, 유지 관리 가능한 제품, 우수한 안정적인 아키텍처, 더 나은 제품 구조를 만드는 요소는 측정하기가 쉽지 않습니다. 모범 사례가 장기적으로 구매하는 시간은 사전에 측정 할 수 없으며, 사실 이후에도 측정 할 수 없습니다. 반면에 한 달의 지연은 결코 쉬운 일이 아닙니다. 이에 대한 관리 지원도 있습니다. 열심히 판매 할 준비를하십시오.

또한 사업의 맥락을 살펴보십시오. 이것이 업무 방식에 영향을 줍니까? 코드 품질이나 모범 사례의 희생을 포함하여 모든 비용을 따라야 할 기회가 있습니까?

잠시 관점을 바꾸자.

나는 그들이 내 예술 작품에 스파게티를 추가 할 때 매우 화가 나고 직장에서의 기분과 생산성에 영향을 미칩니다.

미안 ... 뭐? 미술? 나는 우리 대부분이 동료들로부터 인정 받기 위해 여기에 있다는 것을 알고 있으며, 당신이 좋은 개발자라면 그림 옆에 박물관에 코드가 표시되어 있습니까? 그것을 보는 사람들에게 감정을 불러 일으켜야합니까? 기쁨과 행복의 눈물? 그렇습니다. 나는 냉소적이며 현실감을 유지하기 위해 고의적으로 과장하고 있습니다. 감정적으로 코드에 첨부하지 마십시오.

나는 버스에서 팀, 프로젝트 및 회사를 행복하게 던져서 모든 사람에게 자신의 "예술"을 강요하는 사람과 함께 일했습니다. 그는 "진리 보유자"였으며, 정의상 모든 사람은 경험이없고, 맹인이며, 배우고 싶지 않았으며, 신경 쓰지 않았거나, 멍청한 멍청했습니다. 그 사람이되지 마십시오. 소프트웨어 개발자는 업무 가치를 높이고 꾸준한 미래의 변화 속에서도 계속해서이를 수행 할 수있는 좋은 코드, 테스트 된 코드, 유지 관리 가능한 코드, 코드를 작성해야합니다. 그리고 예산 및 시간 제약 조건 하에서이 모든 작업을 수행해야합니다. 이것이 바로 전문 소프트웨어 개발자라는 의미입니다. 아트 갤러리가 아니라면 아트는 비즈니스에 좋지 않습니다. 실용적이고 사물에 대한 균형 잡힌 견해를 유지하십시오. " 동료가 작성한 잘못된 코드를 무시하고 업무에만 집중하는 방법"문제의 틀을 잡은 방식 때문에 질문이 닫혔습니다. 물러서서 모든 것을 살펴보십시오.

'나쁜 회사 문화', '불편한 졸업생'등에 중점을 두지 않고이 상황을 어떻게 해결하고 실제로 상황을 개선하기 시작할 수 있습니까?

TL; DR : 상황을주의 깊게 살펴보고 그 상황에서 왜 일이 일어 났는지 알아보십시오. 상황이 이와 같다는 점을 인정하고 거기서 어떻게 개선 할 수 있는지보십시오. 모든 사람들의 의견이 무엇인지 알아보십시오. 전투를 선택하십시오. 강제 변경이 작동하지 않습니다. 협업하여 변경하십시오. 상황이 얼마나 나 빠지지 않았는지 개선 할 수있는 방법을 보여 주어야합니다. 당신이하고 싶은 것은 장기적으로 더 큰 이익을위한 것이라고 모두에게 설득하십시오. 탑승하십시오.

그리고 작은 단계로 수행하십시오.

한 번에 너무 많은 변화를 가져 오면 사람들은 낙담하고 포기하게됩니다. 변경에는 시간이 걸립니다. 회사를 바꾸거나 회사를 바꾸십시오. 행운을 빕니다!