마감 시간이 촉박 할 때 다른 사람의 코드를 정리하는 것이 얼마나 중요합니까? [닫은]

(저는 프로그래밍 언어가 아닌 HTML / CSS 코드에 대해 이야기하고 있지만 프로그래머와 같은 문제에 직면하고 있다고 생각합니다.)

저는 팀의 선임 프론트 엔드 디자이너이며, 종종 마감일에 주니어 출력을 재 작업해야합니다.

나는 두 가지 문제에 직면 해있다.

1. 그들의 코딩 스타일은 약간 엉망입니다.
2. 미학은 좋지 않습니다.

그들의 코딩 스타일은 적절한 컨벤션 / 표준이없는 혼합 가방입니다. 나는 코드를 정리하거나 코드를 다루는 것 사이에서 찢어졌습니다.

나쁜 습관을 배울 수 있다고 생각할 때 코딩 스타일을 따르는 것이 실망 스럽습니다. 그러나 마감일을 맞추는 가장 빠른 방법입니다.

더 많은 경험을 가진 사람들에게 어느 것이 더 효과적입니까? 나중에 정리를 저장해야합니까? 아니면 내가 변경하는 동안 정리?

(하지만 오만한 소리를 내고 싶지는 않지만 현실은 그런 것입니다. 더 나은 코드를 작성하는 데 몇 년이 걸릴 것입니다. 시작했을 때 지저분한 코드를 작성했습니다.)

문제를 잘못된 방식으로보고 있다고 생각합니다. 주니어에게 더 나은 코드를 작성하는 방법을 가르 칠 수있는 좋은 기회가 없습니다.

습관적으로 코드를 다시 작성하면 후배들에게 자신의 일을 소중히 여기지 않는다는 인상을 줄 수 있습니다.

더 나은 접근 방법은 팀의 개발 프로세스에 코드 검토 작업을 추가하는 것입니다. 커밋 된 모든 코드에 대해 다를 필요는 없으며, 팀원이 충분히 큰 작업을 마칠 때마다 자신 만 수행 할 필요는 없습니다. 팀 동료 중 한 명 이상과 짝을 이루어 코드를 설명하고 디자인, 코딩 스타일, 가능한 버그 및 보안 문제 등에 대한 건설적인 의견과 비판을받습니다.

코드 검토 팀 동료 인 경우 코드를 다시 작성하면 (코드 변경 이유 를들을 수있는 기회를 얻음) 전문 지식을 통해 배우게되며 공격성이 줄어 듭니다.

그들에게 코드 검토를 수행 할 수있는 기회를 주면 다른 사람들이 코드를 작성하는 방법과 이유를보고 그들의 자존심을 높일 수있는 능력을 향상시킬 수 있습니다.

또한 코드 를 검토 할 기회를 주면 많은 것을 배우게됩니다 . 당신도 무언가를 배울 수 있습니다-보여주기 위해 그것을하지 마십시오!

나는 이것을 전에 말했고 "일하는 코드는 예쁜 코드보다 더 가치있다"고 다시 말할 것입니다.

코드를 변경하면 동작이 변경 될 가능성이 높으며, 테스트 된 코드 인 경우 모든 테스트 노력을 무효화 한 것이므로 테스트를 반복해야합니다.

반드시 후배들에게 깨끗하고 이해하기 쉬운 코드를 작성하도록 장려하십시오. 그러나 모든 것을 다시 쓰려고하면 고용주에게 여러 번 돈을 낭비하게됩니다. 그들은 당신의 후배에게 돈을 지불하고, 당신이 이미 당신의 후배에게 지불 한 것을하도록 지불하고, 그들이 실제로 당신을 고용 한 일을하기 위해 당신에게 한 번 더 지불해야합니다.

• 짧은 대답은 : 아니요. 시간이 어려울 때 때로는 머리를 내려 놓고 미적 총알을 가져 가야합니다. ;)

• 더 실용적인 답변은 타임 박스에 넣는 것입니다. 코드의 특정 측면을 정리하고 정리하기 위해 한 시간 동안 예산을 책정 하십시오. 그런 다음 체크인하고 실제 작업을 수행하십시오. 그러나 제한 유지에 대해 자신에게 정직하십시오.

• 그러나 때로는 약간의 정리만으로 작업 속도가 빨라집니다. 빠른 검색 및 교체 유형 변경조차도 모든 것을 훨씬 쉽게 이용할 수 있습니다.

