구식 동료 취급

저는 상당히 젊은 프로그래머이며 중소 기업 IT 부서에서 일합니다. 동료가 있는데 정말 좋은 Visual Basic 6 프로그래머입니다. 그리고 나는 정말로 좋은 것을 의미합니다. 솔직히 그는 첫 번째 커피를 마시고 내 컴퓨터를 부팅해야 할 때 버그가 거의없는 작업 응용 프로그램을 제공 할 수 있습니다. 그는 단지 좋다.

우리는 팀과 함께 일하고 있으며 그의 작업 스타일은 완전히 구식입니다. 그는 버저 닝 소프트웨어를 믿지 않습니다 (코드가 올바른지 확인하는 경우에는 말도 안되는 부분이 모두 필요하지 않습니다). 배포를 믿지 않습니다 (작동하는 실행 파일을 제공 할 수 있습니다. 배포 방법은 sysadmins가 파악하는 것입니다). 추상화를 믿지 않습니다. ( '서브 루틴을 만들려면 계속 진행하되, 해당 서브 루틴에서 서브 루틴을 호출하지 마십시오. 그렇게 지저분 해지고 코드를 따르기가 어렵습니다.이 방식으로 모든 사람이 진행중인 모든 단계를 수행 할 수 있습니다. '또는'예, 해당 라이브러리를 사용하여이를 수행 할 수 있지만 실제로는 진행 상황을 이해하지 못합니다 ') 확실히 OOP를 믿지 않습니다. (우리는 VB.net에서 일합니다)

그는 자신이하는 일에 능숙하며, 가능한 한 빨리 애플리케이션을 제공 할 수 있습니다. 그러나 그것은 팀에서 작동하지 않습니다. 우리의 다른 팀원은 조용하고 말을 좋아하지 않지만 동의하는 경향이 있습니다. 우리 관리자는 내가 올바른 지적을한다고 생각하지만 프로그래머는 아닙니다.

그가 작성한 프로그램을 유지하는 데 어려움을 겪고 있으며 팀 분위기가 좋지 않습니다. 내가 가장 잘하는 일은 무엇이라고 생각하십니까?

이것은 진실이 다가오는 것을 알고있는 "그는 좋은 사람이지만 ..."인 것 같습니다. 그리고 진실은 그가 엔지니어만큼 좋지 않은 것처럼 들립니다. 좋은 소프트웨어는 단순한 작업 및 개발 속도가 아닙니다. 또한 유지 관리 성, 호환성, 추상화 (향후 효율성을 위해) 등 언급 한 다른 사항에 대해서도 설명합니다.

그래서, 그것은 당신이 손에 문제 개발자가있는 것처럼 들립니다. 당신에게 더 나쁜 것은 그가 입증되었고 아마도 그의 방식으로 설정되었다는 것입니다. 그래서 당신은 무엇을 할 수 있습니까?

• 그 주위를 해결하십시오.
• 자신이하는 것처럼 일정대로 프로젝트를 제작하도록 노력하십시오.
• 당신이 할 수 없다면, 더 나은 결과를 생산하십시오 .
• 시간이 지남에 따라 그가 무시한 입증 된 개념은 당신에게 돈을 지불하기 시작합니다.

반면에, 당신이 자신의 길을 강요 받으면 떠나십시오.

동료를 바꾸려고하지 마십시오. 당신은 그를 일하는 소프트웨어를 제공 할 수있는 사람으로 묘사하고 있습니다. 팀에 통합하기에는 너무 늦었을 것입니다.

따라서 두 가지 선택이 있습니다.

• 자신을 적응 시키 십시오. 아마도 시간이 지남에 따라 소스 제어 시스템의 유용성을 그에게 확신시킬 수 있습니까? 당신은 영향력의 범위 를 증가시켜야 할 것 입니다. 변화에 대한 저항력이 높을수록 더 많은 시간이 필요합니다.

• 에서 자신 을 제거하십시오team . 당신은 이것을 정당화 할 많은 포인트가 있습니다. 어쩌면 당신은 그것의 자신의 응용 프로그램을 유지하고 새로운 것들에 자신을 헌신해야합니다.

• 에서 자신 을 제거하십시오company . 때로는 이것이 유일한 솔루션입니다.

내가 당신이라면 지금 내 자신의 소스 제어 시스템을 설정합니다. 코드를 작성하는 데 사용하고 다른 팀 구성원이 계정을 가지고 액세스 할 수 있도록 관리하십시오. 다른 동료들도 그것을 사용하는 데 열의를 보일 것입니다.

그러한 관행을 믿지 않는 동료는 설득하기 쉽지 않을 수 있습니다. 그러나 사용자가 작성해야하는 코드는 버전 제어로 이동하여 작업 할 수 있습니다. 변경 사항에 액세스해야하는 경우 리포지토리에서 코드를 가져 오는 방법에 대한 간단한 단계별 지침을 보내십시오.

