일관된 코드 스타일의 실제 가치는 무엇입니까


47

고객을위한 새로운 솔루션을 구현하는 컨설턴트 팀의 일원입니다. 나는 클라이언트 측 코드베이스 (React 및 javascript)에 대한 대부분의 코드 검토를 담당합니다.

일부 팀원은 고유 한 코딩 패턴을 사용하여 무작위로 파일을 골라서 스타일을 가진 사람을 누가 알 수 있는지 알 수있었습니다.

예 1 (일회성 인라인 함수)

React.createClass({
  render: function () {
    var someFunc = function () {
      ...
      return someValue;
    };
    return <div>{someFunc()}</div>
  }
});

저자는 someFunc에 의미있는 이름을 지정하면 코드를보다 쉽게 ​​읽을 수 있다고 주장합니다. 함수를 인라인하고 주석을 추가하면 동일한 효과를 얻을 수 있다고 생각합니다.

예 2 (바인딩되지 않은 함수)

function renderSomePart(props, state) {
    return (
      <div>
        <p>{props.myProp}</p>
        <p>{state.myState}</p>
      </div>
    );
}

React.createClass({
  render: function () {
    return <div>{renderSomePart(this.props, this.state)}</div>;
  }
});

이것이 우리가 일반적으로하는 방법입니다 (상태와 소품을 통과하지 않아야 함).

React.createClass({
  renderSomePart: function () {
    return (
      <div>
        <p>{this.props.myProp}</p>
        <p>{this.state.myState}</p>
      </div>
    );
  },
  render: function () {
    return <div>{this.renderSomePart()}</div>;
  }
});

이러한 코딩 패턴은 기술적으로 정확하지만 나머지 코드베이스 나 Facebook (React 작성자)이 자습서 및 예제에서 암시하는 스타일 및 패턴과 일치하지 않습니다.

우리는 정시에 인도하기 위해 빠른 속도를 유지해야하며 불필요하게 팀에 부담을주고 싶지 않습니다. 동시에 우리는 합리적인 품질 수준에 있어야합니다.

고객 유지 관리 개발자가 이와 같은 불일치에 직면했다고 생각하려고합니다 (모든 구성 요소 는 동일한 작업을 수행하는 다른 방법을 이해해야 할 수도 있습니다 ).

질문:

고객과 유지 보수 개발자가 일관된 코드베이스를 인식하고 이와 같은 불일치를 유지하고 잠재적으로 확산시킬 수있는 가치는 무엇입니까?


50
일관된 직교 법의 가치는 무엇입니까? 텍스트를 읽고 쓰는 데있어 영구적이고 지속적인 속도 향상. 일관된 코드 스타일의 가치는 무엇입니까? 코드 읽기 및 쓰기 속도가 영구적이며 일관되게 향상됩니다. 다른 무엇을 원할 수 있습니까?
Kilian Foth

9
글을 읽으면 읽은 내용의 패턴에 익숙해지고 미래의 글을 읽는 방법을 예상하게됩니다. 일관성이 없으면 패턴을 예상 할 수없고 코드에 대한 더 많은 해석을 수행해야하므로 독자의 속도가 느려집니다.
캐나다 코더

1
Joel은 그 주제에 대한 좋은 아이디어를 가지고 있습니다. 요컨대, 좋은 코딩 표준으로 버그를 쉽게 볼 수 있습니다. joelonsoftware.com/articles/Wrong.html

13
JavaScript의 익명 함수보다 명명 된 함수가 거의 항상 선호한다고 덧붙이고 싶습니다. 디버깅 할 때 스택의 위치를 ​​결정하는 데 도움이됩니다.
Mike McMahon

1
@yoniLavi 당신은 메타에 그것을 요구해야합니다.
RubberDuck

답변:


48

코드 전송 장점

라이브러리에서 제공하는 패턴 React을 따르는 경우 React에 익숙한 다른 개발자가 제공하는 제품을 쉽게 픽업하고 유지 관리 할 수 ​​있습니다.

이전 버전과의 호환성 문제

일부 라이브러리에는 새로운 주요 버전이 있으며 패턴이 크게 다른 경우 이전 버전과의 호환성이 저하되어 향후 업그레이드 속도가 느려질 수 있습니다. React새로운 릴리스를 어떻게 다루는 지 잘 모르겠지만 이전에 이런 일이 발생하는 것을 보았습니다.