• 스타일 전쟁에주의하십시오. 특히 마감 시간이 촉박 한 상황에서 다른 프로그래머가 다시 수행 할 수있는 문체 적 환경 설정을 취소하려는 경우, 다시 말해서 문제 해결 방법을 실제로 해결할 때까지 기다리는 것이 좋습니다. 공동으로 문체 문제. (어떤 사람들은주고받는 것을 의미합니다.)

그러나 답에는 판단 가치가 있습니다. 나는 "보통"중요하다고 말할 것입니다. 깨끗한 코드는 실제로 작업 속도를 높이고 코드 품질은 결과물의 일부입니다. 정리에 시간을 소비하지 않고 코드를 만질 수 있다고 생각하지 않습니다. 그러나 스타일과 형식, 스타일 전쟁으로 인한 소란 이 코드를 프로덕션으로 만드는 것보다 더 중요해 지지 않도록 하십시오.

코드를 수정하고 마감일을 정할 때 일반적으로 두 가지 규칙을 사용합니다.

코드가 끔찍하지만 합리적인 시간에 문제를 찾아서 고칠 수 있습니다

나는 문제를 해결하고 나머지는 그대로 둡니다 .

코드가 너무 지저분해서 문제를 찾기가 정말 어렵습니다. 무언가를 고치면 즉시 다른 것이 깨집니다. 수정하는 것보다 처음부터 해당 코드를 작성하는 것이 더 빠를 것입니다.

그런 다음 코드를 정리하고 버그를 수정하기에 충분히 깨끗해질 때까지 다시 쓰기 / 리 팩터 이외의 다른 선택 은 없습니다 .

경계의 경우는 다음과 같습니다

코드가 지저분하고 정말 나쁩니다. 합리적인 시간에 버그를 고칠 수는 있지만 코드 구조는 유지 관리를 어렵게 만듭니다. 새로운 기능이 있으면 새로운 버그가 발생하거나 성능이 크게 저하 될 수 있습니다.

이 경우, 코드는 수정되어야하지만 유휴 시간 동안 새로운 기능이 구현 될 때에 만 마감 시한에 맞춰 버그 수정 시간이되지 않습니다!

프로세스에서이 문제를 발견 한 시점을 알고 싶습니다.

엄밀히 말하면, 우리 중 아무도 거주하지 않는이 마법의 이상적인 세상에서, 홍보되거나 배포 된 모든 코드는 완벽해야합니다. 때로는 실용적이지 않아도됩니다.

그러나 코드 검토 프로세스가있는 경우 테스트하기 전에이를 강조 표시해야합니다. 마감 기한을 지키지 못하면 개발 과정의 핵심 구성 요소, 즉 코드 검토와 같은 문제가 전달에 대한 예측에 문제가 있습니까?

시간을내어 학습 과정의 일부로 만들지 않으면 후배는 앉아서 일을 더 잘하는 방법을 배우지 않을 것입니다. 당신이 그렇게하지 않는 것처럼 들립니다.

전반적인 문화에 달려 있습니다. 마감 기한이 산발적 인 경우 나중에 정리해야한다는 점을 받아들입니다. 그들이 일정하다면, 당신은 구조적으로 기술 부채를 쌓고있는 것보다 관리 문제를 해결해야합니다. 그들이 당신의 관심사를 해결하지 못하면, 회사 문화가 곧 다윈의 원칙에 맞을 가능성이 있기 때문에 다른 직업 기회를 찾는 것이 더 좋습니다.

앞으로 문제를 억제하기 위해 모든 직원이 따라야하는 내부 코딩 표준 및 실무 문서를 개발하십시오.

현재 일괄 처리의 경우 코드를 리팩터링 할 때 S & P 문서에 따라 코드를 정리하십시오.

나는 프로그래밍에 상당히 경험이 없다. 그러나 학생으로서 저는 종종 프로젝트에 대한 동료 검토 및 파트너십을 약속합니다. 프로젝트를 완료 할 시간이 충분하다면, 명확성과 가독성을 위해 팀원의 코드를 정리해 보겠습니다. 종종, 처음 100 줄 정도를 거르는 것도 어렵다는 것을 알게 될 것입니다. 이 경우 동료 프로그래머에게 더 나은 습관과 코딩을 가르치는 데 도움을주기 위해 기꺼이 손을 내밀고 있습니다. 시간이 충분하지 않으면 간단히 복사 / 붙여 넣기하고 프로젝트를 열악한 인터페이스를 다루는 큰 그림으로 작업합니다. 나중에 코딩 기술에 대한 많은 조언을 제공 할 것입니다. 동료 평가의 경우, 건설적인 비판은 (환영하지 않는 방법에 관계없이) 장기적으로 본인과 본인 모두에게 이익이됩니다.

