계약자 변경 코드 스타일

Question

현재 4 명이 팀에서 작성했지만 현재는 나로 축소 된 응용 프로그램을 지원합니다. 우리는 최근 다른 일들로 가득 차있는 동안 일부 성능 문제를 조사하는 계약자를 확보했습니다.

계약자가 실적이 좋은 것처럼 보였지만 기존 스타일을 개인 취향으로 대체 한 많은 양의 코드도 보냈습니다.

불행히도 우리는 코딩 표준 문서가 없으며 C# 일반 규칙을 준수하기위한 일반적인 규칙 만 갖고 있습니다. 그들은했습니다,

• 는 'var에'의 거의 모든 용도를 제거하는 키워드 if 문 단일 라인 어느 곳
• : 그들이 무슨 짓을했는지의 예로서

  , 그것은 포함 추가 중괄호

• 람다의 대부분을 제거 및보다 자세한 코드로 대체
• 변경 메소드 서명 정도로 모든 파라미터는 하나 개의 라인이 아닌 별도의 행에

우리는 또한 TDD 정책을 운영합니다. 특히 성능 관련 부분에 대한 테스트 커버리지는 매우 낮습니다. 변경 내용에 대한 문서를 거의 남기지 않고 체크인 주석이 특히 도움이되지 않아서 더 힘들어졌습니다. 실제 기능 변경은 '조정 (tweaks)'작업 사이에서 손실됩니다.

계약자와 관련하여 어떻게 이야기해야합니까? 분명히 프로젝트를 지원할 책임이 없으며 변화에 민감한 것처럼 보이지 않기 때문에 프로젝트를 변경하는 데 많은 자극이 없습니다.

계약서를 짧게 작성한 후에 모든 것을 이전에 사용한 코드 형식으로 다시 변경해야합니까?

커뮤니티 위키를 만든 이유는 여기에 맞는 대답이 하나도 없기 때문입니다.

Answer 1

어느 곳과 문 단일 라인은, 그들은 중괄호

이 하나 도움이 될 수있는 유일한 하나를 추가 한 경우.

• 변경 메소드 서명을 람다의 대부분을 제거 'var에'키워드
• 의 거의 모든 용도를 제거하고 더 자세한 코드로 대체하므로 모든 매개 변수는 별도의 줄이 아니라에 한 줄

이러한 것들은 바뀌지 않습니다.

코드를 다시 작성할 권한이 없다고 말합니다. 이 활동을 위해 낭비되는 시간을 지불하지 않을 것이며 일을 다시하기 위해 자신의 시간을 사용해야 할 것입니다. 그것은 다과를 제공해야합니다.

이러한 사항은 사전에 논의해야합니다. 허용되는 활동과 허용되지 않는 활동을 분명하게 기술해야합니다.오래전에 데이터베이스 엔티티를 포함하여 코드 전체에 머리 글자를 넣는 계약자에 대한 또 다른 비슷한 질문이있었습니다. 그것은 다른 누군가의 암호에 어떤 자리도없는 자기 계발의 비꼬 인 종류였습니다.

P. 이러한 모든 일을함으로써 계약자가 인위적으로 추가 작업량을 만들어서 더 많은 시간을 청구 할 가능성도 있습니다.

Answer 2

계약자와 관련하여 어떻게 이야기해야합니까?

정중하게 : 왜 소스 코드의 변경을 최소화하고 싶은지 설명하십시오.

또는 체크인 전에 변경 사항에 대한 코드 검사를 수행하고, 사용자가 이해하지 못하거나 원하지 않는/테스트하지 않은 변경 사항의 체크인을 허용하지 않습니다.

Answer 3

다른 문제가 발생했는데 다른 문제는 귀하의 돈을 부당하게 낭비하는 것이므로 중괄호가 맞을 수도 있습니다.

향후 문제를 예방하고이를 해결하는 데 도움이되도록 stylecop 구현을 설정하는 것이 좋습니다. 최소한 규칙을 위반할 때를 인식하지 못할 수는 없습니다.

Answer 4

나는 우리가 "나는 그것을 할 수있는 방법이 아니다"라고 생각하는 것을 보았다는 유혹을 알고 있다고 생각합니다. 그러나 우리는 그것을 거부합니다.

먼저 상사와 이야기를 나누고 싶습니다. 그러나 마음에 가장 먼저 떠오르는 것은 계약자에게 작업을 구체적으로 요구하지 않는 한 그가 추가 한 것으로 생각되는 이점과 상관없이 자신이 수행 한 작업을 수행하지 않고 있다는 것입니다. 그래서 그것에 대한 토론이 필요합니다.

마음에 떠오른 다음 일은 코드의 소유자와 얼마나 큰 차이가 있건간에 코드의 소유자와 논의하지 않고 대량 변경을하는 사람들은 좋은 소식이 아닐 수 있다는 것입니다. 그들은 사람들을 화나게 할 것이고, 더 나쁜 것은 당신이 정리해야 할 버그와 예상치 못한 행동을 소개 할 것입니다. 그는 다른 사람들의 코드에 대한 허락없이 이런 종류의 일을하는 것이 용납 될 수 없다는 것을 똑바로 세워야합니다.

