코드 품질과 강력한 개발자 특성의 균형을 유지하는 방법

직장에서의 코드 검토에서 필자는 코드베이스의 전반적인 품질이나 유지 관리 성을 반드시 추가 할 필요는 없지만 "영리한"것으로 간주되는 코드 및 패턴을보고있었습니다. 나는 이것을 피드백으로 지적하고 반론에 확신을 갖지 못한다. 이 코드가 repo에 들어가고 나중에 프로덕션에 들어가면 약간 걱정됩니다.

응집력있는 팀을 유지하고 싶기 때문에 예약에 대해 너무 보컬하여 긴장을 만들고 싶지 않습니다. 또한 너무 관대하지 않고 고객을 위해 훌륭한 제품을 만들고 싶습니다.

전통적으로, 누가 무엇을 체크인하고 어떻게 '승인'했습니까?

어떻게 작동하지만 너무 복잡하거나 영리한 코드를 발가락에 밟지 않고 제거 할 수 있습니까?

나는이 인용문을 좋아한다 :

"디버깅은 처음에 코드를 작성하는 것보다 두 배나 어렵습니다. 따라서 코드를 가능한 한 영리하게 작성하면 정의에 따라 디버그하기에 충분히 똑똑하지 않습니다." – 브라이언 W. 케르 니건

한편으로는 나중에 디버깅하고 확장하기가 어렵 기 때문에 너무 영리한 코드가 지겨워집니다.

반면에 작동하는 영리한 코드는 배우는 좋은 방법입니다. 아마 전체 팀을 위해. 저자에게 동료들에게 코드에 대한 작은 비공식적 인 이야기를하도록 격려하는 것은 어떻습니까? 실제로 의도 한대로 작동하고 프로젝트 전체에서 의미가 있는지 확인하십시오. 당신은 그것을 무의미한 경쟁으로 바꾸고 싶지 않습니다!

그것이 가치를 더하지 못한다고 생각한다면, "이 부분을 리팩토링 할 수 있는가? 뚫을 수없는 너겟을 만드는 영리하고 읽기 쉬운 코드를 만드는 것이 더 어렵다는 점을 명심하십시오.

내 조언은 바보를 치는 것이다. ) 개발자에게 설명하도록합니다. 작업이 완료되면 향후 유지 보수를위한 주석으로 모든 내용을 기록 할 것을 제안 할 수 있습니다. 암시 적으로 '좋은'코드로 간주하기에는 너무 복잡합니다.

좋은 코드가 너무 복잡하면 대부분의 사람들은 코드 품질이나 개발자 전문 지식에 대한 언급없이 힌트를 얻습니다.

추신. 분명히이 코드의 대부분은 어쨌든 주관적이므로 한 사람의 불가능한 코드는 다른 개발자에게 합리적이고 업계 표준 알고리즘 일 수 있으므로 누군가가 나쁜 코드를 작성했다고 직접 비난 할 수는 없습니다 (간결한 경우는 제외) 바이트 배열을 stl 목록에 복사하여 암호화 루틴으로 전달한 다음 다시 바이트 배열로 변환 한 계약자처럼!)

제 경험은 강력한 개발자 특성을 위해 코드 품질 지침을 구부리는 것입니다. 나는 충분히 깊이 파낼 시간이 없을 때 항상 사용합니다. 그런 길을 파는 것은 일반적으로 상당히 많은 노력이 필요합니다 (아래에 더 자세히 설명되어 있음).

이 규칙은 개인적인 경험에 근거합니다. 나는 가이드 라인을 따르고 모든 편차에 대해 철저히 싸우는 것으로 시작했습니다. 시간이 지남에 따라 나는 충분한 기술을 습득하고 비교적 쉬운 방법으로 이러한 싸움에서 이길 수있는 충분한 트릭을 배웠습니다. 결과적으로 내 "승리"의 전반적인 영향을 배우는 데 더 집중할 수있었습니다. 제가 말할 수있는 한 그 영향은 오히려 부정적인 결과였습니다. "싸움을 잃은"사람들은 고통을 겪고 생산성이 떨어졌습니다. 그리고 그들의 코드가 품질 가이드 라인을 200 % 준수한다는 사실은 그 사실을 보상하지 않았습니다.