팀의 신입 사원이 생산성을 높이기 시작

작성자가 제공 한 내용을 따르는 경우 프레임 워크를 사용하여 재능있는 개발자를 고용하고 새로운 패턴을 가르치는 대신 시스템에서 더 빨리 시작할 수 있습니다.

발견되지 않은 잠재적 문제

미래에는 아직 접근 방식으로 발견하지 못했지만 저자의 접근 방식으로 해결되는 문제가있을 수 있습니다.

다시 말해, 혁신이 항상 위험하다고 생각합니다. 접근 방식이 더 우수하고 팀에 적합하다고 생각되면 활용하십시오!


이 우수한 점에 감사드립니다. 우리는 일반적으로 도서관에서 제공하는 패턴을 따르고 있습니다. 내가 제시 한 (코드 리뷰에서 찾은) 예제는 벗어납니다. 고객이 "반응과 모양과 느낌"이 같지 않기 때문에 배달의 일부를 거부하고 다시 실행해야 할까봐 걱정했습니다. 이제 그들이 왜 그런지 알고 있습니다.
Andreas Warberg

2
+1- "rather than teaching new patterns"절차 적 훈련은 신입 사원이있는 매우 큰 시간입니다. 잘 알려진 패턴
Gusdor

1
@Alexus : 이전 버전과의 호환성과 관련하여 React는 여전히 1.0 버전이 아닙니다. 현재 버전 인 0.13은 매우 과감한 방식으로 호환성을 깨뜨 렸지만, 이러한 실패의 발생 여부는 React 구성 요소를 호출하는 데 사용되는 메커니즘에 따라 다릅니다. React 호출 방법에 대한 매우 일관된 규칙이 있어도 React 업그레이드로 인해 코드가 손상되지는 않지만 일관된 코드를 수정하는 것이 더 쉽고 빠르며 안정적입니다. React의 경우 이전 버전과의 호환성 문제에 대한 귀하의 우려는 분명합니다. 예 : stackoverflow.com/a/20913637/18192
Brian

53

불일치 중지하고 생각하게 하는 이유 , 어떤어디에 :

  • 코드의 일부를 읽고 나머지 코드와 다른 스타일을 사용한다는 것을 알면 왜이 특정 부분이 다른가? 내가 알아야 할 특별한 이유가 있습니까? 그 부분이 실제로 다른 이유가 있다면 알고 있어야합니다. 그렇지 않으면 불쾌한 버그가 생길 수 있습니다. 따라서 원래 코드를 만지도록 만든 원래 문제에 대해 생각하는 대신 이제 코드가 다른 이유에 대해 생각하는 데 시간을 낭비하게되며,이를 알아낼 수 없으므로 원래 작성자에게 문의하여 시간을 낭비하고 더 나쁜 것은-그 과정에서 당신이 작업하고있는 문제의 정신적 모델을 잃어버린 것입니다.

    해당 코드를 터치 / 읽어야하는 팀의 다른 모든 개발자에게 곱하십시오.

  • 여러 스타일을 사용하여 코드에 추가해야하는 경우, 당신은 중지하고 결정해야 하는 사용자의 추가에 사용할 스타일. 중요한 결정을 내려야합니다. 중요하지 않은 결정을 생각하는 데 시간을 낭비하는 것은 시간 낭비입니다.

  • 스타일이 일관되면 코드를 쉽게 탐색 할 수 있습니다. 일관성은 일관된 위치 를 신속하게 찾는 데 도움이되기 때문 입니다. 일관성이없는 스타일을 사용하면 원하는 스타일이 어떤 스타일을 사용하는지 알 수 없기 때문에 잡기조차 더 어려워집니다.


6
훌륭하고 환상적인 통찰력. 왜 일부 개발자들은 이것을 단지 '얻는'것처럼 보이고 다른 개발자들은 그것을 반대 하는가?
Dogweather

2
현재 제안 된 일관성있는 스타일이 이전 프로젝트에서 작업 한 스타일과 크게 일치하지 않기 때문입니다. 특히 다른 환경에서 상당한 경험을 가진 사람들을 위해.
킥 스타트

4