더 현대적인 프로세스에 참여하기 위해 싸우거나 그보다 앞서 갈 필요는 없습니다. 때로는 자신의 길을 가고 행동으로 리더가되는 것이 누군가에게 말로 설득하는 것보다 효과적입니다. 걸음마. 그가 버전 제어에 더 반응하기 시작하면 서브 루틴 리팩토링을 시작하고 변경 사항으로부터 보호하기 위해 단위 테스트를 추가하십시오. 테스트를 자동화하고 체크인하자마자 결과에 액세스 할 수있는 방법을 보여줍니다.

많은 사람들은 변화를 좋아하지 않기 때문에 저항력이 있습니다. 그러나 변화가 점진적으로 그리고 따르기 쉬운 방식으로 제시되면 종종 혜택을 매우 빨리 보게됩니다.

무엇보다도, 그를 위해 가능한 한 간단하게 만드십시오 (간단하게 유지하십시오). 자신의 용어로 이러한 관행을 따르도록 시작하십시오. 그러나 당신을 아래로 끌지 마십시오.

솔직히 말하면, 당신은 그의 좋은 그림을 그리는 것이 아닙니다. 유지 보수가 어려운 소프트웨어, 구식 등의 새로운 방식에 고집

당신이 말한 바에 따르면, 재사용 가능한 라이브러리와 빠른 응용 프로그램 개발을 목표로하는 디자인 패턴을 사용하지 않고 버그가없는 소프트웨어 FASTER를 훨씬 더 빨리 생산하는 경우 그보다 자신에 대해 더 많이 말합니다 ...

.. 그에 대해 .yeh, 그와 함께 일하지 않고 자신의 일과 관련되지 않는 방법을 찾으십시오. 그는 자신의 일에 대해 전형적인 이기적인 태도를 가진 것 같습니다. 당신은 그런 사람과 일할 수 없으며, 당신은 그들이 일하는 것을 관찰하고 (현재 당신처럼) 정리할 수 있습니다.

나는 이것을 전에 본 적이있다 .

그리고 나는 거의 기꺼이 내기를한다 :이 유형의 녀석 은 그의 머리에 시도되고 테스트 된 "패턴"이 있기 때문에 "빠른" 것만 보인다 . LOB ( Business of Business) 앱의 99 % 는 CRUD 입니다.

그는 아마도 기존 코드에서 많은 Copy & Paste를 사용합니다 (그것에 아무런 문제가 없습니다).

그러나..

그가 원격으로 복잡한 것을 만난 순간, 왜 넘어 지는가? 더 이상 기본 "패턴"에 맞지 않기 때문입니다.

약간의 도전 ...

OOP와 코드 재사용의 이점을 얻는 복잡한 프로젝트를 측면에서 만들었습니다.

그런 다음 해당 프로젝트를 보여주고 기능을 구현하도록 요청하십시오.

그런 다음 그의 코드가 자신의 방식으로 구현 한 경우 거의 10 배 더 커지고 10 배 더 추악 해질 것입니다.

비즈니스 측면에서 이것을보십시오.

버그가 많은 코드를 생성하는 데 시간이 더 걸립니다. 따라서 적은 수익을 낼 수 있습니다.

시간이 지남에 따라 이것을 되돌릴 수 있다면 이것을 바꿀 수 있습니다.

그러나 아마도 아마도이 구식 프로그래머는 실제로 버그가없는 코드를 빠르게 생성하는 방법에 대해 몇 가지를 가르쳐 줄 수 있습니까? 아마도 그의 기술은 생각보다 구식이 아닐까요?

누군가가 아주 좋은 관행없이 그러한 훌륭한 코드를 생성 할 수 있다고 생각합니다. 이러한 관행을 배우고 이해하는 "최상의 관행"과 최신 유행에 적용 할 수 있습니다.

관리자가 프로그래머가 아닌 경우 이해할 수있는 용어로 시도하십시오.

• Sourecontrol을 사용해야합니다. 그렇지 않으면 복구하는 데 큰 문제가있을 수 있습니다.

• 그것은 나를 소요 x를 그는 몇 가지 매우 기본적인 프로세스를 수행하는 것을 거부하기 때문에 긴 시간의 양.

다른 한편으로, 당신이 완벽에 빠지지 않도록하십시오. 즉, 이것이 우리가 따라야하는 가장 좋은 방법입니다. 동료에게 추가해야 할 내용이 많을 수 있으므로 올바른 방향으로 천천히 움직여야 할 수도 있습니다.

동료가 팀에서 개발 한 적이없는 것 같습니다. 그런 종류의 솔로 전문가 종류의 파트너는 좋은 그룹 역 동성을 허용하지 않습니다. 따라서 상사에게 그것에 대해 말하고 파트너의 열망과 장단점을 논의하십시오. 더 좋은 방법으로 할 수는 있지만 거절하면 명령의 한가운데로 올라갑니다.