전체적으로 여유 시간이 있다면 새로 온 사람들에게 모든 사람이 유익하도록 일을 수행하는 방법을 가르쳐 주어야합니다. 잠시 시간을내어 당신에게 효과가 있었던 것과 그렇지 않은 것을 가르쳐주십시오. 시간이 없다면 지금 당장 일을하면서 기회가있을 때 다시 연락하십시오. 특히 미래에 그들과 함께 일할 경우 더 좋은 방법이 있다는 것을 알려주십시오.

한 사람을 더 큰 그룹의 "필터"로 사용하는 것보다 전체 품질을 향상시키는 것이 훨씬 우수합니다. 그 메모에서 :

• 페어 프로그래밍 은 개발 방법을 이해하기위한 코드 검토 버전으로 작동합니다. 읽기와 쓰기, 말하기, 표시의 차이와 같습니다. 코드가 발전하고 변경 사항을 신속하게 논의하는 것은 리팩토링의 방법뿐만 아니라 이유와 좋은 코드를 이해하는 데 큰 도움이됩니다. 내 경험상 아이디어는 계속해서 발전하기 때문에 전체적으로 높은 품질의 결과로 끝나고 코드와 상대방의 사고에 대한 이해가 높아지기 때문에 혼자 개발하는 것 보다 빠릅니다 .
• Linting 도구 는 코딩 스타일을 따르는 지 확인할 수 있습니다. 이를 통해 모든 사람 이 코드 형식을 지정하는 방법을 배우게되며 개발자가 표준을 기억하면 오류가 빨리 사라집니다.
  • 빌드 프로세스의 일부를 커밋하기 전에 수정했는지 확인하십시오.
  • 언어 템플릿을 사용하여 CSS, HTML, JavaScript 및 서버 측 코드를 별도로 확인할 수 있습니다.
• 유효성 검사 도구 는 생성 된 출력이 정상인지 확인할 수 있습니다. 이것도 빌드 프로세스의 일부 여야합니다.

모범 사례는 코딩 스타일 가이드를 보유하고 정기적으로 검토하여 마감일이 다가올 때이 문제에 직면하지 않도록하는 것입니다.

내 추천은 리더십을 보여주고 정기적으로 코드를 검토하는 것입니다. 정기적 인 코드 검토를 보장하기 위해 경영진이 맨 위로 밀리지는 않지만 프로그래머가 정기적으로 코드를 검토하고 일정을 잡기 위해 노력할 때 내 경험에 감동합니다.

사람들에게는 다음과 같은 많은 이점이 있습니다.

• 더 나은 스타일을 배우다
• 더 나은 사례를 따르십시오
• 그들이하고있는 일을 연구하는 법을 배우다

그리고 자신을위한 몇 가지 이점은 다음과 같습니다.

• 마지막 순간에 더 효율적으로 작동합니다 (항상 발생 함)
• 팀과 경영진 모두 전문가와 리더로 인정

나는 "작동하는 것을 고치지 마라"와 "고객에게 중요하지 않은 것에 시간을 낭비하지 마라"라는 대답의 이유를 알 수 있습니다. PM은 위험에 대해 걱정하고 있습니다.

또한 대부분의 사람들이 이런 종류의 수정을 잘하지 못한다는 것을 알고 있습니다. 나도 이것을 이해합니다.

나는 대부분의 마감일이 인위적이라고 믿는다. 실제 시스템은 마감일보다 더 오래 살며 오늘날의 나쁜 디자인은 당신을 영원히 싸울 것입니다. 사람들은 몇 개월 만에 무언가를 제공하고 생산 후 실행되는 코드에서 일부 나쁜 결정을 수정 한 후 몇 년을 보냅니다.

기술 부채는 단어입니다. 언젠가 다시 올 것이고 누군가는 그것을 지불 할 것입니다.