코드가 잘 작성되었지만 완벽하게 일관성이 없을 수 있으므로 일부 클라이언트는 신경 쓰지 않습니다. 일이 나 빠지기 시작하면, 그들에게 또 다른 타격을주고 싶습니까? 다중 개발자 프로젝트를 수행하기 위해 회사를 고용했는데 코딩 표준이 있고이를 준수한다고 표시하지 않은 경우 회의적입니다.

우리는 정시에 인도하기 위해 빠른 속도를 유지해야하며 불필요하게 팀에 부담을주고 싶지 않습니다.

코딩 표준이 그렇게 미친 것이 아니라면 모든 사람이 탑승하는 것이 그렇게 어렵지 않아야합니다. 사람들이 어떤 코드를 작성하거나 작성하지 않는지 알기 때문에 입력 및 서식이 아니라 프로젝트가 중단됩니다. 당신이 고착하는 데 상당한 시간이 걸리면 멀리 갔다는 것을 알게 될 것입니다. 바라건대, 이것이 당신의 첫 로데오가 아닙니다.

자신의 테스트를 수행하십시오. 한 개발자에서 다른 개발자로 중간에 과제를 전환하고 다른 사람의 파일을 완성하도록하십시오. 그들은 자신의 버전으로 모든 것을 재 포맷하는데 시간을 소비합니까? 따르기가 너무 어렵습니까? 고객의 유지 관리 팀에게는 더 나빠질 것입니다.


2

자연 영어로 글쓰기 스타일을 다루는 것처럼 코드 스타일을 다루는 행운을 빕니다. 우리가 매일 대화하는 방식을 모방 한 대화 영어부터 공식 영어에 이르기까지 다양한 스타일이 있습니다.

그런 의미에서 최종 제품이 어떻게 보이는지 고려하십시오. 어떤 상황은 당시 가장 적합한 구조를 사용하는 것을 매우지지합니다. 다른 것들은 균일 한 케이던스와 구조를 요구합니다. 공식 영어로 작성된 것처럼 제품이 최고인 경우 특히 그렇습니다. 이 경우 구어체가 도움이 될 수 있지만 제품의 전반적인 느낌이 찢어집니다.

일반적으로 코딩 표준이 일관성이 높을수록 개발자가 흥미로운 것에주의를 기울이는 데 드는 노력이 줄어 듭니다. 다양한 코딩 표준을 지원하는 경우 개발자가 독특하거나 독창적 인 작업을 수행한다고 발표 할 때 소리가 커야합니다. 개발자가 중요하다고 생각하는 것을 표현하려는 시도는 종종 코드 자체의 동적 범위를 어둡게 할 수 있습니다. 이런 일이 발생하면 버그를보기가 너무 어렵 기 때문에 버그가 사라지기 쉽습니다.

이 주장의 반대 측면에서, 코딩 표준이 느슨할수록 개발자는 문제에 대한 구문을 더 자유롭게 적용해야합니다. 프로 코딩 표준 논증과 아이러니 대조적으로, 너무 많은 표준화로 인해 코드 구조가 손상되어 버그를 쉽게 극복 할 수 있습니다.

당신이 찾고있는 것은 자신의 팀의 행복한 매체입니다.


2

다른 사람들이 지적했듯이 유지 관리 개발자가 뒤 쳐야 할 때 다른 스타일의 코드 섹션으로 인해 중지되어 해당 섹션의 특별한 점을 파악하려고 할 것입니다. 일치하지 않는 스타일이 다른 섹션으로 전파되어 나중에 큰 혼란을 초래할 위험이 있습니다.

나는이 질문에 대한 답을 이미 알고 있으며, 이것이 맞지 않으면 직면하지 않을 것이라는 인상을 얻습니다.

우리는 정시에 인도하기 위해 빠른 속도를 유지해야하며 불필요하게 팀에 부담을주고 싶지 않습니다.

이것은 항상 보편적 인 절충안 인 것 같습니다. 빠르게하는 것과 올바르게하는 것입니다. 고객 마감 기한이 바뀔 때 좋은 코딩 관행을 희생 한 결과를 평가할 수 있습니다. 그러나 JeffO는 (이례적이거나 반 직관적 인) 코딩 스타일을 따르는 것이 팀의 속도를 크게 떨어 뜨리지 않아 마감일이 크게 줄어드는 것을 관찰 할 때 JeffO에 동의해야합니다.