주의를 집중시키기에 충분히 심각한 다른 코드를 좋아할 때 먼저 코드 소유자와 확인합니다. 분명한 버그가 있더라도 코드와 해당 코드를 정리하기로 한 결정은 내 것이 아닙니다.

Answer 5

나는 계약자 (때로는)이고, 내가 이것을했다면 나는 훌륭한 속도와 지불없이 문을 보여줄 것으로 기대합니다. 진지하게,이 사람은 당신에 의해 고용되고 그는 더 이상도 덜도하지 말라고 정확히 무엇을하고 있어야합니다. 그리고 "훌륭함"에 대해 걱정하지 마십시오. 계약자는 permy에서 그런 것을 기대하지 않습니다.

Answer 6

글쎄, 나에게 나만의 해결책을 제시하는 코드와 같은 냄새가 나는데, 이는 Resharper과 같은 도구의 설정에 의해 자동화되고 시행 될 수 있습니다. 나는 그것이 매우 무례하다고 생각할 것이고, "나의 개인 취향에 따라 모든 코드를 재 포맷하라"버튼을 누르지 말 것을 요청할 것이다.

Answer 7

FxCop 구현 - 첫 번째 방어선이어야합니다. 또한 소스 컨트롤을 사용하는 경우 (하나의 최대한 빨리 구현하지 않는 경우), dev 레이블 지정 (빌드 용으로 레이블이 지정된 파일에서만 빌드)을 사용하고 레이블에 레이블을 옮길 권한을 부여하지 마십시오. 파일. 이렇게하면 자신의 변경 사항을 면밀히 검토하고 개발자의 표준을 충족 할 때까지 코드에 레이블을 지정하지 않을 수 있습니다.문제가되는 개정판으로 dev 라벨을 옮길 때까지 그가 작성한 코드는 품질 보증에 반영되지 않으므로 그곳에서 자비를 베푸는 것입니다. 일부 상점에서는 샌드 박스 빌드에 단일 레이블을 사용하지 않으며 새 레이블을 샌드 박스에도 적용하기를 원하므로 그렇게 할 수도 있습니다.

Answer 8

다른 사람들이 말했듯이, 이러한 변화는 단순히 코딩 스타일에 대한 것입니다. 그가 성능 향상을 위해 존재한다면, 그는 이러한 변화에 시간을 낭비하고 있습니다. 이러한 변화가 성과를 향상시키는 방법을 언급 할 수 없다면 그의 강박증은 법안을 실행하는 중입니다.

나는 라고 말하고 싶습니다. "코딩 스타일을 변경해 주셔서 감사합니다. 그러나 속도 저하의 원인이되는 코드 영역의 비 스타일 변경에 집중할 수 있습니다."

Answer 9

계약자가 허가없이 코드를 도매 형식으로 다시 포맷 한 경우, 나는 그에게 한 번만의 변경으로 자신의 시간에 되돌릴 수 있습니다.

다른 사람이 만드는 유효한 점 외에도, 이로 인해 발생하는 버전 제어 악몽을 고려하십시오. 여기에 몇 줄의 깨끗한 진행 대신에 몇 줄이 변경되었으므로 이제 소스 제어 데이터베이스에이 "틈새"가 생겨서이 계약자의 "개선 사항"전후 버전 간의 비교는 의미가 없습니다.

계약자에게 변경 사항이 있습니다. 오늘. 그리고 자신의 시간에.

Answer 10

이것은 사람들이 '개선'을하는 것을 거부 할 수 없으며 갑자기 원하지 않는 물건에 대해 요금이 청구되는 것을 알게되는 매우 일반적인 경험입니다. 때로는 더 많은 보수를받는 것이 의도적으로 이루어졌지만, 대부분 개발자가 횡단하고 '잘못된 코드'를 남기지 못하는 것으로 생각합니다. 약간의 전투가 필요할 수도 있지만 기본적으로 "작업을 요청하지 않은 사항은 변경하지 마십시오."라는 말을 반복해야합니다. 그의 성격에 따라, 한 번만 친절하게 물어 보거나 강제로 더 높은 사람을 구해야 할 수도 있습니다.

Answer 11

먼저 다른 사람들이 말했듯이. 청구서를 지불하고 있습니다. 그는 직원이 아닙니다. 그의 직업은 당신이 그에게 무엇을 요구하는지, 당신이 요구하는 것만을하는 것입니다. 그렇지 않으면 그에게 그 문을 보여줄 수 있습니다. 항상 이것을 기억하십시오. 당신은 배가 아니라 운전하고 있습니다. 당신은 그에게 돈을 지불하지 않으려 고 할 수는 있지만, 법적 계약을 맺고있는 상태에서 코드를 그대로 두는 것에 대해서는 아무 것도 없다면 그렇게하기가 어렵습니다. 그러나 언제든지 그를 그냥 보내 줄 수 있습니다.