따라서 IMO, 당신은 깨진 디자인을 올바르게 고치고 전문가 (특히 후배에게)라는 것은 비공식적이지 않더라도 비판을받는 방법과 그것을 배우는 방법을 알아야한다는 것을 의미합니다. 사실, 대부분의 삶은 공손하지 않습니다.

모든 정답은 극단적 일 것입니다. 마감 기한이 너무 빡빡해서 못생긴 코드를 사용해야하는 경우가 있으며, 코드가 너무 나빠서 개선하기 위해 마감 기한을 놓칠 가치가있는 경우가 있습니다. 필요한 것은 자신이 속한 것을 판단하는 방법과 더 나은 코드를 작성할 수있는 현실적인 마감일을 설정하는 방법입니다.

나중에 정리를 저장하지 마십시오. 습관적으로 리팩토링 만 할 것이없는 기간이 없다면, 코드를 정리하는 것이 현재보다 더 우선 순위가 높은 "나중"이 없습니다. 루틴은 "빨간색, 초록색, 리팩터링"이 아니라 "빨간색, 초록색, 리팩터링 2 주 동안 완전히 다른 작업을 수행합니다"입니다. 현실적으로 다음에 다른 이유로 코드를 다시 방문 할 때까지 코드를 변경하지 않을 것이며 아마도 마감일이 될 것입니다. 실제 옵션은 지금 해결하거나 떠나는 것입니다.

물론 스타일을 잘 잡은 코드는 스타일이 나쁜 코드보다 낫습니다. 다시 읽을 계획이라면. 다시 읽지 않으려면 정리하지 마십시오 . 테스트를 통과 한 첫 번째 물건을 배송하십시오. 그러나 대부분의 프로그래머에게는 거의 발생하지 않는 시나리오입니다. 이 경우를 무시하면 실제 사례에 대한 세부 정보만으로 수정 비용과 수정하지 않는 비용 (향후 유지 관리 비용 증가)을 판단 할 수 있습니다.

코드를 유지 관리해야하는 시점에서 수정해야하는 것이 지금 수정하는 것보다 해결하기 어려운 것이 있습니다. 이것들은 실제로 지금 고치는 데 큰 도움이되지 않습니다. 가장 분명한 것은 고치기가 쉽지 않다 (공백 오류 등).이 질문을 할 시간이 있지만 고칠 수는 없다고 상상하기 어렵다. ;-) 사소하지 않고 이런 종류의 경우 , 이상적이지 않지만 실용적이어야하는 코드가 있습니다. 작동하며 마감일입니다. 그걸 써.

(a) 모든 사람의 마음이 그렇게 신선하지는 않지만 나중에 수정하기가 훨씬 쉬운 특정 사항이 있습니다. (b) 그것들에 의존하거나 모방하는 다른 것들이 쓰여졌다. 이것들은 지금 고치는 것이 훨씬 더 가치가 있으므로 우선 순위를 정하십시오. 마감일에이 문제를 해결할 시간이 없다면 코드베이스에 부채를 쌓아 다음 번에 방문 할 때 지불해야하므로 마감일을 길게 할 수있는 한 열심히 노력해야합니다. 코드.

코드를 수정하는 기본 방법은 검토 프로세스를 통하는 것입니다. 당신이 가진 문제에 대해 의견을 말하고 후배에게 보내서 변경하십시오 . 당신이 의미하는 바의 예를 제시하고 주니어에게 그들이 적용되는 코드에서 모든 사례를 찾도록 맡길 수 있지만, 단지 코드를 완성하지는 마십시오. 그렇게하면 개선 할 수단이 없습니다.

일반적인 문제는 "이러한 작업을 수행하지 말고 대신 수행하십시오"라는 스타일 가이드에 작성해야하며 그 이유를 설명해야합니다. 궁극적 이유는 "미학적으로 일관된 우리의 코드를 만들기 위해"할 수있다, 그러나 당신이 어떤 명분으로 규칙을 작성할 준비를하지 않으면 당신은 아마 중 하나를 적용 할 수 없습니다. 각 프로그래머는 자유롭게 선택할 수 있습니다.

마지막으로 물건을 무기한으로 조정하는 경향에주의하십시오. 반품은 줄어들고, 여전히 좋은 경험을 통해 배워야합니다. 충분한 것이 무엇인지에 대한 현실적인 아이디어를 형성하는 것이 절대적으로 중요합니다. 그렇지 않으면 마감일이 "충분히 좋은"코드를 만들 수있는 시간을 갖도록하는 협상을 할 수 없습니다. 충분하지 않은 것에 시간을 보내십시오.