몇 년 동안이 개념에 대해 알고 있었지만 최근에는 " 기술 부채 "라는 용어 만 배웠습니다 . 당신은 지금 훈련 된 스타일을 따르지 않는다면 궁극적으로 지불되어야 할 기술 부채를 고려해야합니다.

불행하게도 eBusiness가 언급했듯이 고객이 기술적으로 정통하거나 나중에 코드 자체를 유지 관리하지 않는 한 일관성있는 코딩 표준의 가치를 이해하기는 어렵습니다. 그러나 합리적인 사업가라면 "지금은 약간의 예방 유지 보수"(좋은 코딩 형태)가 "나중에 상당한 수리 비용을 피하는 데 도움이된다"는 개념을 파악할 수 있어야합니다 (나중에 개발자 시간 낭비로 인해 음식물).


고객은 기술에 정통하며 어느 시점에서 솔루션의 유지 관리 및 추가 개발을 담당 할 것입니다. 지금까지 Q & A 노력은 시각적 레이아웃에 초점을 두 었으며 기능에는 그다지 중요하지 않았습니다. 기능 버그가 시작되면 유지 보수가 어떤지에 대한 느낌이들 것입니다. 일관성이 높을수록 코드 검토가 더 빠를 것이라고 생각합니다 (같은 일을하는 놀라운 새로운 방법을 줄이십시오). 고객은 분명히 최대 일관성을 원하지만 추가 비용을 지불하지는 않을 것입니다.
Andreas Warberg

2

여기에서 인기있는 답변은 코드베이스가 어떻게 되길 원하는지에 대해 쉽게 동의 할 수있는 이론적 모범 사례를 반복합니다. 그러나 실제 코드는 결코 그렇게 보이지 않습니다. 완벽한 코드베이스를 만들려고하면 필연적으로 실패 할 것입니다. 그것은 우리가 더 잘하려고하지 말아야한다는 것이 아니라, 실제로 달성 할 수있는 목표와 목표를 설정하는 데 한계가 있다는 것입니다.

사소한 것에 너무 집중하면 전체적으로 가장 효율적인 방법으로 작업을 해결하는 방법과 같이 더 중요한 문제에 집중하지 못할 수 있습니다.

첫 번째 예제를 스타일로 언급하지 않을 것입니다. 스타일은 옳고 그름이없는 선택입니다.이 경우 추가 기능은 거꾸로없는 코드 팽창입니다. 추가 행이 2 개이며 읽기 쉽고 수정하기 쉽기 때문에이 예제 자체는 큰 문제가 아닙니다.

더 큰 문제는 복잡한 코드 팽창입니다. 랩퍼 함수, 클래스 계층 구조 및 주변 코드가 실제 목적이 아니라고 확신 할 수 없을 정도로 복잡 할 수있는 모든 종류의 기타 구성. 코드에 명백한 팽창이 있다면 아마도 더 명백하지 않은 팽창이있을 것입니다. 무언가를하기가 훨씬 어렵고 발견하기도 어렵지만 훨씬 더 큰 문제이기도합니다.

고객에 대하여

고객은 자신의 요구를 해결하는 제품을 얻는 데 집중하는 경향이 있습니다. 코드 품질에 대해 걱정하는 소수의 고객 중 한 명이라도 두 번째 우선 순위가 될 것이며 코드 품질에 대한 아이디어가 귀하와 완벽하게 일치하지 않을 수 있습니다. 고객 회사에는 자체 프로그래머가있을 수 있지만 여전히 업무 수행 여부를 결정하는 것은 관리이며, 코드 품질의 의미를 모르는 경우가 많습니다.


코드를 검토 할 때 직접 DOM 조작, 현지화되지 않은 사용자 대면 문자열, 재사용 기회 (기존 구성 요소, 도우미, 이미로드 된 타사 라이브러리 등), 호환되지 않거나 부적절한 변경 등 확실히 중요하다고 생각되는 몇 가지 사항을 찾습니다. 공유 코드, 고객 및 팀 규칙과의 편차. 스타일과 코딩 패턴의 일관성에 대한 가치는 나에게 분명하지 않았으므로 코드 리뷰에서 어떻게 대응해야할지 확신 할 수 없었습니다.
Andreas Warberg

0

diff의 가독성에 관한 것입니다. 코드 스타일이 튀어 나오면 diff는 프로그램에 의미 상 의미가없는 변경 사항을 숨기고 병합을 어렵게하거나 불가능하게 만들 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.