이 발견으로 인해 대부분의 전투가 중단되었으며 결과적으로 문제가있는 사례를 분석하는 데 더 많은 시간이 소요되었습니다. 그리고 나는 충분히 깊이 파고 들면 전형적으로 뒤에 어딘가에 흥미로운 디자인 문제가 있다는 것을 발견했습니다 . 미묘한 (또는 미묘하지 않은) 문제는 성격 싸움 뒤에 숨어있었습니다.

• 31K 소스 파일이 권장 크기 제한 인 30K를 초과하는 것을 알 수 있습니다. 내 옵션은 파일 소유자가 어떻게 든 여분의 킬로바이트를 짜내 거나 하루나 이틀의 생각과 파기를 소비하여 몇 가지 / 시간 을 소비하는 것입니다. 즉, 대신 사용할 수있는 라이브러리 API가 있습니다. 해당 파일의 코드를 제거 할 수 있습니다.

그러한 발견은 때로는 최종 사용자 관점에서별로 유용하지 않을 수도 있지만 (때로는 실제로 깊은 영향을 줄 수도 있지만) 그러한 너트를 깨뜨릴 때 얻는 즐거움을 인정해야합니다. 어쨌든 노력의 가치가 있습니다. 케이크 가이드 라인 편차에 착빙도 싸움없이 사라집니다. :)

조직에는 개발 팀의 의견에 따라 정기적으로 업데이트되는 코딩 지침 / 표준 문서가 있어야합니다. 이 문서는 변수 이름 지정 방법, 코드 형식 지정 방법 등과 같은 세부 사항을 설명 할 수 있습니다. 이 문서는 또한 가독성, 유지 보수성, 정확성, 효율성 및 표준 준수와 같은 것들의 상대적 중요성을 포함하여 프로그래머가 코드 작성시 채택 할 것으로 기대하는 가치를 설명해야합니다.

코드 검토는 해당 코딩 표준 문서를 사용하여 수행해야합니다. 코딩 표준에 따르면 두 사람이 충돌 할 때 프로그래머가 간결성보다 가독성을 선호해야한다고 말하는 경우 "영리한"코드에 대해 논쟁하는 데 약간의 지원이 필요합니다. 표준이 그렇게 말하지 않고 표준을 따라야한다고 생각한다면, 누군가의 자아가 온라인에있을 때이를 파악하려고 시도하기보다는 코딩 표준 회의에서 요약하여 논의 할 수 있습니다.

궁극적으로, 그것은 때때로 판단 요청으로 귀결되며,이 경우 최종 단어는 코드 및 / 또는 제품을 책임지는 사람에게 전달되어야합니다. 일반적으로 선임 개발자, 기술 책임자, 프로젝트 관리자 또는 엔지니어링 책임자와 같은 사람입니다. 담당자이고 특정 코드를 충분히 유지 관리 할 수 ​​없다고 생각하는 경우에는 그렇게 말하지 않아도됩니다. 당신은 그것에 대해 외교적 일 수 있습니다 :

샘, 나는 당신의 독창성에 깊은 인상을 받았지만, 그것이 너무 영리하다고 생각합니다. 나는 이것을 유지하기보다는 지금부터 1 년에 한 번 새로운 개발을 위해 노력할 필요가있다. 나는 그것을 유지해야하는 사람이 그 훌륭함을 완전히 이해하지 못할 수도 있다고 우려한다. 나는 당신이 그것을 싫어한다는 것을 알고 있지만, 우리가 논의 한 간단한 구현으로 되돌아 가면 감사하겠습니다.

반면에, 당신이 담당하는 사람이 아니라면, 당신이 할 수있는 최선의 방법은 당신의 입장을 명확하게 설명하고 팀의 나머지 사람들을 설득하는 것입니다. 관리자의 지원을받지 못하면 전화가 아니라는 사실을 받아들이고 계속 진행하십시오.