많은 사람들이 이전에 말했듯이, 당신이 공중에 던지는 것은 항상 되돌아옵니다. 코드 기반에서 강력한 균일 성을 믿습니다. 물론 어떤 것들은 그다지 중요하지 않습니다. 예를 들어 프로 시저 내의 지역 변수에 대한 명명 규칙. 그러나 구조적 인 경우 기본 트렁크에 최종 병합하기 전에 즉시 수정해야합니다. 개별 프로시 저나 클래스를 볼 때 약간 어색 할 수 있지만 모든 사람이 "약간 못생긴"코드를 커밋하면 실제로 전체적으로 너무 빠릅니다.

추악한 코드는 종종 90 %의 시간 동안 잘 작동하지만 가장자리에서 떨어집니다. 일반적으로 몇 가지 간단한 규칙을 따르면 간단하지 않습니다. 먼저, 모든 프로그래머가 생성 한 모든 절차 또는 기능 블록에 대한 정확한 제약을 정의하고 문서화해야합니다.

둘째, 모든 절차에 대해 이러한 제약 조건에 대한 테스트가 있어야합니다. 이것은 프로그래머가 커밋하기 전에 자신의 절차에 대해 로컬로 실행할 수 있어야하는 간단한 단위 테스트 여야합니다. 분명히 이것은 적절한 테스트 스위트로 관리하기가 쉽지만 테스트가 없어도 작성해야하며 빌드에서 제외 할 수있는 부분 클래스로 커밋해야합니다.

셋째, 사전 구성된 도구가있는 표준화 된 표준 개발 환경이 매우 중요합니다. TS 서버는 이것에 탁월합니다. 모든 사람은 동일한 정확한 도구 (및 버전), 동일한 구성 및 동일한 업데이트를 갖습니다. 표준에 맞게 사전 구성된 CodeRush 또는 Resharper와 같은 리팩토링 도구를 설치하고 프로그래머에게 여전히 경고가있는 커밋을 거부하도록 지시하십시오. 이제 팀의 코드 검토 시간을 사용하여 피드백에서 규칙 세트를 실제로 개선 할 수 있으며 팀은 나중에 지속적으로 정리하지 않고도 행복하게 스스로를 교정 할 수 있습니다. 프로그래머가 동료 나 상사보다 올바르게 구성된 도구에서 코드 비판을받는 것이 훨씬 쉽습니다. 표준은 임의로 정의 된 것처럼 보이거나 제대로 이해되지 않을 수 있습니다. IDE에서 코드가 거칠다고 말하면 아무도 그것에 대해 논쟁하지 않고 수정 될 것입니다. 코드 품질이 크게 향상 될 것이며, 팀 전체가 몇 주 후에 리팩토링하고 정리하는 데 훨씬 적은 시간을 소비하게됩니다. 프로그래머는 규칙에 익숙해지고 쓰레기 코드 작성을 중단합니다.

마지막으로 간단한 수정은 프로그래머에게 개선 동기를 부여하는 것입니다. 프로그래머는 정의상 경쟁력이 있습니다. 누구나 가장 훌륭하거나 빠른 코드를 원합니다. 모든 사람에게 동기를 부여하고 생산성을 향상 시키며 무능한 사람을 근절하는 좋은 방법은 모든 사람을위한 매주 가중 점수 보드를 계산하여 거부 된 커밋 및 깨진 마감 시간 등을 제거하는 것입니다. 주간 팀 회의에서 상위 N을 보여주십시오. 아마도 월 평균에있는 사람에게 점심을 지불 할 수도 있습니다.

검토 도구를 사용하는 것이 좋습니다. Git 기반 저장소가있는 경우 Gerrit 검토 도구를 사용할 수 있습니다 . 커밋이 거부 된 후 팀은 원하는 표준을 배우고 향후 커밋에는 추가 작업이 필요하지 않습니다.

커밋은 당신의 수락을 기다립니다. 다시 써야 할 줄이 있으면 주석을 작성할 수 있으며 팀원은 요구 사항에 따라 코드를 스스로 수정할 수 있습니다. 팀원들이 표준을 코딩 하는 것을 배우는 좋은 방법 입니다.