여기처럼 평범하고 단순하게 관리자에게 문의하십시오. 성장의 여지가 있습니다. 동료가 좋다고 말하면 동료가 올바른 OO 개념으로 소스 컨트롤과 .Net을 사용하도록 전환하는 데 설득력이 없어야합니다.

나는 당신이 어디에 있는지에 대한 더 넓은 그림을 얻기 위해 다른 사람들과 이야기하고 싶습니다. 아마도 코드가 다른 코드와 너무 많이 섞일 필요가 없도록 약간의 분리가있을 수 있습니다.이 코드를 처리 할 수있는 한 가지 방법으로 자신의 영역으로 분리 할 가능성이 있기 때문에이 코드는 개발자가 아닌 감독 또는 CIO.

스파게티 코드가 "OOP, OOP의 땅에 들어갈 수있는 빌딩 블록이 많은 경향이있는 일부 큰 엔터프라이즈 시스템이 있기 때문에 어떤 종류의 더 큰 시스템이 구축되었는지 확인하기 위해 그와 대화하고 싶을 수도 있습니다. 좋을 수 있습니다! " 비록 이것이 이것이 자신의 도구 상자에 가지고있는 유용한 방법을 보는 것이 매우 유용한 경우가 종종 있습니다.

무관심은 그가 코드를 디자인하는 경향이 있지만 근본적으로 Kool-aid를 너무 많이 사용했다는 점에서 내가 근본에 가깝다고 생각하는 것들을 거부 한 이유인지 알 수있는 또 다른 용의자 일 수 있습니다.

다른 방법으로 당신을 증명하기 위해 (좋은 방법으로) 그에게 도전하고, 그에게 도구와 연습의 멋진면을 보여주십시오. 장사하지 마세요.

예를 들어, 그는 버전 관리를 보조 도구로 믿지 않지만 브랜치 / 병합 방법과 파일이 불필요하게 여러 가지 실험적 기능을 수행하는 방법을 보여줍니다.

OOP와 관련하여 명령 패턴, 작업 패턴 및 귀중한 시간을 절약하는 방법 및 모든 팀과 같은 멋진 / 복잡한 디자인 패턴을 보여줍니다.

당신이 그를 조금이라도 관심이 없다면 ... 그는 잃어버린 사건 일지 모르지만 다시 팀을위한 도구를 가지고 있으며 그를 능가 할 수 있습니다. 관리자가 볼 수있는 메시지를 표시 / 이메일 커밋 메시지를 표시 / 이메일로 보내서 관리자에게 투명성을 가져오고 동료를 그림에서 제외시키는 저장소 소프트웨어를 사용해보십시오 (bitbucket.org에는 수은을 사용하는 경우 무제한 개인 공간이있는 개인 저장소가 있습니다).

결국, 말로 설득하려고 노력하지 말고 반박 할 수없는 행동으로, 완고한 사람들 IMHO를 다루는 가장 좋은 방법입니다 (역 심리학은 때때로 작동합니다, lol).

글쎄, 당신이 언급 한 기술은 분명히 좋지만, 당신이 그것을 이데올로기로 밀고 있는지 스스로에게 물어볼 필요가 있습니다. 저는 젊은 프로그래머들이 대학에서받은 것에 대해 약간 복음주의적인 경향이 있다는 것을 알게되었습니다. 이러한 기술은 결과로 인해 우수하다는 것을 기억하십시오: 버전 제어를 통해 동시 개발, 설계, 개발, 테스트, 버그 수정 단계를보다 명확하게 추적 할 수 있습니다. 프로젝트가 실제로 단기적이라면, 그 중 많은 것이 단순히 부적절하며, 민첩성을 떨어 뜨릴 것입니다. 모범 사례가 가능한 모든 모범 사례를 사용한다는 의미는 아닙니다. 예를 들어, 추상화는 적어도 몇 번은 원조보다 확실히 책임이 될 수 있습니다. 버전 제어는 개발 타임 라인, 복잡한 코드, 여러 프로그래머를 확장했을 때 가장 의미가 있습니다.

프로젝트를 진행하거나 공통점 또는보다 일반적인 프레임 워크에 대해 생각할 때 잠재적 인 재사용 가능성에 주목해야합니다. 프로젝트를 시작하려고 시도하는 것은 강력한 움직임이며 더 많은 기술로 일하게 할 수 있습니다 ...

"버전 관리"소프트웨어가 좋은 이유에 대해 관리자에게 모든 사람 을 위한 프레젠테이션을하도록 요청해야합니다 . 동료를 외면하지 마십시오.

나는 사람들이 일을 피하는 방법으로 사람들이 항상 그것을 잘못 사용하는 것을 보았 기 때문에 소스 제어 소프트웨어에 회의적입니다.

저의 동료들은 지속적으로 합병하고 서로의 발가락을 끊임없이 밟고 있습니다. 그러나 장점에 대한 좋은 친절한 강의는 좋은 일이 될 것이며 토론을 촉진시킬 것입니다.