당신의 장소에서 (그리고 때로는 그 똑똑한 사람 중 하나입니다) 나는 그것을 제거하지 않을 것이지만, 재치있는 / 영리한 저자에게 개인적으로 그것을 주석에 아주 잘 문서화하고 가능한 경우 대안에 대한 토론을 포함하도록 요청하십시오 예를 들어 그가 쓸 수있는 더 간단한 글들.

나는 심지어 그조차도 2 개월 만에 그 줄에있는 모든 비트와 밥을 기억하지 못할 것이기 때문에 이것이 최선임을 강조합니다 .

예를 들어 스마트 코드를 작성하자마자 가장 간단한 코드를 사용하여 스마트 코드를 삭제합니다.

왜 그렇게 될까요?

• 당신 은 그가 쓴 것에 관심을 가지고 있음을 인정했습니다 .
• 당신은 그에게 물어 보면서 존경을 표 했습니다 .
• 메모리 / 초점 문제를 인용함으로써 코드를 변경해야하며 회사 나 팀을 위해 일하는 동안에는 불가능한 시나리오를 고안하고 분류해야합니다.

(마지막 암시하지 않고 요청 이런 종류의 수신 될 수 프로그래머를 상품화하기 위해 회사 측에 시도로 , 그것을 만드는 교환 언제든지 다른 코드 원숭이와 함께)

내 경험상 일반적으로 코드 기반에서 모든 요구 사항을 충족시키는 코드를 얻는 것은 매우 어렵습니다.

그러나 다음에 코드를 유지 관리 할 때는 이전 코드를 유지 관리하기가 어려워 향후 비용 절감을위한 대안으로 코드를 교체한다고 쉽게 주장 할 수 있습니다.

거부권에 관한 한 경영진은 분명히 그것을 가지고 있습니다.
때로는 코드 품질을 담당하는 팀 또는위원회가이 권한을 갖기도합니다.

'영리한'패턴의 예를 제공하면 도움이 될 것입니다. 아마도 당신은 과잉 반응하고 있을지도 모릅니다.

'영리한'은 내 책에서 결코 나쁜 일이 아니지만 영리하고 복잡한 사이에 미끄러운 경사가있을 수 있음에 동의 할 수 있습니다.

다른 많은 관행과 마찬가지로 대답은 그것이 달려 있다고 생각합니다 .

• 결함이라면 반드시 수정해야합니다.
• 코드가 작동하면 코드 변경 주장의 가치와 영리한 코드의 미래 비용을 균형있게 조정해야합니다. 개발 작업과 유지 관리 작업의 비율에 대한 경험 규칙이 있지만 프로젝트마다 크게 다릅니다. 합리적입니다.
• 코드를 단순화해야한다고 팀원에게 확신시킬 수없는 이유를 생각해보십시오.
• 항상 모든 것을 완벽하게 얻을 필요는 없습니다. 그것은 무한 루프에서 코드 검토를 의미하며 아무것도 (내 코드, 하하 제외) 완벽하기 때문에 체크인되지 않았습니다.
• 저의 개인적 선호는 코드 작성자가 최종적으로 말하는 것입니다. 분명히 그들이 매우 가난한 일을 계속하고 있다면 다른 조치를 취해야하지만 개발자가 코드를 변경하도록 강요하는 부정적인 가치는 매우 드문 상황 인 경우 코드를 수정하여 얻은 이익보다 높을 수 있습니다 .

나는이 질문에 분명히 관련 될 수있다. 저는 현재 두 팀의 기술 책임자이며 우리가 생산하는 코드를 가능한 한 읽기 쉽고 유지 관리 할 수 ​​있도록하는 것이 제 임무입니다. 동시에 나는 "영리한"코드를 생성하는 것으로 알려져 있으며, 대부분의 팀원이이를 따르는 데 어려움을 겪을 것이라는 것을 알고 있습니다.