둘째로, 그 사람을 멈추고 되돌릴 수 없으면 그 사람을 없앨 수 없으며, 스타일을 변경할 계획이라면 그 사람은 스타일 변경을 모두해야한다고 말할 수 있습니다 절대 코드 변경없이 체크인하십시오. 이를 통해 코드 변경 사항을 확인하기 위해 diffed 수있는 기본 코드 집합에서 앞으로 이동할 수 있습니다.

셋째, 그가 변경 한 사항에 대한 설명을 설명하게하십시오. var 제거는 성능상의 이점이 없습니다.

넷째, 이것은 많은 것을 빨아 먹을 수 있지만, 사실은 ReSharper를 사용하여 코드를 사실 이후에 사용자가 수락 한 스타일로 되돌려 놓습니다. 그것은 더 많은 작업이고, 당신은 여전히 ​​borked diffs를 가지고 있지만 오 잘. 람다는 더 열심히 일합니다. 그리고 당신이 정말로 그의 경우에 대해 알아야 할 것이 있습니다.

다섯 번째로, 포인트를 집에 넣고 그가 한 모든 변경 사항을 취소하고 스타일 변경이 아닌 코드 변경 만 다시 수행하도록합니다. 그가 스스로 알아낼 수 없을 때 그가 만든 엉망에 관해서는 눈을 뜨게해야합니다.

마지막으로, 글 머리 기호를 물고 그를 다시 불러올 수 있습니다.예, 그것은 끔찍합니다. 그러나 당신이 그를 치안하지 않는 실수를했기 때문에, 당신이 원하는 것을 정면으로 지정하지 않고, 그가 할 수없는 일을 ... 당신은 궁극의 가격을 지불 할 것입니다. 그에게 돈을 지불하거나, 다른 사람에게 돈을 지불하거나, 돈을 지불하거나, 돈으로 살 수 있습니다. (그리고 borked diffs의 가격을 지불 할 수도 있습니다.) 어떤 식 으로든 자르면 돈이 들게됩니다.

Answer 12

처음에는 상황을 피하려면 코드 검토를 소개하십시오. 특히 새로운 개발자가 귀하의 표준을 모르는 사람들과 합류 할 경우 특히 그렇습니다.

전 git, 기능 브랜치 및 풀 요청 (github 또는 bitbucket)을 지원하는 서비스를 사용하는 것을 좋아합니다. TFS는 실제로 작동하지 않지만, 고맙게도 Visual Studio는 git를 지원합니다. 마스터와 병합하기 전에 코드 리뷰를하면 코드가 깨져 버리지 않습니다. 편집증 환자라면 계약 업체가 기본 저장소에 대한 액세스 권한을 쓸 필요가 없습니다.

Answer 13

보기

다른 점 :

당신의 메이크업 두 문장 :와 "계약자는 성능 좋은 일을하기 위해 등장했다 동안" "그들은 또한 사전을 대체하는 코드의 많은 양의를 통과했다 자신의 취향에 맞는 기존 스타일. "

다음과 같은 많은 질문이 제기됩니다. 계약자를 단기간 동안 "끌어 들여"성능을 향상시킬 수있는 경우. 이는 처음부터 응용 프로그램에 큰 결함이 있었음을 나타냅니다. "성능 향상"을 위해 계약자를 불러들이려고 할 때마다 이것은 매우 잘못 작성된 코드 또는 하이 엔드 전문 지식을 필요로하는 매우 복잡한 문제의 신호입니다.

다음 : 명시된 코드 스타일이 없더라도 코드 스타일을 변경했다는 불만을 토로 할 때 모조에 대한 무의미한 주장을 다른 사람의 모조보다 낫게 만드는 것입니다. 어쩌면 당신은 그 사람에게 왜 그들이 완전한 그림을 가질 수 있도록 구문 적으로 나타나는 변경을했는지 물어봐야 할 것입니다.

나는이 게시물에 대한 한 면면 응답의 긴 목록을보고 상대방에게 무슨 일이 일어 났는지 궁금합니다. 사람들은 감정을 꺼내 객관적으로 봅니다. 변수 이름 지정 규칙이 낙타의 경우에서 파스칼의 경우로 바뀌 었음을 알기 위해 몇 명의 사람들이 아름다운 알고리즘 솔루션을 지나서 복잡한 문제를 보게 될지 놀라는 경우가 많습니다. 나는 일반적으로 이러한 유형의 반응을 중요하지 않은 결점을 찾아내어 자기 가치의 정당화에 적용합니다.

핵심 질문 : 새로 형식이 지정된 코드로 인해 응용 프로그램의 읽기가 어려워 졌습니까? 예산 제약이있는 이유는 무엇입니까? 왜 매우 구체적인 수정을 원한다고 명시하지 않았습니까? 특정 코딩 스타일을 유지하기를 원한다면 명시 적으로 명시하지 않는 것이 어떻습니까?