내가 제공 할 수있는 몇 가지 관찰 :

1. 귀하의 팀에는 의견 불일치가있을 때 궁극적 인 결정을 내리는 리더가 필요합니다. 마지막 릴리스에서 나는 지도력이없는 팀에 있었고 끔찍했습니다. 모든 것이 논쟁이되었으며, 강한 개성을 가진 사람이 거의 없다면 어느 쪽도 버지 않습니다. 어떤 결정이 선택되었는지에 관계없이 리드가있는 경우 팀의 모든 사람은 리드가하는 말이 무엇인지 이해해야합니다. 그래서 경영진이 그를 이끌었습니다.

2. 사람들을 행복하게하는 것이 매우 중요합니다. 그러므로 팀 전체를 당신의 관점으로 밀어 붙이는 대신에 그들을 조금만 밀어 내십시오. SOLID 원칙을 설명하고, 작고 응집력있는 클래스 / 메소드 / 인터페이스의 중요성을 설명하고 위반 사항이 발견 될 때마다 (예 : 코드 검토) 이러한 사항을 반복하십시오. 동시에, 그들이 좋아하지 않는 모든 것을 다시 쓰게하지 마십시오. 하루가 끝나면 개인 표현과 그룹 표준 준수 간의 균형이 필요합니다. 개인 선호도가 그룹이 일반적으로 운영되는 방식으로 전환함에 따라 두 사람이 수렴되기를 바랍니다.

3. 나는 "영리한"코드를 가지지 않는 것보다 깨끗하고 이해하기 쉬운 클래스 인터페이스를 갖는 것이 훨씬 더 중요하다고 생각합니다. 예를 들어, 3 가지 방법으로 조회 된 항목 목록을 유지 관리하는 클래스가 있습니다. 현재는 소규모로 작동하는 모든 조회에 대해 선형 검색을 사용하지만이 클래스는 매우 낮은 수준이기 때문에 확장 성이 좋지 않습니다. Boost Intrusive 컨테이너를 사용하는 다른 클래스로 대체하려고합니다. 각 요소는 각 인덱스에 동시에 배치되도록 지원하며 모든 조회는 O (sqrt (N))에서 수행됩니다. 그렇습니다. 내부에서는 훨씬 더 복잡하고 많은 사람들은 Boost를 좋아하지 않지만 외부에서는 추가, 제거, 가져 오기의 3 가지 방법이 남아 있습니다. 결론은 사람들이 원하는 코드를 (이유없이) 작성할 수 있다는 것입니다.

4. 코드 소유권에 대한 아이디어를 유지하십시오. 다른 사람들이 일부 코드를 추가 / 수정해야 할 수도 있기 때문에 달성하기가 어려운 경우도 있습니다. 코드가 작성되면 원래 개발자가 해당 코드의 궁극적 인 골키퍼입니다. 다른 사람이 만질 수 없다는 의미는 아닙니다. 다른 사람들이 자신의 코드를 수정하면 괜찮습니다.하지만 결국 개발자는 코드를 검토하고 그 안에 들어가는 모든 것에 대해 책임을집니다. 그 코드가 단순하거나 영리하든 상관없이 그의 아기입니다. 예측할 때 디자인 / 코딩 결정으로 인해 버그가 발생하기 시작한 경우 버그를 수정하는 대신 해당 개발자와 함께 앉으십시오 (btw는 모든 버그를 수정해야 함) 어떻게 다른 결정을 내릴 수 있는지 결정하기 위해 이러한 결정에 반영합니다.

개발 팀을 이끌고 관리하는 데 수년을 보냈습니다. 본질적으로, 나는 코드와 매우 흑백 측면에서 약간 OCD입니다. 나는 당신의 전투 선택이 팀 리더로서 배우기 가장 어려운 기술 중 하나라는 경험을 통해 배웠습니다. 예, 표준이 중요합니다. 그렇습니다. 가독성과 유지 관리 성이 매우 중요합니다. 그렇습니다. 우리는 모두 통일 된 표준 호환 코드를 작성하기 위해 노력해야합니다. 개발자는 코드 생성 도구가 아니라 인간입니다. 개성과 의견이 있고 지루해하며 새로운 것을 배우고 싶습니다.

직장에서의 코드 검토에서 필자는 코드베이스의 전반적인 품질이나 유지 관리 성을 반드시 추가 할 필요는 없지만 "영리한"것으로 간주되는 코드 및 패턴을보고있었습니다.

좋아 ... 그래서 그들은 추가하지 않지만 산만합니까? 우리는 코딩 스타일에서 개인적 선호의 문제에 대해서만 이야기하고 있습니까, 아니면 코드가 완전히 불필요합니까 (예 : 표현식 트리와 리플렉션을 사용하는 것이 재미있어서 표현식 트리와 리플렉션 사용)? 전자 인 경우 놓아주십시오. 개발자가되는 재미의 일부는 문제에 대한 창의적인 해결책을 제시하는 것입니다. 어쩌면 (그리고 우리 대부분은 이것을 인정하기를 좋아하지 않습니다), 우리는 때때로 우리가 이해하지 못하는 접근법에 위협을 느끼고 새로운 접근법을 배우기 위해 추가 에너지를 요구하거나 원하지 않습니다.

이제 창의성이 불필요한 코드와 완전히 정당화 할 수없는 복잡성을 초래할 때, 반드시 목소리를 내고 사례를 만드십시오. 팀 플레이어가되는 것이 중요하지만 책임을 져야합니다. 코드 검토는 품질 보증 및 학습만큼 책임에 관한 것입니다. 약간의 발걸음을 내딛 으려고 노력하지만, 왜 노력 (돈)이 작업 코드를 다시 작성해야하는지, 그리고 자아가 그 과정에서 멍이 들어야하고 자신의 기술에 대한 누군가의 열정을 무너 뜨릴 위험을 감수해야하는 강력한 논거가 있다고 생각되면 그런 다음 테이블 위에 놓지 마십시오. 당신이 팀장이라면, 이것이 당신의 일입니다. 그 영향을 알고 그렇게하십시오. 팀장이 아니고 권한이 없으면 팀에 맡겨 결정하십시오.

팀에 책임을 부여하는 가장 좋은 방법은 다른 사람들이 당신에게 책임을 지도록 권장하는 것입니다. 열린 마음을 유지하고 코드 개선을 제안 할 때 사람들을 폐쇄하지 않으면 제안을 더 잘 받아 들일 수 있습니다.

개인적인 경험에서, 이런 일이 생길 때 나는 익숙하지 않은 구현을 고문하기 위해 테스트를 작성 하는 자원 봉사자 적대 테스터 가 될 수있는 권한을 요청할 것 입니다.

코드의 작동 방식을 진정으로 이해하고 다양한 방식으로 코드를 조사하려고 노력할 것입니다.

이것은 시간 약속입니다. 몇 시간 또는 수십 시간 일 수도 있고 일주일의 좋은 시간 일 수도 있습니다. 코드의 정당화 여부는 코드의 복잡성이 요구 사항의 복잡성과 일치하는지 여부에 따라 다릅니다.

만약 코드가 많은 테스트를 견뎌 내지 못했다면, 구현이 실제로 나보다 더 깨달았을 것이며, 주 제품에 포함되도록 지원할 것입니다.

소스 제어 방법론에 따라이 테스트 단계를 시작하기 전에 소스 제어 시스템 (아마도 지점)에 코드를 임시로 커밋해야 할 수 있습니다.

내 대답은 OpenCV 사용 경험에 따라 색이 지정됩니다. 프로그래머가 독자적으로 구현할 수있는 것보다 훨씬 정교한 알고리즘이 있습니다. 박사조차도 아니고 아마도 박사의 최상위 몇 퍼센트 일 것입니다. 코드가 그렇게 좋다면, 신뢰 수준을 정량화하는 효과적인 수단이 없더라도 자신의 본능과 편견에 반하여 행동해야합니다.